public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Boeuf, Sebastien" <sebastien.boeuf@intel.com>
To: "kraxel@redhat.com" <kraxel@redhat.com>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: Creating new target for Cloud Hypervisor
Date: Mon, 10 Jan 2022 11:03:27 +0000	[thread overview]
Message-ID: <145e521b95cb383c1f343d46acca2faf70fad761.camel@intel.com> (raw)
In-Reply-To: <20220110104542.hrfoi5ndwdeh3lal@sirius.home.kraxel.org>

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

  reply	other threads:[~2022-01-10 11:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-10  9:13 Creating new target for Cloud Hypervisor Boeuf, Sebastien
2022-01-10 10:35 ` Yao, Jiewen
2022-01-10 10:45   ` Boeuf, Sebastien
2022-01-10 10:45 ` Gerd Hoffmann
2022-01-10 11:03   ` Boeuf, Sebastien [this message]
2022-01-10 11:54     ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=145e521b95cb383c1f343d46acca2faf70fad761.camel@intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox