From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkZjp-000068-UY for qemu-devel@nongnu.org; Tue, 21 Apr 2015 11:05:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkZjk-0007Wf-HD for qemu-devel@nongnu.org; Tue, 21 Apr 2015 11:05:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58504) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkZjk-0007WP-8U for qemu-devel@nongnu.org; Tue, 21 Apr 2015 11:05:20 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3LF5IdP027496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 21 Apr 2015 11:05:19 -0400 Message-ID: <5536672A.6060809@redhat.com> Date: Tue, 21 Apr 2015 17:05:14 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1429521560-2743-1-git-send-email-kraxel@redhat.com> <1429521560-2743-6-git-send-email-kraxel@redhat.com> <55365F05.1050402@redhat.com> <553660EC.4040902@redhat.com> In-Reply-To: <553660EC.4040902@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Gerd Hoffmann Cc: qemu-devel@nongnu.org, mst@redhat.com On 04/21/15 16:38, Paolo Bonzini wrote: > > > On 21/04/2015 16:30, Laszlo Ersek wrote: >>>> - MemoryRegion tseg_blackhole; >>>> + MemoryRegion tseg_blackhole, tseg_window; >>>> PcPciInfo pci_info; >>>> ram_addr_t below_4g_mem_size; >>>> ram_addr_t above_4g_mem_size; >>>> >> Why is this necessary? If you disable the black hole overlay, the access >> will go to the RAM. (Or can't that be done per-CPU?) > > The reason to have two separate MemoryRegions is exactly to allow > per-CPU access. > > tseg_blackhole is added on top of address_space_memory to hide TSEG; > tseg_window is included in /machine/smram and TCG adds it to the private > per-CPU address space when it enters system management mode. Hm, I must have missed this (or not seen it at all) -- should I have noticed it in Gerd's series somewhere (or in yours)? Or is that by virtue of mapping mch->tseg_window as a subregion of mch->smram? (These overlays are pretty confusing, without a graphical visualization :)) >> I'm thinking, the last 1 / 2 / 8 megabytes should behave as RAM in all >> of the following cases: >> - no SMRAM programmed (tseg size = 0) >> - SMRAM programmed (tseg size > 0), and it is open >> - SMRAM programmed (tseg size > 0) and closed, but CPU in SMM > > Correct. However, you can have one CPU in SMM and another executing > "normal" code. It would be a hole to allow that CPU to read (or worse, > write) the TSEG or legacy SMRAM areas. > >> ... Another question, related to SMM (but not related to SMRAM): Paolo, >> am I right to think that we'll be keying off at least two independent >> things of SMM-or-not: one is access to SMRAM (tseg), for LockBox and SMM >> driver purposes, the other is pflash access (with the MemTxAttrs thing), >> for the varstore? > > Yes. Great, thank you. Yet another question -- as far as I understand, I should have enough info (with my pending questions of course) for EFI_SMM_ACCESS2_PROTOCOL. I've now reviewed EFI_SMM_CONTROL2_PROTOCOL too, and AFAICS the only thing I need to know for it is "how to raise an SMI, synchronously". What are the plans for that? An ioport write perhaps? (I skimmed the ICH9 spec, but whatever I found seemed to be quite inappropriate.) Thanks Laszlo