From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTRP5-0005lF-11 for qemu-devel@nongnu.org; Wed, 31 Oct 2012 02:03:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTRP3-0008Oa-7m for qemu-devel@nongnu.org; Wed, 31 Oct 2012 02:03:50 -0400 Received: from mout.web.de ([212.227.15.3]:60652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTRP2-0008OG-V4 for qemu-devel@nongnu.org; Wed, 31 Oct 2012 02:03:49 -0400 Message-ID: <5090BF35.6020101@web.de> Date: Wed, 31 Oct 2012 07:03:33 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <50890462.5010307@linux.vnet.ibm.com> <508904C4.7030409@linux.vnet.ibm.com> <508A6772.4040400@siemens.com> <508E2B98.4050700@linux.vnet.ibm.com> <508E33F5.2000001@web.de> <508E3ED6.5070605@linux.vnet.ibm.com> In-Reply-To: <508E3ED6.5070605@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig23CCD9E3985E4418DF0780CC" Subject: Re: [Qemu-devel] [PATCH v2 3/5] Qemu: do not mark bios readonly List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xiao Guangrong Cc: KVM , Marcelo Tosatti , qemu-devel@nongnu.org, Kevin O'Connor , Avi Kivity , Anthony Liguori , Liu Sheng This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig23CCD9E3985E4418DF0780CC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-10-29 09:31, Xiao Guangrong wrote: > 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 overwr= ites >>>> its F-segment during boot. And it applies changes to the shadowed ar= ea >>>> (below 1 MB) also to the ROM area - I don't think that is the origin= al >>>> 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 pa= tchset >>> was applied or not. I found the information that win 95 is not suppor= ted 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 no= t 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. >=20 > Aha, i tried accel=3Dtcg, 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. :) Indeed, looks like I'm on the wrong track regarding what breaks Win95 in KVM mode. However: This patch inappropriately allows the guest to change the BIOS content during runtime. And that not only in the lower ISA range, not only for our stepchild isapc but for the high ROM range as well, even with PCI chipset enabled. So this is nothing more than a hack. >=20 >> >>> >>>> >>>> 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 u= ses >>> 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. >=20 > Sounds the PV is complexer that directly making the bios area writable > (if it works). But it is the only correct solution. In fact, shadowing means mapping RAM above the ROM, not enabling writability, and then copying necessary bits from the high ROM part to that RAM. Seabios does this when PAM is available, we just need to pull in those bits for PV shadow control. >=20 >> >>> >>>> BTW, your patch series should allow to drop the KVM special case fro= m >>>> 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 en= abled? >> >> Yes. >> >>> We can not do that for pflash is a RD device which can not be directl= y written, >>> kvm can not emulate the instruction which implicitly write the memory= =2E (e.g: >>> using this area as stack). >> >> Isn't enabling ROMD support for KVM that whole point of your patches? = I >=20 > It can generate MMIO exit if ROMD be written, that means the instructio= n > needs kvm's help to be finished if it explicitly/implicitly write the m= emory. I was assuming that this is what you already do. If you trap write accesses, why not allowing user space to handle them? >=20 >> do not see yet what prevents this still, but it should be fixed first.= >=20 > For the explicitly write memory access, it is easy to be fixed - we jus= t need > to fetch the instruction from EIP and emulate it. But for the implicitl= y memory > access, fixing its emulation is really hard work. Really worth doing it= ? Aren't the read-only regions also marked read-only on the host side to avoid that the guest writes to it? Or how is this implemented? Support for flash emulation in KVM mode is increasingly important, for embedded platform virtualization but also for classic x86 server-like targets. The pflash-backed system firmware device was added for a reason.= =2E. Jan --------------enig23CCD9E3985E4418DF0780CC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCQvzgACgkQitSsb3rl5xQpuQCgqynV1t4Vq0ojmA3b1T0A91rc Rt4AoNLxYjb6PszI4CQ/LKViOfp704Lp =M8Sj -----END PGP SIGNATURE----- --------------enig23CCD9E3985E4418DF0780CC--