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
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
