qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/3] support readonly memory feature in qemu


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 3/3] support readonly memory feature in qemu
Date: Tue, 11 Sep 2012 18:33:51 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-09-11 18:15, Anthony Liguori wrote:
> Jan Kiszka <address@hidden> writes:
> 
>> On 2012-09-11 05:02, Kevin O'Connor wrote:
>>> On Mon, Sep 10, 2012 at 11:25:38AM +0200, Jan Kiszka wrote:
>>>> On 2012-09-09 17:45, Avi Kivity wrote:
>>>>> On 09/07/2012 11:50 AM, Jan Kiszka wrote:
>>>>>>
>>>>>>> +            } else {
>>>>>>> +                cpu_physical_memory_rw(run->mmio.phys_addr,
>>>>>>> +                                       run->mmio.data,
>>>>>>> +                                       run->mmio.len,
>>>>>>> +                                       run->mmio.is_write);
>>>>>>> +            }
>>>>>>> +
>>>>>>>              ret = 0;
>>>>>>>              break;
>>>>>>>          case KVM_EXIT_IRQ_WINDOW_OPEN:
>>>>>>>
>>>>>>
>>>>>> Great to see this feature for KVM finally! I'm just afraid that this
>>>>>> will finally break good old isapc - due to broken Seabios. KVM used to
>>>>>> "unbreak" it as it didn't respect write protections. ;)
>>>>>
>>>>> Can you describe the breakage?
>>>>
>>>> Try "qemu -machine isapc [-enable-kvm]". Seabios is writing to some
>>>> read-only marked area. Don't recall where precisely.
>>>
>>> On boot, QEMU marks the memory at 0xc0000-0x100000 as read-only.
>>
>> Only the remapped BIOS ROM (0xe0000-0xfffff) is read-only. And that's
>> where SeaBIOS apparently wants to write to.
>>
>>> SeaBIOS then makes the area read-write, performs its init, and then
>>> makes portions of it read-only before launching the OS.
>>
>> What does it do if there is no PAM? Nothing?
>>
>>>
>>> The registers SeaBIOS uses to make the memory read-write are on a PCI
>>> device.  On isapc, this device is not reachable, and thus SeaBIOS
>>> can't make the memory writable.
>>
>> On isapc, this device and all the PAM does not even exist.
>>
>>>
>>> The easiest way to fix this is to change QEMU to boot with the area
>>> read-write.  There's no real gain in booting with the memory read-only
>>> as the first thing SeaBIOS does is make it read-write.
>>
>> Considering SeaBIOS, that is true. If Seabios depends inherently on
>> shadow ROMs and as we have no real chipset for isapc to control
>> shadowing behavior, that will likely be the best option. Can have a
>> look.
> 
> I've never really understood this.
> 
> Why do we need ISAPC?  An ISA-only OS would still be okay on a system
> with an i440fx and no PCI devices, no?

For OSes that were not aware of newer devices, there should be indeed no
difference. But for those that were, the behaviour can be different than
what you want to recreate. I suppose that was the reason for
creating/keeping this variant.

> I think that makes a lot more sense because then SeaBIOS doesn't have to
> deal with the notion of ISAPC.

How much difference does it actually today? Was it really ever written
for such a use case or does it now work by chance?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]