[edk2-devel] Creating new target for Cloud Hypervisor

[Boeuf, Sebastien]

On Mon, 2022-01-10 at 11:45 +0100, kraxel at redhat.com wrote:
> 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.

Well I have a problem regarding SerialDxe because it breaks a bit QEMU
since adding it without removing the PciSerial registers two ways of
reading from serial. From microvm, you simply removed PciSerial since
you know it doesn't support LPC bridge, but I can't do the same here.
Can you think of any other way of properly handling this with a runtime
switch?

But more generally, things like the 8259 PIC, or PS2 keyboard are not
things that we try to support in Cloud Hypervisor, as well as Q35
specific bits being present in the target, meaning there's room for
simplification.

> 
> 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 (#85453): https://edk2.groups.io/g/devel/message/85453
Mute This Topic: https://groups.io/mt/88319600/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-