-----Original Message-----
From: Boeuf, Sebastien <sebastien.boeuf@...>
Sent: Wednesday, February 23, 2022 10:03 PM
To: kraxel@...; Yao, Jiewen <jiewen.yao@...>;
devel@edk2.groups.io
Cc: Justen, Jordan L <jordan.l.justen@...>
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@...>
Sent: Wednesday, February 23, 2022 8:20 PM
To: kraxel@...; devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Justen, Jordan L
<jordan.l.justen@...>
Subject: Re: [edk2-devel] [PATCH 0/3] CloudHv: Rely on PVH boot
specification

On Wed, 2022-02-23 at 13:02 +0100, kraxel@... 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