Hi Andrew, > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, July 06, 2017 4:46 PM > To: Jordan Justen <[email protected]> > Cc: Singh, Brijesh <[email protected]>; edk2-devel-01 <edk2- > [email protected]>; Lendacky, Thomas <[email protected]>; > Liming Gao <[email protected]>; Duran, Leo <[email protected]>; > Mike Kinney <[email protected]>; Jiewen Yao > <[email protected]>; Laszlo Ersek <[email protected]>; Jeff Fan > <[email protected]> > Subject: Re: [edk2] [PATCH v6 00/17] x86: Secure Encrypted Virtualization > (AMD) > > > > On Jul 6, 2017, at 2:42 PM, Jordan Justen <[email protected]> > wrote: > > > > On 2017-07-06 13:11:03, Brijesh Singh wrote: > >> > >> > >> On 07/06/2017 11:45 AM, Jordan Justen wrote: > >>> On 2017-07-05 15:31:20, Brijesh Singh wrote: > >>>> Hi Jordan and Laszlo, > >>>> > >>>> Ping. > >>>> > >>>> It has been a while, Do you have any further feedbacks on this series ? > >>>> If you want then I can rebase the patches before you commit into > upstream repos. > >>>> > >>> > >>> I'm still dissappointed by the APRIORI usage. > >>> > >>> As I understand it, you are also dissatisfied with this approach and > >>> you hope to improve things by somehow hooking into DXE Core. Is that > >>> true? If so, can you create a bugzilla regarding this feature? When > >>> would you plan to work to address that? > >>> > >> > >> I think we agree in that this particular use-case has shown the need > >> for re-thinking the existing GCD interface. However, the problem we > >> are trying to solve with this patch-set is enabling the SEV feature. > >> As it turns out, we can do so within the existing GCD framework by simply > leveraging the APRIORI hook already in use by OvmfPkg. > >> > >> In that context, our proposal is that we limit the scope of this > >> patch-set to simply enabling the SEV feature, and then allow the 'GCD > >> experts' to separately propose updates to the framework. > > > > This sounds like you don't plan to work on this, but will just leave > > it to the 'GCD experts'. Is that right? > > > > I am asking that you file and own a bugzilla for this. You'd obviously > > need to work with the package owners though. Unless you drive this, I > > don't think anyone will be motivated enough to get it fixed. > > > > If some one will make a write up on this mailing list summarizing the issue > with the GCD design, and what features are needed I can start a > conversation on the PI working group list. > > Thanks, > > Andrew Fish [Duran, Leo] Excellent proposal, thanks!
How about we do that on a separate thread (maybe with a reference back to this one, if needed for context)? Basically, we would like these patch-set to move upstream independent of the GCD write-up. I hope that's reasonable & agreeable by all. Leo. > > > -Jordan > > > >> > >>> I guess with that resolved, you could add an Acked-by from me. > >>> > >>> In general, it'd also be nice to move the processor features to more > >>> generic places, although that may be challenging if the next step is > >>> some kind of platform hook from DXE Core. Maybe if the DXE Core > >>> calls out to some protocol or signals an event then a driver in > >>> UefiCpuPkg could handle the protocol implementation to modify the > page tables. > >>> > >>> -Jordan > >>> > >>> > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
