On Tue, Jun 02, 2015 at 10:28:52AM -0400, Stefan Berger wrote: > On 06/02/2015 09:30 AM, Michael S. Tsirkin wrote: > >On Tue, Jun 02, 2015 at 09:22:40AM -0400, Stefan Berger wrote: > >>On 06/02/2015 05:15 AM, Michael S. Tsirkin wrote: > >>>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 <stef...@linux.vnet.ibm.com> > >>>>>>Cc: Michael Tsirkin <m...@redhat.com> > >>>>>>Cc: Kevin O'Connor <ke...@koconnor.net> > >>>>>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? > >> > >>They won't persist. If one powers down the physical machine, this won't work > >>or not that I would know of that it would have to work. > >> > >> > >>>>>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. > >>> > >>How would the BIOS then find that memory (so it can read the command code > >>and act on it)? Would it need to walk ACPI tables or how would it find the > >>base address? > >> > >> Stefan > >This is similar to things like suspend/resume. > > > >The bios walks the list of the tables RSDP->XSDT, and locates the > >data table either by triple signature/vendorid/vendortableid, > >or by detecting a UEFI signature and locating the matching GUID > >(second option is preferable given current OVMF code). > > We would need to create an XSDT with at least two entries, one pointing to > the existing FADT (per spec) and one to this new table with what signature?
I think XSDT has same content as RSDT + new tables from ACPI 2 spec. > Do you have a pointer to a table structure identifiable by UEFI signature > and GUID to see how this looks like? Look it up in Appendix O (that a letter O, not zero) in the UEFI spec. > ACPI will identify it by triple > signature, though, right ? Should the XSDT always be there or only if we > have a TPM? I'm looking at adding it unconditionally, this let us use ACPI 2 funcitonality without crashing XP guests. > 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 > Would the ACPI code then internally walk the list of tables attached to the > XSDT and find the address of that table and make it available so that we can > define a Field() on it. Yes. > Assuming the DataTableRegion is called AAAA, would > we then define a Field(AAAA, AnyAcc,...) on it? Exactly. > Well, I am not sure how involved this is going to be, so maybe I would defer > this ACPI support for now unless we could live with the proposed solution > and UEFI could use it as well when run on QEMU. And I am glad that I haven't > converted the ASL to C code, because this would make it a lot more difficult > to develop and debug... > > Stefan
