From patchwork Mon Feb 18 12:53:15 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 221328 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 59DC92C13BF for ; Mon, 18 Feb 2013 23:53:55 +1100 (EST) Received: from localhost ([::1]:59766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7QED-0007gw-3a for incoming@patchwork.ozlabs.org; Mon, 18 Feb 2013 07:53:53 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7QDz-0007fw-7t for qemu-devel@nongnu.org; Mon, 18 Feb 2013 07:53:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7QDt-0005R9-UY for qemu-devel@nongnu.org; Mon, 18 Feb 2013 07:53:39 -0500 Received: from bombadil.infradead.org ([2001:4830:2446:ff00:4687:fcff:fea6:5117]:51810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7QDt-0005Pe-Pw for qemu-devel@nongnu.org; Mon, 18 Feb 2013 07:53:33 -0500 Received: from i7.infradead.org ([2001:8b0:10b:1:225:64ff:fee8:e9df]) by bombadil.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux)) id 1U7QDc-0005h0-JQ; Mon, 18 Feb 2013 12:53:17 +0000 Message-ID: <1361191995.13482.107.camel@i7.infradead.org> From: David Woodhouse To: Laszlo Ersek Date: Mon, 18 Feb 2013 12:53:15 +0000 In-Reply-To: <1361184025.13482.90.camel@i7.infradead.org> References: <511D4BDF.2000506@redhat.com> <1360880674.27246.20.camel@shinybook.infradead.org> <511E8470.1020707@redhat.com> <1360961820.17260.13.camel@i7.infradead.org> <511EE2D5.9090804@redhat.com> <1361184025.13482.90.camel@i7.infradead.org> X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 2001:4830:2446:ff00:4687:fcff:fea6:5117 Cc: "edk2-devel@lists.sourceforge.net" , seabios , "qemu-devel@nongnu.org" Subject: Re: [Qemu-devel] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Mon, 2013-02-18 at 10:40 +0000, David Woodhouse wrote: > On Sat, 2013-02-16 at 02:37 +0100, Laszlo Ersek wrote: > > I give up. Thanks for the help & sorry about spamming three lists. > > I've managed to reproduce this on a clean F18 system. This is the stock > qemu 1.2.2-6.fc18 on kernel 3.7.6-201.fc18.x86_64 with a newly-installed > Fedora 18 VM in the guest. > > qemu-system-x86_64 -enable-kvm -cdrom F18boot.iso -serial mon:stdio -bios OVMF.fd > > On my laptop where I'd been doing most of my testing, even after running > 'yum distro-sync qemu\*' to get back to the stock qemu, I still can't > reproduce the issue. They are both running the *same* kernel. > > I'll try reverting a whole bunch of other stuff that ought to be > irrelevant to the stock distro packages, and see if/when it breaks... I cannot make these two machines behave consistently. I have absolutely no clue what is going on here. At reset, the PAM regions are all set to '1' (read only). So the CSM should reside in RAM at 0xffff0 but THAT SHOULDN'T MATTER. After a reset we should be running from 0xfffffff0 and there's unconditionally ROM there, isn't there? Nevertheless, on my workstation as on yours, we do seem to end up executing from the CSM in RAM when we reset. But on my laptop, it executes the *ROM* as it should. This patch 'fixes' it, and I think it might even be correct in itself, but I don't think it's a correct fix for the problem we're discussing. And I certainly want to know what's different on my laptop that makes it work *without* this patch. Either there's some weirdness with setting the high CS base address, on CPU reset. Or perhaps the contents of the memory region at 0xfffffff0 have *really* been changed along with the sub-1MiB range. Or maybe the universe just hates us... diff --git a/hw/piix_pci.c b/hw/piix_pci.c index 6c77e49..6dcf1c5 100644 --- a/hw/piix_pci.c +++ b/hw/piix_pci.c @@ -171,6 +171,23 @@ static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id) return 0; } +static void i440fx_reset(void *opaque) +{ + PCII440FXState *d = opaque; + uint8_t *pci_conf = d->dev.config; + + pci_conf[0x59] = 0x00; // Reset PAM setup + pci_conf[0x5a] = 0x00; + pci_conf[0x5b] = 0x00; + pci_conf[0x5c] = 0x00; + pci_conf[0x5d] = 0x00; + pci_conf[0x5e] = 0x00; + pci_conf[0x5f] = 0x00; + pci_conf[0x72] = 0x02; // And SMM + + i440fx_update_memory_mappings(d); +} + static int i440fx_post_load(void *opaque, int version_id) { PCII440FXState *d = opaque; @@ -217,6 +234,8 @@ static int i440fx_initfn(PCIDevice *dev) d->dev.config[I440FX_SMRAM] = 0x02; cpu_smm_register(&i440fx_set_smm, d); + + qemu_register_reset(i440fx_reset, d); return 0; }