[edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

Laszlo Ersek lersek at redhat.com
Mon Jun 7 13:52:16 UTC 2021


On 06/06/21 14:49, Xu, Min M wrote:
> On June 6, 2021 7:30 PM, Michael Brown Wrote:
>> On 06/06/2021 03:03, Min Xu wrote:
>>>> (11) "Page table should support both 4-level and 5-level page table"
>>>>
>>>> As a general development strategy, I would suggest building TDX
>>>> support in small, well-isolated layers. 5-level paging is not enabled
>>>> (has never been tested, to my knowledge) with OVMF on QEMU/KVM,
>>>> regardless of confidential computing, for starters. If 5-level paging
>>>> is a strict requirement for TDX, then it arguably needs to be
>>>> implemented independently of TDX, at first. So that the common edk2
>>>> architecture be at least testable on QEMU/KVM with 5-level paging
>>>> enabled.
>>>>
>>> Yes, 5-level paging is a strict requirement for TDX. I would wait for
>>> the conclusion of the *one binary*.
>>
>> The "one binary" decision isn't relevant here, is it?  It would make more
>> sense to implement 5-level paging within the base EDK2 architecture.  This
>> would allow that feature to be tested in isolation from TDX (and
>> consequently tested more widely), and would reduce the distance between
>> standard builds and TDX builds.
>>
> 
> In our first version of TDVF, a static 5-level page table is used. It is simple and
> straight forward. But for *one binary* solution, we have to consider the compatibility
> with the current 4-level page table. That's why I said "I would wait for the conclusion
> of the *one binary*"
> 
> Thanks for the suggestion. We will discuss the it internally first.

My primary concern with the 5-level paging is not that the core
infrastructure is absent from edk2 -- it is present alright. (Over time,
numerous issues have been found and fixed in it, but that's kind of
expected, with such a big feature.) I understand it has been in use
successfully on a number of physical platforms.

My problem is that, AFAICT, the 5-level paging infrastructure of edk2
has never been *tested* on QEMU/KVM, as a part of OVMF. I have
absolutely no idea what to expect.

The "one binary" decision is a little bit relevant:

- If 5-level paging blows up on QEMU/KVM, as a part of OVMF, then
restricting the breakage (possibly a regression even?) to the new TDX
platform is good.

- On the other hand, both 5-level paging and TDX are complex in their
own rights; developing feature sets in small isolated waves is always
best. There are going to be "bug hunts" in the TDX platform of course;
finding an *orthogonal* 5-level paging bug (anywhere in the virt stack,
for that matter) is not the greatest outcome for a supposed TDX bug hunt.

- I figure users might want 5-level paging for OVMF at some point
anyway, even without TDX.

The last two points (especially the middle point of the three) kind of
outweigh(s) the first point for me.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76132): https://edk2.groups.io/g/devel/message/76132
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 mailing list