Re: [PATCH v6 00/17] x86: Secure Encrypted Virtualization (AMD)

["Duran, Leo" <leo.duran@amd.com>]

Hi Andrew, 

> -----Original Message-----
> From: afish@apple.com [mailto:afish@apple.com]
> Sent: Thursday, July 06, 2017 4:46 PM
> To: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Singh, Brijesh <brijesh.singh@amd.com>; edk2-devel-01 <edk2-
> devel@lists.01.org>; Lendacky, Thomas <Thomas.Lendacky@amd.com>;
> Liming Gao <liming.gao@intel.com>; Duran, Leo <leo.duran@amd.com>;
> Mike Kinney <michael.d.kinney@intel.com>; Jiewen Yao
> <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Jeff Fan
> <jeff.fan@intel.com>
> Subject: Re: [edk2] [PATCH v6 00/17] x86: Secure Encrypted Virtualization
> (AMD)
> 
> 
> > On Jul 6, 2017, at 2:42 PM, Jordan Justen <jordan.l.justen@intel.com>
> 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
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel