On 1/24/23 14:42, Tom Lendacky wrote:
>> Fedora has near zero additional patches, so it pretty much depends on
>> how mainline merges stuff. If SEV-SNP or TDX or both will land in an
>> upstream release before support for unaccepted memory lands too you'll
>
> Sorry, just saw this...
>
> SEV-SNP
;
dionnagl...@google.com ; dave.han...@linux.intel.com
; Yao, Jiewen ; Shutemov,
Kirill
主题: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior
On Wed, 25 Jan 2023 at 13:10, Gerd Hoffmann wrote:
>
> On Wed, Jan 25, 2023 at 12:44:13PM +0100, Ard Biesheuvel wrote:
> > On Wed,
On Wed, 25 Jan 2023 at 13:10, Gerd Hoffmann wrote:
>
> On Wed, Jan 25, 2023 at 12:44:13PM +0100, Ard Biesheuvel wrote:
> > On Wed, 25 Jan 2023 at 10:18, Gerd Hoffmann wrote:
> > >
> > > On Wed, Jan 25, 2023 at 10:01:47AM +0100, Ard Biesheuvel wrote:
> > >
> > > > Exactly. And my Fedora kernel has
On Wed, Jan 25, 2023 at 12:44:13PM +0100, Ard Biesheuvel wrote:
> On Wed, 25 Jan 2023 at 10:18, Gerd Hoffmann wrote:
> >
> > On Wed, Jan 25, 2023 at 10:01:47AM +0100, Ard Biesheuvel wrote:
> >
> > > Exactly. And my Fedora kernel has those bits enabled by default.
> > >
> > > So I suppose the way f
On Wed, 25 Jan 2023 at 10:18, Gerd Hoffmann wrote:
>
> On Wed, Jan 25, 2023 at 10:01:47AM +0100, Ard Biesheuvel wrote:
>
> > Exactly. And my Fedora kernel has those bits enabled by default.
> >
> > So I suppose the way forward here is to expose this protocol only on
> > OVMF builds that target SEV
On Wed, Jan 25, 2023 at 10:01:47AM +0100, Ard Biesheuvel wrote:
> Exactly. And my Fedora kernel has those bits enabled by default.
>
> So I suppose the way forward here is to expose this protocol only on
> OVMF builds that target SEV-SNP, instead of introducing it as a
> generic CoCo feature.
O
On Tue, 24 Jan 2023 at 23:42, Lendacky, Thomas via groups.io
wrote:
>
> On 1/16/23 04:28, Gerd Hoffmann via groups.io wrote:
> > On Fri, Jan 13, 2023 at 10:34:15AM -0800, Dave Hansen wrote:
> >> On 1/13/23 10:23, Dionna Glaze via groups.io wrote:
> However, *NONE* of this points me in the dir
On 1/16/23 04:28, Gerd Hoffmann via groups.io wrote:
On Fri, Jan 13, 2023 at 10:34:15AM -0800, Dave Hansen wrote:
On 1/13/23 10:23, Dionna Glaze via groups.io wrote:
However, *NONE* of this points me in the direction of saying that we
should have an OS/firmware protocol to negotiate whether the
On 1/13/23 09:06, Dionna Amalie Glaze wrote:
> Thanks for your perspective, Dave. From what I understand,
> distributions lag behind, user kernel configurations can be varied,
> and Kirill's patch set is still untested with regards to memory
> latency of workloads. We may yet see folks opt for a sl
On Fri, Jan 13, 2023 at 10:34:15AM -0800, Dave Hansen wrote:
> On 1/13/23 10:23, Dionna Glaze via groups.io wrote:
> >> However, *NONE* of this points me in the direction of saying that we
> >> should have an OS/firmware protocol to negotiate whether the firmware or
> >> OS does page acceptance oth
On 1/13/23 10:23, Dionna Glaze via groups.io wrote:
>> However, *NONE* of this points me in the direction of saying that we
>> should have an OS/firmware protocol to negotiate whether the firmware or
>> OS does page acceptance other than the existing UEFI memory map bit.
> We know of distributions
> Kirill's _initial_ patch does #1. If anyone desperately wants #2, they
> have mechanisms available to make a kernel with only #1 approximate #2.
> A user on that kernel could allocate and memset()ing a bunch of memory.
> Or, they could have a firmware stub accept the memory before booting the
>
Thanks for your perspective, Dave. From what I understand,
distributions lag behind, user kernel configurations can be varied,
and Kirill's patch set is still untested with regards to memory
latency of workloads. We may yet see folks opt for a slow boot for
better latency. This protocol is for safe
Hi Folks,
My hope (from the x86 side at least) was that all functional Linux TDX guests
will have memory acceptance support. We don't have fully-functional guest code
yet and assuming that Linux memory acceptance support will be in place before
we get there.
Basically, I was hoping that Linux
t; > Glaze ; Xu, Min M ; James
> > Bottomley ; Tom Lendacky
> > ; Aktas, Erdem ;
> > Andrew Fish ; Kinney, Michael D
> >
> > Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory
> > behavior
> >
> > On Fri, 13 Jan 2023 at 12:11, Yao
vel@edk2.groups.io; Gerd Hoffmann ; Dionna
> Glaze ; Xu, Min M ; James
> Bottomley ; Tom Lendacky
> ; Aktas, Erdem ;
> Andrew Fish ; Kinney, Michael D
>
> Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory
> behavior
>
> On Fri, 13 Jan 2023 at 12:11,
.io; Yao, Jiewen
> > Cc: Gerd Hoffmann ; Dionna Glaze
> > ; Xu, Min M ; James
> > Bottomley ; Tom Lendacky
> > ; Aktas, Erdem ;
> > Andrew Fish ; Kinney, Michael D
> >
> > Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory
> > behavio
Aktas, Erdem ;
> Andrew Fish ; Kinney, Michael D
>
> Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory
> behavior
>
> On Fri, 13 Jan 2023 at 08:33, Yao, Jiewen wrote:
> >
> > This is API between BIOS and OS.
> >
> > I would like to see sign-
> > Erdem ; Andrew Fish ; Kinney,
> > Michael D
> > Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory
> > behavior
> >
> > On Fri, Jan 13, 2023 at 03:46:34AM +, Yao, Jiewen wrote:
> > > Hi Dionna
> > > I think I understa
Ard Biescheuvel
> ; Xu, Min M ; James Bottomley
> ; Tom Lendacky ; Aktas,
> Erdem ; Andrew Fish ; Kinney,
> Michael D
> Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory
> behavior
>
> On Fri, Jan 13, 2023 at 03:46:34AM +, Yao, Jiewen wrote:
>
On Fri, Jan 13, 2023 at 03:46:34AM +, Yao, Jiewen wrote:
> Hi Dionna
> I think I understand your intention.
> I believe we need OS side and UEFI standard sign-off for this
> *BZ3987_MEMORY_ACCEPTANCE_PROTOCOL*, because OS is the consumer, right?
> If so, I suggest you maintain the work in a ed
Hi Dionna
I think I understand your intention.
I believe we need OS side and UEFI standard sign-off for this
*BZ3987_MEMORY_ACCEPTANCE_PROTOCOL*, because OS is the consumer, right?
If so, I suggest you maintain the work in a edk2-stage area for
https://github.com/tianocore/edk2-staging.
EDKII ma
22 matches
Mail list logo
