[edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
jejb at linux.ibm.com
Wed Jun 9 14:36:36 UTC 2021
On Wed, 2021-06-09 at 13:00 +0200, Laszlo Ersek wrote:
> On 06/09/21 02:58, Xu, Min M wrote:
> > On 06/09/2021 3:33 AM, Laszlo wrote:
> > > On 06/08/21 18:01, James Bottomley wrote:
> > > > On your slide 13 Question: "Open: How will the QEMU find the
> > > > metadata location?" can't you just use the mechanism for SEV
> > > > that's already upstream in both QEMU and OVMF?
> > >
> > > I think I made the same comment, in different words. (Point (12)
> > > at
> > > <https://listman.redhat.com/archives/edk2-devel-archive/2021-
> > > June/msg00143.html>.)
> > >
> > So my understanding to this solution is that:
> > 1) GUID-ed structure chain is started from a fixed GPA in
> > ResetVector.
> > 2) Append a TDX-specific GUID-ed structure in the chain
> > 3) Qemu search the GUID-ed chain from the fixed GPA and find the
> > TDX-specific GUID-ed structure based on TDX-specific GUID.
> > Is the expected process for QEMU?
> This is my understanding, yes; James will know more details though.
Pretty much, yes. The guided structure is designed as a backwards
table, so you can tell if it's present or not by looking for the table
guid (96b582de-1fb2-45f7-baea-a366c55a082d) at 0xffffffd0. If you find
that, it gives you the size of the table as the u16 preceding the GUID.
All entries are of the form
<variable size data> <u16 tot len inc guid> <guid>
You can see how it works in
Beginning around line 35.
In QEMU you want the function pc_system_ovmf_table_find() which is in
hw/i386/pc_sysfw.c and finds entries by guid.
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76278): https://edk2.groups.io/g/devel/message/76278
Mute This Topic: https://groups.io/mt/83283616/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
More information about the edk2-devel-archive