Re: Creating new target for Cloud Hypervisor

["Gerd Hoffmann" <kraxel@redhat.com>]

On Mon, Jan 10, 2022 at 09:13:44AM +0000, Boeuf, Sebastien wrote:
> Hi all,
> 
> So far I've been able to patch the OvmfPkgX64 target to make it work for both
> QEMU and Cloud Hypervisor, but as I try to enable more features (EFI shell for
> instance) the gap is getting bigger and harder to keep them working together.
> 
> That's why I'm thinking about creating an OvmfCh target that would be a simple
> copy of OvmfX64 at first, and then we could keep improving from there. There are
> multiple things that are not needed by Cloud Hypervisor, which might help reduce
> the complexity of the firmware, eventually leading to faster boot.
> 
> I'd like some confirmation from the community that it's okay to go down this road
> before I proceed and send the patches.

Well, depends.  A separate target is extra maintainance effort.  But
having to write code for runtime-switching where compile-time switching
would work without additional code is extra maintainance effort too ...

For microvm pci support (not yet merged) tipped things towards a
separate target.  pcie in microvm works completely different when
compared to pc/q35.  Using mmconfig for pci config space access is
mandatory, port 0xcf8 is not supported.  So fitting that with a runtime
switch into OvmfPkg/Library/DxePciLibI440FxQ35 (and probably some other
places) would have been quite messy, with a separate target is is *alot*
easier.

Quite a few places use a runtime switch nevertheless to avoid code
duplication.  PlatformPei for example is identical for both OvmfPkgX64
and MicrovmX86 targets, with case: branches for microvm in switch
statements.

So, what problem you are facing which makes you think a separate target
would work better?  The timer thing should be a non-issue as we plan to
switch over OvmfPkgX64 to use apic timer anyway.

take care,
  Gerd