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