From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkZK9-00031C-W5 for qemu-devel@nongnu.org; Tue, 21 Apr 2015 10:38:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkZK2-0005wr-HQ for qemu-devel@nongnu.org; Tue, 21 Apr 2015 10:38:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkZK2-0005wW-6i for qemu-devel@nongnu.org; Tue, 21 Apr 2015 10:38:46 -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 (8.14.4/8.14.4) with ESMTP id t3LEcfuQ008407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 21 Apr 2015 10:38:45 -0400 Message-ID: <553660EC.4040902@redhat.com> Date: Tue, 21 Apr 2015 16:38:36 +0200 From: Paolo Bonzini 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> In-Reply-To: <55365F05.1050402@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: Laszlo Ersek , Gerd Hoffmann Cc: qemu-devel@nongnu.org, mst@redhat.com 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. > 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. Paolo