Thanks much everyone who attended 2 sessions of TDVF design review meeting
and lots of valuable comments and feedbacks received. These 2 meetings were
recorded and now uploaded to below link:
Session 1:
https://drive.google.com/file/d/100__tNVe5erNzExySq2SJOprvBN7zz8u/view?usp=sharing
Session 2:
On 06/24/2021 8:36 AM, James Bottomley wrote:
> On Thu, 2021-06-24 at 00:24 +, Min Xu wrote:
> > On 06/22/2021 9:39 PM, Laszlo wrote:
> > > I should clarify: the relevant part of my preference is not that
> > > "IntelTdx.dsc"
> > > contain the *complete* TDVF feature set. The relevant part
On Thu, 2021-06-24 at 00:24 +, Min Xu wrote:
> On 06/22/2021 9:39 PM, Laszlo wrote:
> > I should clarify: the relevant part of my preference is not that
> > "IntelTdx.dsc"
> > contain the *complete* TDVF feature set. The relevant part (for me)
> > is that
> > "OvmfPkgX64.dsc" *not* be
On 06/22/2021 9:39 PM, Laszlo wrote:
>
> I should clarify: the relevant part of my preference is not that
> "IntelTdx.dsc"
> contain the *complete* TDVF feature set. The relevant part (for me) is that
> "OvmfPkgX64.dsc" *not* be over-complicated for the sake of TDX, even
> considering only the
On 06/23/21 04:44, Xu, Min M wrote:
> On 06/22/2021 9:35 PM, Laszlo wrote:
>>
>> For example, as I stated earlier, "OvmfPkg/AcpiPlatformDxe" is a
>> driver where I'd like to see zero changes, for either SEV or TDX. If
>> the TD Mailbox location has to be reported to the OS via the MADT,
>> and
On 06/22/2021 9:35 PM, Laszlo wrote:
> Hi,
>
> On 06/11/21 08:37, Xu, Min M wrote:
> > In today's TianoCore Design Meeting we reviewed the Overview Section
> (from slide 1 to 20). Thanks much for the valuable feedbacks and comments.
> The meeting minutes will be sent out soon.
> >
> > To address
On 06/22/2021 9:35 PM, Laszlo wrote:
>
> For example, as I stated earlier, "OvmfPkg/AcpiPlatformDxe" is a driver where
> I'd like to see zero changes, for either SEV or TDX. If the TD Mailbox
> location has
> to be reported to the OS via the MADT, and QEMU cannot (or must not)
> populate that
like to see zero changes, for either SEV or TDX. If the TD
> Mailbox location has to be reported to the OS via the MADT, and QEMU
> cannot (or must not) populate that field in the MADT, then a separate,
> TDX-specific edk2 driver should locate the MADT (installed technically
> by &quo
Pkg/AcpiPlatformDxe", earlier), and update the field.
Thanks,
Laszlo
> From: devel@edk2.groups.io On Behalf Of Min Xu
> Sent: Friday, June 11, 2021 6:30 AM
> To: devel@edk2.groups.io; Yao, Jiewen ;
> r...@edk2.groups.io
> Cc: j...@linux.ibm.com; Laszlo Ersek ; Brijesh Singh
> ; T
...@linux.ibm.com; Laszlo Ersek ; Brijesh Singh
; Tom Lendacky ;
erdemak...@google.com; c...@microsoft.com; bret.barke...@microsoft.com; Jon
Lange ; Karen Noel ; Paolo Bonzini
; Nathaniel McCallum ; Dr. David
Alan Gilbert ; Ademar de Souza Reis Jr.
Subject: Re: [edk2-rfc] [edk2-devel] RFC
On Thu, 2021-06-10 at 21:38 -0400, James Bottomley wrote:
> On Fri, 2021-06-11 at 01:36 +, Yao, Jiewen wrote:
> > Hi James.
> > I attached the invitation and copied all content below:
> >
> > ==
> > ## TOPIC
> >
> > 1. NA
> >
> > For more info, see here:
On Fri, 2021-06-11 at 01:36 +, Yao, Jiewen wrote:
> Hi James.
> I attached the invitation and copied all content below:
>
> ==
> ## TOPIC
>
> 1. NA
>
> For more info, see here: https://www.tianocore.org/design-meeting/
>
> ---
> ## Microsoft Teams meeting
>
Gilbert ; Ademar de Souza Reis Jr.
>
> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
>
> On Thu, 2021-06-10 at 22:30 +, Xu, Min M wrote:
> > Hi, All
> > Thanks much for the valuable comments and discussion about the
> > design.
> &
On Thu, 2021-06-10 at 22:30 +, Xu, Min M wrote:
> Hi, All
> Thanks much for the valuable comments and discussion about the
> design.
> We have updated the slides (v0.9) in below link. If some comments or
> concerns are not answered/addressed in the new slides, please don't
> hesitate to tell
Hi, All
Thanks much for the valuable comments and discussion about the design.
We have updated the slides (v0.9) in below link. If some comments or concerns
are not answered/addressed in the new slides, please don't hesitate to tell us.
We do want to answer/address all the comments/concerns. But
Hi all,
Sorry for the late reply. I like to add some clarification on "one
binary". I feel like the way everyone uses the term "one binary" in
the email threads is causing some confusion.
As I have tried to explain before, we are not looking for everything
in a single binary. As Laszlo has
On Wed, 2021-06-09 at 17:47 +0200, Paolo Bonzini wrote:
> On 09/06/21 16:28, James Bottomley wrote:
> > That would cut across the ApEntrypoint and the guidedStructureEnd.
> > However, nothing says anything in the reset vector guided structure
> > has to be data ... so it could equally well be
On 09/06/21 16:28, James Bottomley wrote:
That would cut across the ApEntrypoint and the guidedStructureEnd.
However, nothing says anything in the reset vector guided structure has
to be data ... so it could equally well be code. That means we can do
guid based entries that contain the 32 bit
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
On Wed, 2021-06-09 at 02:01 +, Xu, Min M wrote:
> On 06/09/2021 12:01 AM, James Bottomley wrote:
[...]
> > On slide 19, the mucking with the reset vector really worries me
> > because we don't have that much space to play with. Given that
> > you're starting in 32 bit mode and can thus enter
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
On 06/09/2021 12:01 AM, James Bottomley wrote:
> It looks like I'll be travelling that day, but should be able to attend at
> least the
> first 45 minutes of the design review from the airport lounge.
>
Thanks much James!
> On TdMailbox and TdHob, we already have two SEV pages in the MEMFD and
On 06/09/2021 3:33 AM, Laszlo wrote:
> (Min Xu got dropped from the CC list for some reason, at *some* point in this
> sub-thread! Not sure when. Re-adding him.)
>
> Commenting on excerpts:
>
> On 06/08/21 18:01, James Bottomley wrote:
>
> > On TdMailbox and TdHob, we already have two SEV pages
(Min Xu got dropped from the CC list for some reason, at *some* point in
this sub-thread! Not sure when. Re-adding him.)
Commenting on excerpts:
On 06/08/21 18:01, James Bottomley wrote:
> On TdMailbox and TdHob, we already have two SEV pages in the MEMFD and
> since TDX and SEV is an
On Thu, 2021-06-03 at 13:51 +, Yao, Jiewen wrote:
> Hi, All
> We plan to do a design review for TDVF in OVMF package.
>
>
> The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11)
> is now available in blow link:
> https://edk2.groups.io/g/devel/files/Designs/2021/0611.
>
> The
On 06/08/21 14:27, Xu, Min M wrote:
> On 06/04/2021 12:12 AM, Laszlo wrote:
>> But it counts as an absolute disaster nowadays, and should not be revived in
>> any platform. If you don't have pflash in TDX guests, just accept that you
>> won't have non-volatile variables. And link
On 06/04/2021 12:12 AM, Laszlo wrote:
> (22) EmuVariableFvbRuntimeDxe
>
> Ouch, this is an unpleasant surprise.
>
> First, if you know for a fact that pflash is not part of the *board* in any
> TDX
> setup, then pulling
>
> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
>
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,
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
On 06/06/2021 09:52, Min Xu wrote:
On June 4, 2021 12:12 AM, Laszlo wrote:
(18) says "SMM is not supported in Td guest" -- how is the variable store
protected from direct hardware (pflash) access from the guest OS?
Without SMM, the guest OS need not go through gRT->SetVariable() to
update
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
On June 4, 2021 12:12 AM, Laszlo wrote:
> On 06/03/21 15:51, Yao, Jiewen wrote:
> > Hi, All
> > We plan to do a design review for TDVF in OVMF package.
> >
> >
> > The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11) is
> > now available in blow link:
> >
On June 4, 2021 12:12 AM, Laszlo wrote:
> On 06/03/21 15:51, Yao, Jiewen wrote:
> > Hi, All
> > We plan to do a design review for TDVF in OVMF package.
> >
> >
> > The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11) is
> > now available in blow link:
> >
On Fri, 2021-06-04 at 15:52 +0100, Michael Brown wrote:
> On 04/06/2021 11:43, Michael Brown wrote:
> > On 04/06/2021 11:11, Laszlo Ersek wrote:
> > > And, to reiterate, just because Confidential Computing is the
> > > new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64,
> > > OvmfPkgX64
On 04/06/2021 11:43, Michael Brown wrote:
On 04/06/2021 11:11, Laszlo Ersek wrote:
And, to reiterate, just because Confidential Computing is the
new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64
do not disappear. Regressing them, or making them unmaintainable due to
On 04/06/2021 11:11, Laszlo Ersek wrote:
And, to reiterate, just because Confidential Computing is the
new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64
do not disappear. Regressing them, or making them unmaintainable due to
skyrocketing complexity, is not acceptable.
en
>> with only SEV in mind; that's why "OvmfPkg/AmdSev/AmdSevX64.dsc" exists.
>> =======
>>
>> Thank you
>> Yao Jiewen
>>
>>> -Original Message-
>>> From: r...@edk2.groups.io On Behalf Of Laszlo Ersek
>>
o;
>> devel@edk2.groups.io
>> Cc: j...@linux.ibm.com; Brijesh Singh ; Tom
>> Lendacky ; erdemak...@google.com;
>> c...@microsoft.com; bret.barke...@microsoft.com; Jon Lange
>> ; Karen Noel ; Paolo Bonzini
>> ; Nathaniel McCallum ;
>> Dr. David Alan Gilbert ; Ademar de
On 06/04/2021 12:12 AM, Laszlo wrote:
> On 06/03/21 15:51, Yao, Jiewen wrote:
> > Hi, All
> > We plan to do a design review for TDVF in OVMF package.
> >
> >
> > The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11) is
> > now available in blow link:
> >
roups.io
> Cc: j...@linux.ibm.com; Brijesh Singh ; Tom
> Lendacky ; erdemak...@google.com;
> c...@microsoft.com; bret.barke...@microsoft.com; Jon Lange
> ; Karen Noel ; Paolo Bonzini
> ; Nathaniel McCallum ;
> Dr. David Alan Gilbert ; Ademar de Souza Reis Jr.
>
> Subject: Re: [e
On 06/03/21 15:51, Yao, Jiewen wrote:
> Hi, All
> We plan to do a design review for TDVF in OVMF package.
>
>
> The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11) is
> now available in blow link:
> https://edk2.groups.io/g/devel/files/Designs/2021/0611.
>
> The Bugzilla is
41 matches
Mail list logo
