From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTS4b-0007TD-3y for qemu-devel@nongnu.org; Wed, 31 Oct 2012 02:46:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTS4a-0003ly-41 for qemu-devel@nongnu.org; Wed, 31 Oct 2012 02:46:45 -0400 Received: from mout.web.de ([212.227.17.12]:54220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTS4Z-0003le-Qs for qemu-devel@nongnu.org; Wed, 31 Oct 2012 02:46:44 -0400 Message-ID: <5090C94C.8080808@web.de> Date: Wed, 31 Oct 2012 07:46:36 +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> <5090BF35.6020101@web.de> <5090C6C9.2070403@linux.vnet.ibm.com> In-Reply-To: <5090C6C9.2070403@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7FE8DF5053D6E0DD3FCC82CA" 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) --------------enig7FE8DF5053D6E0DD3FCC82CA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-10-31 07:35, Xiao Guangrong wrote: >>>>> We can not do that for pflash is a RD device which can not be direc= tly written, >>>>> kvm can not emulate the instruction which implicitly write the memo= ry. (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 instruct= ion >>> needs kvm's help to be finished if it explicitly/implicitly write the= memory. >> >> I was assuming that this is what you already do. If you trap write >> accesses, why not allowing user space to handle them? >=20 > Already have done that, guest write ROMD -> vmexit -> return to userspa= ce with > MMIO Exit. Great. >=20 >> >>> >>>> do not see yet what prevents this still, but it should be fixed firs= t. >>> >>> For the explicitly write memory access, it is easy to be fixed - we j= ust need >>> to fetch the instruction from EIP and emulate it. But for the implici= tly 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 reas= on... >=20 > Please allow me to clarify it more clearly. >=20 > The flash is ROMD device means guest can not write it, any kinds of gue= st write > access on this device can cause vmexit to kvm and return to userspace. >=20 > We should pay more attention on it if we execute the code in ROMD since= we > can not use ROMD as stack/page table/IDT table and all other implicitly= write access. > Of course, if you do not use ROM as those purposes, it is okay. :) So the problem is that there is KVM code that still blindly writes to guest memory and does not take the memory regions' protection flag into account? And we cannot mark those regions read only in the host's page table? Jan --------------enig7FE8DF5053D6E0DD3FCC82CA 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/ iEYEARECAAYFAlCQyUwACgkQitSsb3rl5xRxCACglAhILtKNcuuDhgVFENSTDQtb uHYAn1uL7BPBH8TcQRqlv3DPGA6tgsL9 =5Dum -----END PGP SIGNATURE----- --------------enig7FE8DF5053D6E0DD3FCC82CA--