From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBTUX-0005WS-Sh for qemu-devel@nongnu.org; Tue, 11 Sep 2012 12:39:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBTUW-00086x-Gr for qemu-devel@nongnu.org; Tue, 11 Sep 2012 12:39:13 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:40680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBTUW-00086m-A0 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 12:39:12 -0400 Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 11 Sep 2012 10:39:11 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id F3DDB1FF0042 for ; Tue, 11 Sep 2012 10:39:05 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q8BGPsBk191780 for ; Tue, 11 Sep 2012 10:38:46 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q8BGG5fG012248 for ; Tue, 11 Sep 2012 10:16:07 -0600 From: Anthony Liguori In-Reply-To: <504F5942.5020904@siemens.com> References: <1347006389-543-1-git-send-email-liusheng@linux.vnet.ibm.com> <1347006389-543-4-git-send-email-liusheng@linux.vnet.ibm.com> <5049B56B.20707@siemens.com> <504CB9B3.8010408@redhat.com> <504DB212.3000908@siemens.com> <20120911030214.GA27802@morn.localdomain> <504F5942.5020904@siemens.com> Date: Tue, 11 Sep 2012 11:15:50 -0500 Message-ID: <87y5kgo7rd.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 3/3] support readonly memory feature in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka , Kevin O'Connor Cc: "kvm@vger.kernel.org" , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "xiaoguangrong@linux.vnet.ibm.com" , Avi Kivity , Liu Sheng Jan Kiszka writes: > On 2012-09-11 05:02, Kevin O'Connor wrote: >> On Mon, Sep 10, 2012 at 11:25:38AM +0200, Jan Kiszka wrote: >>> On 2012-09-09 17:45, Avi Kivity wrote: >>>> On 09/07/2012 11:50 AM, Jan Kiszka wrote: >>>>> >>>>>> + } else { >>>>>> + cpu_physical_memory_rw(run->mmio.phys_addr, >>>>>> + run->mmio.data, >>>>>> + run->mmio.len, >>>>>> + run->mmio.is_write); >>>>>> + } >>>>>> + >>>>>> ret = 0; >>>>>> break; >>>>>> case KVM_EXIT_IRQ_WINDOW_OPEN: >>>>>> >>>>> >>>>> Great to see this feature for KVM finally! I'm just afraid that this >>>>> will finally break good old isapc - due to broken Seabios. KVM used to >>>>> "unbreak" it as it didn't respect write protections. ;) >>>> >>>> Can you describe the breakage? >>> >>> Try "qemu -machine isapc [-enable-kvm]". Seabios is writing to some >>> read-only marked area. Don't recall where precisely. >> >> On boot, QEMU marks the memory at 0xc0000-0x100000 as read-only. > > Only the remapped BIOS ROM (0xe0000-0xfffff) is read-only. And that's > where SeaBIOS apparently wants to write to. > >> SeaBIOS then makes the area read-write, performs its init, and then >> makes portions of it read-only before launching the OS. > > What does it do if there is no PAM? Nothing? > >> >> The registers SeaBIOS uses to make the memory read-write are on a PCI >> device. On isapc, this device is not reachable, and thus SeaBIOS >> can't make the memory writable. > > On isapc, this device and all the PAM does not even exist. > >> >> The easiest way to fix this is to change QEMU to boot with the area >> read-write. There's no real gain in booting with the memory read-only >> as the first thing SeaBIOS does is make it read-write. > > Considering SeaBIOS, that is true. If Seabios depends inherently on > shadow ROMs and as we have no real chipset for isapc to control > shadowing behavior, that will likely be the best option. Can have a > look. I've never really understood this. Why do we need ISAPC? An ISA-only OS would still be okay on a system with an i440fx and no PCI devices, no? I think that makes a lot more sense because then SeaBIOS doesn't have to deal with the notion of ISAPC. Regards, Anthony Liguori > > Jan > > -- > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE > Corporate Competence Center Embedded Linux > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html