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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v2 3/5] Qemu: do not mark bios readonly
Date: Mon, 29 Oct 2012 08:44:53 +0100
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-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.

> 
>>
>> 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.

> 
>> 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
do not see yet what prevents this still, but it should be fixed first.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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