Re: KVM call agenda for 2013-05-28

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

On Wed, May 29, 2013 at 10:49:27AM +0200, Gerd Hoffmann wrote:
> 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 ...
> 
> > 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.

I think it's a mistake. I sent a mail explaining this part.

> Also mentioned in the call: "architectural reasons", which I understand
> as "real hardware works that way".  Correct.

Not exactly. Real hardware is very likely to have
most of the tables pre-generated in ROM, load
them and tweak them in the minor way.

That's exactly what patches I sent do.

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

Did you look at the patchset I posted?
Generation is in a standalone C file there.


However, if you mean we should do things like

if (Device_id == foobar) {
}

in once central place, I disagree.
I think that's nasty, adding devices would
mean touching this central registry.


> > 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.
> 
> > The possibility was also raised of a "rom" that lives in the
> > qemu repo, is run in the guest, and generates the tables (which is
> > similar to the hvmloader approach that Xen uses).
> 
> Also simliar to the coreboot idea.
> 
> Also in the call: The idea of having some library for acpi table
> generation provided by qemu which the firmware can use.  Has license
> compatibility issues.  Also difficult due to the fact that there is no
> libc in firmware, so such a library would need firmware-specific
> abstraction layers even for simple stuff such as memory allocation.
> 
> > Anthony requested that patches be made that generate the ACPI tables
> > in QEMU for the upcoming hotplug work, so that they could be evaluated
> > to see if they truly do need to live in QEMU or if the code could live
> > in the firmware.
> 
> Good.  I think having qemu generate the tables is also quite useful for
> evaluating the move to coreboot:
> 
>   (1)  make qemu generate the acpi tables.
>   (2a) make seabios use the qemu-generated tables.
>   (2b) make ovmf use the qemu-generated tables.
>   (2c) make coreboot use the qemu-generated tables.
> 
> Now we can look where we stand when using coreboot+seabios or
> coreboot+tianocore compared to bare seabios / bare ovmf.  I expect there
> are quite a few things to fix until the coreboot+seabios combo runs
> without regressions compared to bare seabios.  But maybe not when qemu
> provides the acpi tables to coreboot.
> 
> In case the coreboot testdrive works out well we can continue with:
> 
>   (3)  use coreboot+seabios by default.
>   (4)  move acpi table generation from qemu to coreboot.
> 
> cheers,
>   Gerd
>