From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmCBZ-00080G-WB for qemu-devel@nongnu.org; Mon, 10 Jun 2013 20:11:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UmCBV-0002Nl-4K for qemu-devel@nongnu.org; Mon, 10 Jun 2013 20:11:41 -0400 Received: from mail-oa0-x234.google.com ([2607:f8b0:4003:c02::234]:51166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmCBV-0002Nh-0K for qemu-devel@nongnu.org; Mon, 10 Jun 2013 20:11:37 -0400 Received: by mail-oa0-f52.google.com with SMTP id g12so1974068oah.39 for ; Mon, 10 Jun 2013 17:11:36 -0700 (PDT) From: Anthony Liguori In-Reply-To: <1370908331.21510.28.camel@i7.infradead.org> References: <1370882347-31129-1-git-send-email-mst@redhat.com> <87r4g9rdwe.fsf@codemonkey.ws> <51B62C48.5060303@redhat.com> <87ehc920ym.fsf@codemonkey.ws> <51B63A74.1030905@redhat.com> <87mwqxzlke.fsf@codemonkey.ws> <20130610230557.GA13553@morn.localdomain> <871u89v8u2.fsf@codemonkey.ws> <1370908331.21510.28.camel@i7.infradead.org> Date: Mon, 10 Jun 2013 19:11:34 -0500 Message-ID: <87zjux5ww9.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Woodhouse Cc: Peter Maydell , "Michael S. Tsirkin" , Laszlo Ersek , seabios@seabios.org, qemu-devel@nongnu.org, Kevin O'Connor , Gerd Hoffmann , Jordan Justen David Woodhouse writes: > On Mon, 2013-06-10 at 18:34 -0500, Anthony Liguori wrote: >> Internally within QEMU, this initial discussion started by saying that >> any ACPI generation within QEMU should happen strictly with QOM >> methods. This was the crux of my argument, if QOM is the only >> interface we need, everything is there for the firmware to do the same >> job that QEMU would be doing. > > That's nice in theory, but I'm not sure how it works as things evolve > and new things / new features get exposed. The firmware's > *interpretation* of the QOM tree needs to be kept in sync with qemu. > > Hm, make that: The firmwares' *interpretation*=E2=80=A6 > > Let's take a specific, recent example. We fixed the PIIX4 code to > actually handle the hard reset on port 0xcf9. We need to fix the ACPI > tables to indicate a usable RESET_REG. Very good example. Normally, we try to be bug-for-bug compatible for guests such that -M pc-1.4 would behave exactly the same. In this case, we failed to introduce a property to control this behavior like we should have. If this changes the guest ACPI tables, it definitely should definitely be set based on a property. This is a good example of why this approach is good for QEMU, it helps us catch stuff like this. > How is that exposed in the QOM tree, and how does it all work? With qemu > exposing ACPI tables in their close-to-final form, it's just fine. Boot > with a recent qemu and it's all nice and shiny; boot with an old qemu > and it doesn't reset properly. If we did this right in QEMU, we'd have to introduce a QOM property anyway as that's how we trigger differences in machine behavior. And -M pc-1.4 ought to generate the same tables as qemu 1.4 did. Regards, Anthony Liguori > But if the firmware has to be updated to interpret the new feature > advertised in the QOM tree and translate it into the ACPI table, then we > haven't really got much of an improvement. > > Please explain how this is supposed to work in *practice*. > > --=20 > dwmw2