From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiNqN-0000jf-4A for qemu-devel@nongnu.org; Wed, 15 Apr 2015 09:59:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiNqI-00085G-0T for qemu-devel@nongnu.org; Wed, 15 Apr 2015 09:59:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiNqH-000858-R9 for qemu-devel@nongnu.org; Wed, 15 Apr 2015 09:59:01 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 1C7E58EA3E for ; Wed, 15 Apr 2015 13:59:01 +0000 (UTC) Message-ID: <1429106337.6219.5.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Wed, 15 Apr 2015 15:58:57 +0200 In-Reply-To: <552D259E.405@redhat.com> References: <1429017160-3583-1-git-send-email-kraxel@redhat.com> <552D259E.405@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] q35: implement SMRAM.D_LCK List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" On Di, 2015-04-14 at 16:35 +0200, Paolo Bonzini wrote: > > On 14/04/2015 15:12, Gerd Hoffmann wrote: > > Signed-off-by: Gerd Hoffmann > > --- > > hw/pci-host/q35.c | 17 ++++++++++++++++- > > 1 file changed, 16 insertions(+), 1 deletion(-) > > > > diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c > > index 79bab15..9227489 100644 > > --- a/hw/pci-host/q35.c > > +++ b/hw/pci-host/q35.c > > @@ -268,6 +268,20 @@ static void mch_update_smram(MCHPCIState *mch) > > PCIDevice *pd = PCI_DEVICE(mch); > > bool h_smrame = (pd->config[MCH_HOST_BRIDGE_ESMRAMC] & MCH_HOST_BRIDGE_ESMRAMC_H_SMRAME); > > > > + /* implement SMRAM.D_LCK */ > > + if (pd->config[MCH_HOST_BRIDGE_SMRAM] & MCH_HOST_BRIDGE_SMRAM_D_LCK) { > > + pd->config[MCH_HOST_BRIDGE_SMRAM] &= ~MCH_HOST_BRIDGE_SMRAM_D_OPEN; > > + > > + pd->wmask[MCH_HOST_BRIDGE_SMRAM] &= ~MCH_HOST_BRIDGE_SMRAM_D_OPEN; > > + pd->wmask[MCH_HOST_BRIDGE_SMRAM] &= ~MCH_HOST_BRIDGE_SMRAM_D_LCK; > > + pd->wmask[MCH_HOST_BRIDGE_SMRAM] &= ~MCH_HOST_BRIDGE_SMRAM_G_SMRAME; > > + pd->wmask[MCH_HOST_BRIDGE_SMRAM] &= ~MCH_HOST_BRIDGE_SMRAM_C_BASE_SEG_MASK; > > + > > + pd->wmask[MCH_HOST_BRIDGE_ESMRAMC] &= ~MCH_HOST_BRIDGE_ESMRAMC_H_SMRAME; > > + pd->wmask[MCH_HOST_BRIDGE_ESMRAMC] &= ~MCH_HOST_BRIDGE_ESMRAMC_TSEG_SZ_MASK; > > + pd->wmask[MCH_HOST_BRIDGE_ESMRAMC] &= ~MCH_HOST_BRIDGE_ESMRAMC_T_EN; > > + } > > + > > memory_region_transaction_begin(); > > > > if (pd->config[MCH_HOST_BRIDGE_SMRAM] & SMRAM_D_OPEN) { > > @@ -297,7 +311,6 @@ static void mch_write_config(PCIDevice *d, > > { > > MCHPCIState *mch = MCH_PCI_DEVICE(d); > > > > - /* XXX: implement SMRAM.D_LOCK */ > > pci_default_write_config(d, address, val, len); > > > > if (ranges_overlap(address, len, MCH_HOST_BRIDGE_PAM0, > > @@ -351,6 +364,8 @@ static void mch_reset(DeviceState *qdev) > > MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT); > > > > d->config[MCH_HOST_BRIDGE_SMRAM] = MCH_HOST_BRIDGE_SMRAM_DEFAULT; > > + d->wmask[MCH_HOST_BRIDGE_SMRAM] = 0xff; > > + d->wmask[MCH_HOST_BRIDGE_ESMRAMC] = 0xff; > > S3, if I remember correctly, should not be able to reset D_LCK. The "A Tour Beyond BIOS Implementing S3 Resume with EDKII" white paper lists "Lock SMM. This must be done to maintain SMM integrity." as todo list item for the edk2 resume code path (page 18). So it seems to me it is the job of the firmware to re-lock smm after S3 (and before handing control back to the OS, obviously). > Does > this do the right thing? I think so ... cheers, Gerd