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.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
