qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Pedro Falcato <pedro.falcato@gmail.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	 qemu-devel <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: TianoCore "Add QEMU support to MinPlatform (OpenQEMUBoardPkg)" GSoC project
Date: Mon, 23 May 2022 19:51:14 +0100	[thread overview]
Message-ID: <CAJSP0QUtgwqe7YYRPegB7gEKsPMzrTu1ZirXL4QGMN5dNgjo_A@mail.gmail.com> (raw)
In-Reply-To: <CAKbZUD3ObTfkdFebT1hJir-dYAH21BUsW6dX4wb-pgP8Ue3zrg@mail.gmail.com>

On Mon, 23 May 2022 at 19:00, Pedro Falcato <pedro.falcato@gmail.com> wrote:
>
> Hi Stefan, Gerd,
>
> Some questions: Is emulation of the current boards ever going to be expanded? For instance, can FW rely on the emulation being relatively simple or do you actually need to look at chipset docs?
> For example, I was looking at (most? all?) of the current chipset emulation [1] [2] and it looks relatively simple, such that writing something that directly interfaces with it isn't particularly hard.

I suggest a mix of referencing the hardware datasheets and open source
drivers or firmware code when developing new guest code.

Firmware should follow hardware datasheets and avoid taking relying on
QEMU implementation details.

fw_cfg and other paravirt interfaces that are documented won't change
in backwards incompatible ways. It's fine to rely on them.
QEMU-specific hardware interfaces are documented in docs/specs/ (e.g.
acpi_pci_hotplug.rst).

Anything that isn't documented may not be a stable interface. I
recommend discussing stabilization on qemu-devel before relying on it.

New QEMU versions do not change the hardware interfaces when launched
with a specific machine type version (e.g. -M pc-q35-6.2), so old
firmware should continue working under new QEMU versions as long as a
versioned machine type is specified on the command-line. But
undocumented QEMU hardware interfaces could change in new machine
types, so it's risky to rely on them.

> I've been trying to figure out exactly what one needs to do in FW to get a completely set up virtual machine environment. Are there good docs on that or do you need to just read OVMF/SeaBios code? Have interfaces changed significantly over the years?
> As an example, I remember seeing some OVMF CMOS memory detection shenanigans in the EDK2 mailing list but in my QEMU (7.0.0) you seem to just get the memory map straight from fw_cfg. Also, do you get ALL the ACPI tables from fw_cfg, or do you need to modify them/generate them dynamically in firmware?

Gerd can answer these questions. Please clarify which machine types
you are interested in (see the list from "qemu-system-x86_64 -machine
\?").

Stefan

> Hopefully my questions make sense. Feel free to CC qemu-devel if you think these questions are better suited there.
>
> Thanks,
> Pedro
>
> [1] https://github.com/qemu/qemu/blob/master/hw/isa/lpc_ich9.c
> [2] https://github.com/qemu/qemu/blob/master/hw/isa/piix4.c
>
> On Sat, May 21, 2022 at 8:58 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>
>> Hi,
>> I am a QEMU developer and saw the "Add QEMU support to MinPlatform
>> (OpenQEMUBoardPkg)" TianoCore GSoC project:
>> https://summerofcode.withgoogle.com/programs/2022/projects/s892c1ox
>>
>> You may already know each other from edk2, but in case not, I wanted
>> to introduce Gerd. He's doing edk2 work for QEMU and has been an
>> active QEMU developer for many years.
>>
>> Feel free to CC qemu-devel@nongnu.org if you ever want input or help
>> from the QEMU community.
>>
>> Have a great summer!
>>
>> Stefan
>
>
>
> --
> Pedro Falcato


           reply	other threads:[~2022-05-23 18:52 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CAKbZUD3ObTfkdFebT1hJir-dYAH21BUsW6dX4wb-pgP8Ue3zrg@mail.gmail.com>]

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-all 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=CAJSP0QUtgwqe7YYRPegB7gEKsPMzrTu1ZirXL4QGMN5dNgjo_A@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=isaac.w.oram@intel.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pedro.falcato@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /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;
as well as URLs for NNTP newsgroup(s).