On 3/05/2024 12:19 pm, Edgecombe, Rick P wrote:
On Sat, 2024-03-02 at 00:20 +1300, Kai Huang wrote:
For now the kernel only reads TDMR related global metadata fields for
module initialization. All these fields are 16-bits, and the kernel
only supports reading 16-bits fields.
KVM will need to read a bunch of non-TDMR related metadata to create and
run TDX guests. It's essential to provide a generic metadata read
infrastructure which supports reading all 8/16/32/64 bits element sizes.
Extend the metadata read to support reading all these element sizes.
It makes it sound like KVM needs 8 bit fields. I think it only needs 16 and 64.
(need to verify fully) But the code to support those can be smaller if it's
generic to all sizes.
It might be worth mentioning which fields and why to make it generic. To make
sure it doesn't come off as a premature implementation.
How about:
For now the kernel only reads TDMR related global metadata fields for
module initialization. All these fields are 16-bits, and the kernel
only supports reading 16-bits fields.
KVM will need to read a bunch of non-TDMR related metadata to create and
run TDX guests, and KVM will at least need to additionally be able to
read 64-bit metadata fields.
For example, the KVM will need to read the 64-bit ATTRIBUTES_FIXED{0|1}
fields to determine whether a particular attribute is legal when
creating a TDX guest. Please see 'global_metadata.json in [1] for more
information.
To resolve this once for all, extend the existing metadata reading code
to provide a generic metadata read infrastructure which supports reading
all 8/16/32/64 bits element sizes.
[1] https://cdrdv2.intel.com/v1/dl/getContent/795381
