public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Boeuf, Sebastien" <sebastien.boeuf@intel.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 12:54:30 +0100	[thread overview]
Message-ID: <20220110115430.abcu55ox5l44bajl@sirius.home.kraxel.org> (raw)
In-Reply-To: <145e521b95cb383c1f343d46acca2faf70fad761.camel@intel.com>

  Hi,

> > 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.

Gotcha.

> 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?

Well, tianocore isn't really designed for this.  Typically image builds
have to handle one specific platform only, so that kind of runtime
switches is not needed and support for it is not really present in
tianocore.

Virtualization is kind of special here as we have a single build
supporting multiple platforms (pc & q35 qemu machine types with various
config variants like sev/tdx on/off) to avoid the number of builds for
qemu explode and to make things less confusing for users.

So the ovmf runtime checks are open-coded in many places (all those
switch (mHostBridgeDevId) statements for example).  There is
ovmf-specific code for PCI where alot of the code only exists to
allow for runtime-switching between PCI (pc) and PCIe (q35).

So, yes, I guess it makes sense to have a separate target.  Avoids the
Serial issue, you can drop drivers, you can probably also simplify PCI
as I suspect you don't need the PCI/PCIe runtime switching, ...

take care,
  Gerd


      reply	other threads:[~2022-01-10 11:54 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
2022-01-10 11:54     ` Gerd Hoffmann [this message]

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=20220110115430.abcu55ox5l44bajl@sirius.home.kraxel.org \
    --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