From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [SeaBIOS] KVM call agenda for 2013-05-28 Date: Wed, 29 May 2013 19:28:05 +0300 Message-ID: <20130529162805.GC1771@redhat.com> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <51A5C117.6000609@redhat.com> <871u8p92v8.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Gerd Hoffmann , "Kevin O'Connor" , KVM devel mailing list , Juan Quintela , seabios@seabios.org, qemu-devel qemu-devel , dwmw2@infradead.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:13120 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754262Ab3E2Q2P (ORCPT ); Wed, 29 May 2013 12:28:15 -0400 Content-Disposition: inline In-Reply-To: <871u8p92v8.fsf@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote: > Gerd Hoffmann 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhjEP-0001Ko-Ie for qemu-devel@nongnu.org; Wed, 29 May 2013 12:28:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhjEI-0006QU-Tb for qemu-devel@nongnu.org; Wed, 29 May 2013 12:28:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhjEI-0006Q8-LM for qemu-devel@nongnu.org; Wed, 29 May 2013 12:28:02 -0400 Date: Wed, 29 May 2013 19:28:05 +0300 From: "Michael S. Tsirkin" Message-ID: <20130529162805.GC1771@redhat.com> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <51A5C117.6000609@redhat.com> <871u8p92v8.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871u8p92v8.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: KVM devel mailing list , Juan Quintela , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , Gerd Hoffmann , dwmw2@infradead.org On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote: > Gerd Hoffmann 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