From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSkl2-0003Fa-RF for qemu-devel@nongnu.org; Mon, 29 Oct 2012 04:31:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TSkkw-000743-OY for qemu-devel@nongnu.org; Mon, 29 Oct 2012 04:31:40 -0400 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:45827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSkkw-00073P-0e for qemu-devel@nongnu.org; Mon, 29 Oct 2012 04:31:34 -0400 Received: from /spool/local by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Oct 2012 14:01:30 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9T8VRSs35717264 for ; Mon, 29 Oct 2012 14:01:27 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9TE1H9W015141 for ; Mon, 29 Oct 2012 14:01:18 GMT Message-ID: <508E3ED6.5070605@linux.vnet.ibm.com> Date: Mon, 29 Oct 2012 16:31:18 +0800 From: Xiao Guangrong 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> In-Reply-To: <508E33F5.2000001@web.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Jan Kiszka Cc: KVM , Marcelo Tosatti , qemu-devel@nongnu.org, Kevin O'Connor , Avi Kivity , Anthony Liguori , Liu Sheng 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?