From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzouC-0008Dk-TU for qemu-devel@nongnu.org; Tue, 02 Jun 2015 12:19:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yzou9-0003Dh-Me for qemu-devel@nongnu.org; Tue, 02 Jun 2015 12:19:08 -0400 Received: from e18.ny.us.ibm.com ([129.33.205.208]:45409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yzou9-0003DV-JA for qemu-devel@nongnu.org; Tue, 02 Jun 2015 12:19:05 -0400 Received: from /spool/local by e18.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 2 Jun 2015 12:19:04 -0400 Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 080486E8072 for ; Tue, 2 Jun 2015 12:10:48 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t52GIxQi55443588 for ; Tue, 2 Jun 2015 16:19:00 GMT Received: from d01av03.pok.ibm.com (localhost [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t52GIxfv019026 for ; Tue, 2 Jun 2015 12:18:59 -0400 Message-ID: <556DD772.3050807@linux.vnet.ibm.com> Date: Tue, 02 Jun 2015 12:18:58 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1432676024-1046793-1-git-send-email-stefanb@linux.vnet.ibm.com> <1432676024-1046793-4-git-send-email-stefanb@linux.vnet.ibm.com> <20150531181159.GH5268@redhat.com> <556D1EDE.8060100@linux.vnet.ibm.com> <20150602110702-mutt-send-email-mst@redhat.com> <556DAE20.5070709@linux.vnet.ibm.com> <20150602152340-mutt-send-email-mst@redhat.com> <556DBDA4.2040202@linux.vnet.ibm.com> <20150602163822-mutt-send-email-mst@redhat.com> <20150602151831.GA28908@morn.localdomain> In-Reply-To: <20150602151831.GA28908@morn.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 3/6] Support Physical Presence Interface Spec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor , "Michael S. Tsirkin" Cc: imammedo@redhat.com, qemu-devel@nongnu.org, quan.xu@intel.com On 06/02/2015 11:18 AM, Kevin O'Connor wrote: > On Tue, Jun 02, 2015 at 04:46:06PM +0200, Michael S. Tsirkin wrote: >> On Tue, Jun 02, 2015 at 10:28:52AM -0400, Stefan Berger wrote: >>> How would I mark the DataTableRegion as AddressRangeReserved or would it >>> automatically be? >> It's automatically either AddressRangeReserved or AddressRangeNVS. >> It doesn't look like you have control over which it is. >> seabios makes it reserved, nvs makes it > As I understand it, Stefan wants to do something a little unusual > here. The goal is to allow the guest OS to send a signal to the BIOS > on the next boot, because the TPM stuff only allows the BIOS to change > certain settings immediately after the machine has booted (or > rebooted). So, the idea is to allow the guest OS to put some code in > reserved memory that is at a consistent address so that on a reboot > seabios can find that code and take the corresponding action. The > memory has to be non-volatile across reboots, and it must be someplace > that can be found prior to it being zero'd or overwritten by any init > process. > > Did I understand this correctly? Correct. > > If so, I don't see how the normal QEMU <-> seabios ACPI table > deployment mechanism will help here. SeaBIOS does reserve the space, > but nothing prevents SeaBIOS from overwriting it before extracting any > updates from a previous boot. > > As an aside, I thought putting the updates in a "reserved area" of the > TPM chip was a simple solution to this problem. That way, it's easy > for the guest OS and SeaBIOS to know where the codes will be stored, > and no chance any init process will overwrite it by accident. > > For reference, the original solution was for SeaBIOS to declare an > area of reserved memory and do it in such a way that the address would > be consistent across reboots and would not be overwritten by any init > process. The problem with this approach was that the guest OS didn't > implicitly know where that area of memory was, and it had to "table > scan" to find the address - that was deemed too ugly. > > -Kevin >