Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification

["Yao, Jiewen" <jiewen.yao@intel.com>]

Yes, justification in bugzilla and README, please.

I suggestion you send a different email to ask the different topic - not distract people.


> -----Original Message-----
> From: Boeuf, Sebastien <sebastien.boeuf@intel.com>
> Sent: Wednesday, February 23, 2022 10:03 PM
> To: kraxel@redhat.com; Yao, Jiewen <jiewen.yao@intel.com>;
> devel@edk2.groups.io
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>
> Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot specification
> 
> On Wed, 2022-02-23 at 13:11 +0000, Yao, Jiewen wrote:
> > If you want to support PVH-only, that means you *defeature* the
> > CloudHv in *edk2-stable202202* tag according to
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-
> Planning
> > .
> > I hope that is stated clearly, with justification why we choose PVH-
> > only. Something like: "In edk2-stable202202, CloudHv supported xxx.
> > In edk2-stable202205 or future, CloudHv for non-TDX will only support
> > PVH, because xxxxxx. The CloudFv for TDX will continue support xxx."
> > An ASCII table is preferred to clarify the combination.
> 
> Sounds good. So all the justification should be part of the Bugzilla
> issue, right?
> 
> BTW, completely different topic, but wouldn't it be easier to use
> Github for tracking issues? I mean especially since it's already used
> for CI and Wiki.
> 
> >
> > If possible, please create a similar README under
> > https://github.com/tianocore/edk2/tree/master/OvmfPkg/CloudHv to
> > record such info. (configuration, feature, supported v.s.
> > unsupported, URL link, how to build, how to launch, etc)
> 
> Of course :)
> 
> >
> >
> > FYI: The readme in Microvm is a good example -
> > https://github.com/tianocore/edk2/blob/master/OvmfPkg/Microvm/README.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -----Original Message-----
> > > From: Boeuf, Sebastien <sebastien.boeuf@intel.com>
> > > Sent: Wednesday, February 23, 2022 8:20 PM
> > > To: kraxel@redhat.com; devel@edk2.groups.io
> > > Cc: Yao, Jiewen <jiewen.yao@intel.com>; Justen, Jordan L
> > > <jordan.l.justen@intel.com>
> > > Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot
> > > specification
> > >
> > > On Wed, 2022-02-23 at 13:02 +0100, kraxel@redhat.com wrote:
> > > >   Hi,
> > > >
> > > > > Well that's a good question. If we expect the same target
> > > > > (CloudHv)
> > > > > to
> > > > > support both TDX and non-TDX, that means the generated TDVF
> > > > > will be
> > > > > a
> > > > > PVH ELF binary, which will require some special handling from
> > > > > Cloud
> > > > > Hypervisor.
> > > > > Having two separate targets would simplify things a lot. What's
> > > > > the
> > > > > plan for QEMU? Will the same OVMF target cover both use cases?
> > > >
> > > > Yes, there will be a single binary supporting both tdx and non-
> > > > tdx,
> > > > some
> > > > configs add sev to the mix.  Doing the same for cloudhv shouldn't
> > > > be
> > > > much
> > > > of a problem I think.
> > > >
> > > > In tdx mode the firmware uses the tdhob for memory detection, in
> > > > non-
> > > > tdx
> > > > mode qemu fw_cfg is used instead.  The cloudhv build could switch
> > > > between tdhob and pvhinfo in a simliar way.
> > >
> > > Sounds good :)
> > >
> > > >
> > > > take care,
> > > >  Gerd
> > > >
> >