From: "Laszlo Ersek" <lersek@redhat.com>
To: "Xu, Min M" <min.m.xu@intel.com>, Michael Brown <mcb30@ipxe.org>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Cc: "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"erdemaktas@google.com" <erdemaktas@google.com>,
"cho@microsoft.com" <cho@microsoft.com>,
"bret.barkelew@microsoft.com" <bret.barkelew@microsoft.com>,
Jon Lange <jlange@microsoft.com>, Karen Noel <knoel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Nathaniel McCallum <npmccallum@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Ademar de Souza Reis Jr." <areis@redhat.com>
Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
Date: Mon, 7 Jun 2021 15:52:16 +0200 [thread overview]
Message-ID: <d35bbefe-1bf9-5e81-f2f3-6787605d321a@redhat.com> (raw)
In-Reply-To: <PH0PR11MB50647DBD789DC1EEBDEE2626C5399@PH0PR11MB5064.namprd11.prod.outlook.com>
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
next prev parent reply other threads:[~2021-06-07 13:52 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 13:51 [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF Yao, Jiewen
2021-06-03 16:11 ` Laszlo Ersek
2021-06-03 23:19 ` Yao, Jiewen
2021-06-04 10:11 ` Laszlo Ersek
2021-06-04 10:24 ` Yao, Jiewen
2021-06-04 10:43 ` Michael Brown
2021-06-04 14:52 ` Michael Brown
2021-06-04 15:04 ` James Bottomley
2021-06-04 7:33 ` Min Xu
2021-06-06 2:03 ` Min Xu
2021-06-06 11:29 ` Michael Brown
2021-06-06 12:49 ` Min Xu
2021-06-07 13:52 ` Laszlo Ersek [this message]
2021-06-06 8:52 ` Min Xu
2021-06-06 11:39 ` Michael Brown
2021-06-08 12:27 ` Min Xu
2021-06-08 15:36 ` Laszlo Ersek
2021-06-08 16:01 ` James Bottomley
2021-06-08 19:33 ` Laszlo Ersek
2021-06-09 0:58 ` Min Xu
2021-06-09 11:00 ` Laszlo Ersek
2021-06-09 14:36 ` James Bottomley
2021-06-09 2:01 ` Min Xu
2021-06-09 14:28 ` James Bottomley
2021-06-09 15:47 ` Paolo Bonzini
2021-06-09 15:59 ` James Bottomley
2021-06-10 21:01 ` Erdem Aktas
2021-06-10 22:30 ` Min Xu
2021-06-11 1:33 ` James Bottomley
2021-06-11 1:36 ` Yao, Jiewen
2021-06-11 1:38 ` James Bottomley
2021-06-11 1:55 ` James Bottomley
[not found] ` <168759329436FBCF.5845@groups.io>
2021-06-11 6:37 ` Min Xu
2021-06-22 13:34 ` Laszlo Ersek
2021-06-22 13:38 ` Laszlo Ersek
2021-06-24 0:24 ` Min Xu
2021-06-24 0:35 ` James Bottomley
2021-06-24 0:55 ` Min Xu
[not found] ` <168B5EA81BA66FAC.7570@groups.io>
2021-07-01 5:00 ` Min Xu
2021-06-23 2:44 ` Min Xu
2021-06-23 17:47 ` Laszlo Ersek
2021-06-23 11:56 ` Min Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d35bbefe-1bf9-5e81-f2f3-6787605d321a@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox