qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 3/5] Qemu: do not mark bios readonly


From: Xiao Guangrong
Subject: Re: [Qemu-devel] [PATCH v2 3/5] Qemu: do not mark bios readonly
Date: Mon, 29 Oct 2012 16:31:18 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

On 10/29/2012 03:44 PM, Jan Kiszka wrote:
> On 2012-10-29 08:09, Xiao Guangrong wrote:
>> Jan,
>>
>> On 10/26/2012 06:35 PM, Jan Kiszka wrote:
>>
>>> This has two problems: We know it breaks at least Win 95 that overwrites
>>> its F-segment during boot. And it applies changes to the shadowed area
>>> (below 1 MB) also to the ROM area - I don't think that is the original
>>> behaviour on real hardware.
>>
>> So what is the problem? It can break Win95's running?
>>
>> I tried to install win95 guest but it failed to boot regardless my patchset
>> was applied or not. I found the information that win 95 is not supported at
>> http://www.linux-kvm.org/page/Guest_Support_Status
>>
>> Note: before my patchset, Win 95 still can happily something into ROM area
>> because readonly memory is actually writable on KVM. And win95 can not run
>> on isapc with --no-kvm since it is no way to enable shadow ROM.
> 
> Your patches causes regressions on TCG mode as that is perfectly fine
> with booting Win95 so far.

Aha, i tried accel=tcg, before my patchset, it works for -machine pc but
failed for -machine isapc (known issue for seabios). After my patchset,
it works fine for both -machine pc and isapc. :)

> 
>>
>>>
>>> What we need is paravirtual shadow write control for the ISA PC. It's on
>>> my todo list, maybe I will be able to look into this during the next week.
>>>
>>
>> You idea is that modify the code of seabios and use a special way (PV) to
>> notify Qemu to make the bios writable?
> 
> Yes.
> 
>>
>> Actually, I am confused why the guest (including bios) persistently uses
>> shadow ROM even if it is not supported (on ISA PC), i think the right way
>> is move itself to RAM under this case, no?
> 
> I've been told that Seabios has been built around that assumption and
> the PV shadow control would be simpler to realize.

Sounds the PV is complexer that directly making the bios area writable
(if it works).

> 
>>
>>> BTW, your patch series should allow to drop the KVM special case from
>>> pc_system_firmware_init. That version, btw, treats high and low BIOS
>>> areas separately - but only reloads the upper area. Hmm...
>>>
>>
>> You mean that also allow Qemu to use pflash to load bios if kvm is enabled?
> 
> Yes.
> 
>> We can not do that for pflash is a RD device which can not be directly 
>> written,
>> kvm can not emulate the instruction which implicitly write the memory. (e.g:
>> using this area as stack).
> 
> Isn't enabling ROMD support for KVM that whole point of your patches? I

It can generate MMIO exit if ROMD be written, that means the instruction
needs kvm's help to be finished if it explicitly/implicitly write the memory.

> do not see yet what prevents this still, but it should be fixed first.

For the explicitly write memory access, it is easy to be fixed - we just need
to fetch the instruction from EIP and emulate it. But for the implicitly memory
access, fixing its emulation is really hard work. Really worth doing it?




reply via email to

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