[SeaBIOS] KVM call agenda for 2013-05-28
Michael S. Tsirkin
mst at redhat.com
Wed May 29 18:28:05 CEST 2013
On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
> Gerd Hoffmann <kraxel at redhat.com> writes:
> > On 05/29/13 01:53, Kevin O'Connor wrote:
> >> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> >>> Juan is not available now, and Anthony asked for
> >>> agenda to be sent early.
> >>> So here comes:
> >>> Agenda for the meeting Tue, May 28:
> >>> - Generating acpi tables
> >> I didn't see any meeting notes, but I thought it would be worthwhile
> >> to summarize the call. This is from memory so correct me if I got
> >> anything wrong.
> >> Anthony believes that the generation of ACPI tables is the task of the
> >> firmware. Reasons cited include security implications of running more
> >> code in qemu vs the guest context,
> > I fail to see the security issues here. It's not like the apci table
> > generation code operates on untrusted input from the guest ...
> But possibly untrusted input from a malicious user. You can imagine
> something like a IaaS provider that let's a user input arbitrary values
> for memory, number of nics, etc.
> It's a stretch of an example, I agree, but the general principle I think
> is sound: we should push as much work as possible to the least
> privileged part of the stack. In this case, firmware has much less
> privileges than QEMU.
It's a big stretch. We have to draw the line somewhere, and I think
when *all* firmware people tell us that QEMU is a pain to work
with and should just supply ACPI table to BIOS, that line
has been crossed.
> >> complexities in running iasl on
> >> big-endian machines,
> > We already have a bunch of prebuilt blobs in the qemu repo for simliar
> > reasons, we can do that with iasl output too.
> >> possible complexity of having to regenerate
> >> tables on a vm reboot,
> > Why tables should be regenerated at reboot? I remember hotplug being
> > mentioned in the call. Hmm? Which hotplugged component needs acpi
> > table updates to work properly? And what is the point of hotplugging if
> > you must reboot the guest anyway to get the acpi updates needed?
> > Details please.
> See my response to Michael.
> > Also mentioned in the call: "architectural reasons", which I understand
> > as "real hardware works that way". Correct. But qemu's virtual
> > hardware is configurable in more ways than real hardware, so we have
> > different needs. For example: pci slots can or can't be hotpluggable.
> > On real hardware this is fixed. IIRC this is one of the reasons why we
> > have to patch acpi tables.
> It's not really fixed. Hardware supports PCI expansion chassises.
These normally aren't reported in ACPI, so no hotplug,
or only native hotplug.
> Multi-node NUMA systems also affect the ACPI tables.
In a very minor way.
> >> overall sloppiness of doing it in QEMU.
> > /me gets the feeling that this is the *main* reason, given that the
> > other ones don't look very convincing to me.
> >> Raised
> >> that QOM interface should be sufficient.
> > Agree on this one. Ideally the acpi table generation code should be
> > able to gather all information it needs from the qom tree, so it can be
> > a standalone C file instead of being scattered over all qemu.
> Ack. So my basic argument is why not expose the QOM interfaces to
> firmware and move the generation code there? Seems like it would be
> more or less a copy/paste once we had a proper implementation in QEMU.
Because that's just insanely rick interface we have no chance to
keep stable across versions.
Because it's a ton of QEMU specific firmware.
Because firmware devs don't want to maintain the ACPI that *is* there either.
> >> There were discussions on potentially introducing a middle component
> >> to generate the tables. Coreboot was raised as a possibility, and
> >> David thought it would be okay to use coreboot for both OVMF and
> >> SeaBIOS.
> > Certainly an option, but that is a long-term project.
> Out of curiousity, are there other benefits to using coreboot as a core
> firmware in QEMU?
> Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
> Anthony Liguori
The easier it is to switch firmware the better.
Gives us choice, we switched firmware several times,
we will do it again.
If firmware only has a simple loader for QEMU specific
stuff and is mostly generic, then it's easy.
If there's a lot of code for walking QOM, etc - it's
More information about the SeaBIOS