On 05/15/18 14:30, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > Hi, > > The following series adds basic TPM PPI 1.3 support for OVMF-on-QEMU > with TPM2 (I haven't tested TPM1, for lack of interest). > > PPI test runs successfully with Windows 10 WHLK, despite the limited > number of supported funcions (tpm2_ppi_funcs table, in particular, no > function allows to manipulate Tcg2PhysicalPresenceFlags) > > The way it works is relatively simple: a memory region is allocated by > QEMU to save PPI related variables. An ACPI interface is exposed by > QEMU to let the guest manipulate those. At boot, ovmf processes and > updates the PPI qemu region and request variables. > > I build edk2 with: > > $ build -DTPM2_ENABLE -DSECURE_BOOT_ENABLE
Is -DSECURE_BOOT_ENABLE necessary for *building* with -DTPM2_ENABLE? If that's the case, we should update the DSC files; users building OVMF from source shouldn't have to care about "-D" inter-dependencies, if we can manage that somehow. If -DSECURE_BOOT_ENABLE is only there because otherwise a guest OS doesn't really make use of -DTPM2_ENABLE either, that's different. In that case, it's fine to allow building OVMF with TPM2 support but without SB support. Thanks! Laszlo
