Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
> Gerd Hoffmann <kraxel@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?
> 
> Regards,
> 
> 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
very painful.

-- 
MST