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
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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86860): https://edk2.groups.io/g/devel/message/86860 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86870): https://edk2.groups.io/g/devel/message/86870 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86887): https://edk2.groups.io/g/devel/message/86887 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86902): https://edk2.groups.io/g/devel/message/86902 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86903): https://edk2.groups.io/g/devel/message/86903 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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 > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86907): https://edk2.groups.io/g/devel/message/86907 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86908): https://edk2.groups.io/g/devel/message/86908 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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 > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86909): https://edk2.groups.io/g/devel/message/86909 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86915): https://edk2.groups.io/g/devel/message/86915 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#87017): https://edk2.groups.io/g/devel/message/87017 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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 > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#87020): https://edk2.groups.io/g/devel/message/87020 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#87021): https://edk2.groups.io/g/devel/message/87021 Mute This Topic: https://groups.io/mt/89319389/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.