From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YziIJ-0005zr-OE for qemu-devel@nongnu.org; Tue, 02 Jun 2015 05:15:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YziID-0005Fr-MI for qemu-devel@nongnu.org; Tue, 02 Jun 2015 05:15:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YziID-0005Fi-Hb for qemu-devel@nongnu.org; Tue, 02 Jun 2015 05:15:29 -0400 Date: Tue, 2 Jun 2015 11:15:25 +0200 From: "Michael S. Tsirkin" Message-ID: <20150602110702-mutt-send-email-mst@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556D1EDE.8060100@linux.vnet.ibm.com> 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: Stefan Berger Cc: imammedo@redhat.com, Kevin O'Connor , qemu-devel@nongnu.org, quan.xu@intel.com On Mon, Jun 01, 2015 at 11:11:26PM -0400, Stefan Berger wrote: > On 05/31/2015 02:11 PM, Michael S. Tsirkin wrote: > >On Tue, May 26, 2015 at 05:33:41PM -0400, Stefan Berger wrote: > >>For automated management of a TPM device, implement the TCG Physical Presence > >>Interface Specification that allows a root user on Linux (for example) to set > >>an opcode for a sequence of TPM operations that the BIOS is supposed to execute > >>upon reboot of the physical or virtual machine. A sequence of operations may for > >>example involve giving up ownership of the TPM and activating and enabling the > >>device. > >> > >>The sequences of operations are defined in table 2 in the specs to be found > >>at the following link: > >> > >>http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification > >> > >>As an example, in recent versions of Linux the opcode (5) can be set as > >>follows: > >> > >>cd /sys/devices/pnp0/00\:04/ppi > >> > >>echo 5 > request > >> > >>This ACPI implementation assumes that the underlying firmware (SeaBIOS) > >>has 'thrown an anchor' into the f-segment. The anchor is identified by > >>two signatures (TCG_MAGIC) surrounding a 64bit pointer. The structure > >>in the f-segment is write-protected and holds a pointer to a structure > >>in high memmory > >memory > > > >>area where the ACPI code writes the opcode into and > >>where it can read the last response from the BIOS. > >> > >>The supported opcodes are 1-11, 14, and 21-22. (see table 2 in spec) > >>Also '0' is supported to 'clear' an intention. > >> > >> > >No need for 2 empty spaces. > > > >>Signed-off-by: Stefan Berger > >>Cc: Michael Tsirkin > >>Cc: Kevin O'Connor > >All this seems somewhat messy. Is this FSEG trick what the spec says, > >or is this a QEMU specific protocol? > > Actually, the text in the patch is outdated. We now moved the area where the > data are exchanged between ACPI and BIOS into registers provided by the TIS > -- custom registers in an area that is vendor-specific, so yes, this is a > QEMU specific solution. The address range for this is fixed and known to > SeaBIOS and QEMU. Those registers also won't reset upon machine reboot. Hmm. One way to do a machine reboot is to exit QEMU then restart it. Where do these registers persist? > >Would DataTableRegion not be a better way to locate things in > >memory? > > As I said, we now move that into a memory region provide by the TIS.. > Otherwise I am not very familiar with DataTableRegion. > > Thanks for the comments! > > Stefan A data table is a structure that you define (as opposed to code). Using linker you can allocate some memory and put a pointer there, then use DataTableRegion to read that pointer value. -- MST