qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: seabios <seabios@seabios.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "Jordan Justen (Intel address)" <jordan.l.justen@intel.com>
Subject: [Qemu-devel] qemu / seabios ACPI table interface
Date: Fri, 22 Mar 2013 17:09:53 +0100	[thread overview]
Message-ID: <514C8251.8060209@redhat.com> (raw)

I'm confused. What are the requirements?

(1) should unpatched qemu work with patched seabios?
(2) should patched qemu work with unpatched seabios?

Considering patched qemu + patched seabios,
(3) should qemu dynamically control table origin/contents per table?
(4) should qemu be able to suppress/disable a seabios table via fw_cfg
without providing a replacement?

I had thought:
(1) yes (firmware upgrade on same hardware),
(2) no (hardware upgrade),
(3) yes (eases development and ultimately covers everything),
(4) no (*)

but apparently I'm wrong. I'm ready to be enlightened and try to
implement whatever the consensus is, but what is the consensus?

(*) For each table we can investigate why SeaBIOS provides it now:

- RSDP, RSDT, XSDT: These look like links-only tables. In general, links
(pointers) have to be updated by the firmware (eg. in the FADT), thus
qemu would provide zeros in those fields in general. Since these three
tables consist of nothing more than pointers, qemu would never provide
any of these tables. Choice between RSDT and XSDT is the jurisdiction of
the boot firmware, and it should choose exactly one. (SeaBIOS currently
uses RSDT, OVMF uses XSDT.)

- FADT (FACP): required by the spec. Qemu would either put up with
SeaBIOS's or provide a replacement.

- FACS: always prepared by the boot firmware.

- DSDT: Same as FADT.

- SSDT: a continuation of the DSDT; there can be several instances. If
the DSDT comes from qemu, SeaBIOS shouldn't install any SSDTs of its
own. Qemu won't provide SSDTs without its own DSDT.

- APIC (MADT): required in the "APIC interrupt model", which is probably
"always" for us. Hence same as with FADT/DSDT.

- HPET: Hardware dependent. If qemu doesn't provide the hardware, it
also wouldn't provide the table, and SeaBIOS already doesn't install one
itself because there's no hardware. If the hardware is there, qemu
provides the table, or puts up with SeaBIOS's.

- SRAT: Dependent on NUMA setup. Same case as with HPET.

- MCFG: Seems to depend on hardware (q35). Same as with HPET.

(I'll be out of the office next week -- if I don't follow up, that's the
reason.)

Thanks
Laszlo

             reply	other threads:[~2013-03-22 16:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-22 16:09 Laszlo Ersek [this message]
2013-03-22 17:16 ` [Qemu-devel] qemu / seabios ACPI table interface Paolo Bonzini
2013-03-22 23:59 ` Kevin O'Connor

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=514C8251.8060209@redhat.com \
    --to=lersek@redhat.com \
    --cc=jordan.l.justen@intel.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.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).