[PATCH 0/3] CloudHv: Rely on PVH boot specification

[PATCH 0/3] CloudHv: Rely on PVH boot specification

[Boeuf, Sebastien]

From: Sebastien Boeuf <sebastien.boeuf@intel.com>

Cloud Hypervisor aims at emulating the minimal amount of legacy devices
and this is why the PVH boot specification is supported. The point is to
be able to share some information with the guest without the need for
emulating devices that would be present on real hardware.

Since Cloud Hypervisor supports loading a PVH ELF binary, the CloudHv
target is updated to be generated as such. Relying on the PVH boot
specification, we don't need to hardcode the location of the ACPI tables
anymore since we can retrieve the RSDP address from the hvm_start_info
structure. Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>

Sebastien Boeuf (3):
  OvmfPkg: Generate CloudHv as a PVH ELF binary
  OvmfPkg: CloudHv: Retrieve RSDP address from PVH
  OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS

 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c       |  39 +++--
 OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c | 150 ++++++++++++++++++++
 OvmfPkg/CloudHv/CloudHvX64.dsc              |   2 +-
 OvmfPkg/CloudHv/CloudHvX64.fdf              |  95 ++++++++++++-
 OvmfPkg/Include/IndustryStandard/CloudHv.h  |   5 -
 OvmfPkg/PlatformPei/MemDetect.c             |  73 ++++++++++
 OvmfPkg/PlatformPei/PlatformPei.inf         |   2 +
 8 files changed, 348 insertions(+), 20 deletions(-)
 create mode 100644 OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c

-- 
2.32.0

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[Yao, Jiewen]

HI Sebastien
Here is some feedback.

1) Since this seems a new feature, would you please file a Bugzilla https://bugzilla.tianocore.org/ ?

2) Please also include this new feature in release plan - https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning ?

3) A clarification question: Do you want to *only* support PVH boot in CloudHv, or PVH is one option and you still support old way?

4) Please clarify if that impacts the support for TDVF.

Thank you
Yao, Jiewen

> -----Original Message-----
> From: Boeuf, Sebastien <sebastien.boeuf@intel.com>
> Sent: Tuesday, February 22, 2022 11:53 PM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen <jiewen.yao@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; kraxel@redhat.com; Boeuf, Sebastien
> <sebastien.boeuf@intel.com>
> Subject: [PATCH 0/3] CloudHv: Rely on PVH boot specification
> 
> From: Sebastien Boeuf <sebastien.boeuf@intel.com>
> 
> Cloud Hypervisor aims at emulating the minimal amount of legacy devices
> and this is why the PVH boot specification is supported. The point is to
> be able to share some information with the guest without the need for
> emulating devices that would be present on real hardware.
> 
> Since Cloud Hypervisor supports loading a PVH ELF binary, the CloudHv
> target is updated to be generated as such. Relying on the PVH boot
> specification, we don't need to hardcode the location of the ACPI tables
> anymore since we can retrieve the RSDP address from the hvm_start_info
> structure. Same thing for the RAM below 4G, we can find this information
> through the PVH memmap entries rather than relying on the emulated CMOS.
> 
> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
> 
> Sebastien Boeuf (3):
>   OvmfPkg: Generate CloudHv as a PVH ELF binary
>   OvmfPkg: CloudHv: Retrieve RSDP address from PVH
>   OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS
> 
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
>  OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c       |  39 +++--
>  OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c | 150
> ++++++++++++++++++++
>  OvmfPkg/CloudHv/CloudHvX64.dsc              |   2 +-
>  OvmfPkg/CloudHv/CloudHvX64.fdf              |  95 ++++++++++++-
>  OvmfPkg/Include/IndustryStandard/CloudHv.h  |   5 -
>  OvmfPkg/PlatformPei/MemDetect.c             |  73 ++++++++++
>  OvmfPkg/PlatformPei/PlatformPei.inf         |   2 +
>  8 files changed, 348 insertions(+), 20 deletions(-)
>  create mode 100644 OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
> 
> --
> 2.32.0

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

[Boeuf, Sebastien]

Hi Jiewen,

On Wed, 2022-02-23 at 00:00 +0000, Yao, Jiewen wrote:
> HI Sebastien
> Here is some feedback.
> 
> 1) Since this seems a new feature, would you please file a Bugzilla
> https://bugzilla.tianocore.org/ ?

Ok I will. Just need to wait for my account to be created.

> 
> 2) Please also include this new feature in release plan -
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>  ?

Sure, I'll add a new entry in there, with the link to the bug in
Bugzilla.

> 
> 3) A clarification question: Do you want to *only* support PVH boot
> in CloudHv, or PVH is one option and you still support old way?

We want to support PVH only. No need for the legacy support. Unless you
can think of a good reason to do so?

> 
> 4) Please clarify if that impacts the support for TDVF.

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?

Thanks,
Sebastien

> 
> Thank you
> Yao, Jiewen
> 
> > -----Original Message-----
> > From: Boeuf, Sebastien <sebastien.boeuf@intel.com>
> > Sent: Tuesday, February 22, 2022 11:53 PM
> > To: devel@edk2.groups.io
> > Cc: Yao, Jiewen <jiewen.yao@intel.com>; Justen, Jordan L
> > <jordan.l.justen@intel.com>; kraxel@redhat.com; Boeuf, Sebastien
> > <sebastien.boeuf@intel.com>
> > Subject: [PATCH 0/3] CloudHv: Rely on PVH boot specification
> > 
> > From: Sebastien Boeuf <sebastien.boeuf@intel.com>
> > 
> > Cloud Hypervisor aims at emulating the minimal amount of legacy
> > devices
> > and this is why the PVH boot specification is supported. The point
> > is to
> > be able to share some information with the guest without the need
> > for
> > emulating devices that would be present on real hardware.
> > 
> > Since Cloud Hypervisor supports loading a PVH ELF binary, the
> > CloudHv
> > target is updated to be generated as such. Relying on the PVH boot
> > specification, we don't need to hardcode the location of the ACPI
> > tables
> > anymore since we can retrieve the RSDP address from the
> > hvm_start_info
> > structure. Same thing for the RAM below 4G, we can find this
> > information
> > through the PVH memmap entries rather than relying on the emulated
> > CMOS.
> > 
> > Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
> > 
> > Sebastien Boeuf (3):
> >   OvmfPkg: Generate CloudHv as a PVH ELF binary
> >   OvmfPkg: CloudHv: Retrieve RSDP address from PVH
> >   OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS
> > 
> >  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
> >  OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c       |  39 +++--
> >  OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c | 150
> > ++++++++++++++++++++
> >  OvmfPkg/CloudHv/CloudHvX64.dsc              |   2 +-
> >  OvmfPkg/CloudHv/CloudHvX64.fdf              |  95 ++++++++++++-
> >  OvmfPkg/Include/IndustryStandard/CloudHv.h  |   5 -
> >  OvmfPkg/PlatformPei/MemDetect.c             |  73 ++++++++++
> >  OvmfPkg/PlatformPei/PlatformPei.inf         |   2 +
> >  8 files changed, 348 insertions(+), 20 deletions(-)
> >  create mode 100644 OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
> > 
> > --
> > 2.32.0
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[Gerd Hoffmann]

  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.

take care,
 Gerd

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

[Boeuf, Sebastien]

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
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[Yao, Jiewen]

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.

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)


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
> >

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

[Boeuf, Sebastien]

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
> > > 
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[Yao, Jiewen]

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
> > > >
> >

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

[Boeuf, Sebastien]

On Wed, 2022-02-23 at 14:14 +0000, Yao, Jiewen wrote:
> Yes, justification in bugzilla and README, please.

I've just submitted a v2 patchset including the README, let me know
what you think about it.

I'm still waiting for my Bugzilla account to be created.

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

Sorry, I'll send a separate email.

Thanks,
Sebastien
> 
> 
> > -----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
> > > > > 
> > > 
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[Boeuf, Sebastien]

On Wed, 2022-02-23 at 14:14 +0000, Yao, Jiewen wrote:
> Yes, justification in bugzilla and README, please.

I've just created a bug in Bugzilla:
https://bugzilla.tianocore.org/show_bug.cgi?id=3848

But I don't have the permissions to edit the wiki
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning

Do I need to send a PR to update the wiki?

> 
> 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
> > > > > 
> > > 
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[Yao, Jiewen]

I updated release planning page for you.

Thank you
Yao Jiewen


> -----Original Message-----
> From: Boeuf, Sebastien <sebastien.boeuf@intel.com>
> Sent: Friday, February 25, 2022 7:10 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 14:14 +0000, Yao, Jiewen wrote:
> > Yes, justification in bugzilla and README, please.
> 
> I've just created a bug in Bugzilla:
> https://bugzilla.tianocore.org/show_bug.cgi?id=3848
> 
> But I don't have the permissions to edit the wiki
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
> 
> Do I need to send a PR to update the wiki?
> 
> >
> > 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
> > > > > >
> > > >
> >

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

[Boeuf, Sebastien]

[-- Attachment #1: Type: text/plain, Size: 5633 bytes --]

Thank you Jiewen :)
________________________________
From: Yao, Jiewen <jiewen.yao@intel.com>
Sent: Friday, February 25, 2022 3:21 PM
To: Boeuf, Sebastien <sebastien.boeuf@intel.com>; kraxel@redhat.com <kraxel@redhat.com>; devel@edk2.groups.io <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

I updated release planning page for you.

Thank you
Yao Jiewen


> -----Original Message-----
> From: Boeuf, Sebastien <sebastien.boeuf@intel.com>
> Sent: Friday, February 25, 2022 7:10 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 14:14 +0000, Yao, Jiewen wrote:
> > Yes, justification in bugzilla and README, please.
>
> I've just created a bug in Bugzilla:
> https://bugzilla.tianocore.org/show_bug.cgi?id=3848
>
> But I don't have the permissions to edit the wiki
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>
> Do I need to send a PR to update the wiki?
>
> >
> > 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
> > > > > >
> > > >
> >

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #2: Type: text/html, Size: 8996 bytes --]