From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ5Ze-00017M-1q for qemu-devel@nongnu.org; Fri, 22 Mar 2013 13:16:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJ5Zc-0008HX-LK for qemu-devel@nongnu.org; Fri, 22 Mar 2013 13:16:13 -0400 Received: from mail-vb0-x231.google.com ([2607:f8b0:400c:c02::231]:58887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ5Zc-0008HR-Ga for qemu-devel@nongnu.org; Fri, 22 Mar 2013 13:16:12 -0400 Received: by mail-vb0-f49.google.com with SMTP id s24so2676468vbi.8 for ; Fri, 22 Mar 2013 10:16:12 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <514C91D7.4050808@redhat.com> Date: Fri, 22 Mar 2013 18:16:07 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <514C8251.8060209@redhat.com> In-Reply-To: <514C8251.8060209@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu / seabios ACPI table interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: "Jordan Justen (Intel address)" , seabios , "qemu-devel@nongnu.org" Il 22/03/2013 17:09, Laszlo Ersek ha scritto: > I'm confused. What are the requirements? > > (1) should unpatched qemu work with patched seabios? Yes. > (2) should patched qemu work with unpatched seabios? No. > Considering patched qemu + patched seabios, > (3) should qemu dynamically control table origin/contents per table? Not sure I understand this? > (4) should qemu be able to suppress/disable a seabios table via fw_cfg > without providing a replacement? QEMU should be able to suppress all SeaBIOS tables except for the four tables you identified. Once the transition is done, a special fw_cfg file (or alternatively a SeaBIOS/OVMF patch) would direct SeaBIOS to not create _any_ ACPI table except those four. > I had thought: > (1) yes (firmware upgrade on same hardware), > (2) no (hardware upgrade), > (3) yes (eases development and ultimately covers everything), > (4) no (*) Three out of four, you're probably right on (3) too. :) Paolo > but apparently I'm wrong. I'm ready to be enlightened and try to > implement whatever the consensus is, but what is the consensus? > > (*) For each table we can investigate why SeaBIOS provides it now: > > - RSDP, RSDT, XSDT: These look like links-only tables. In general, links > (pointers) have to be updated by the firmware (eg. in the FADT), thus > qemu would provide zeros in those fields in general. Since these three > tables consist of nothing more than pointers, qemu would never provide > any of these tables. Choice between RSDT and XSDT is the jurisdiction of > the boot firmware, and it should choose exactly one. (SeaBIOS currently > uses RSDT, OVMF uses XSDT.) > > - FADT (FACP): required by the spec. Qemu would either put up with > SeaBIOS's or provide a replacement. > > - FACS: always prepared by the boot firmware. > > - DSDT: Same as FADT. > > - SSDT: a continuation of the DSDT; there can be several instances. If > the DSDT comes from qemu, SeaBIOS shouldn't install any SSDTs of its > own. Qemu won't provide SSDTs without its own DSDT. > > - APIC (MADT): required in the "APIC interrupt model", which is probably > "always" for us. Hence same as with FADT/DSDT. > > - HPET: Hardware dependent. If qemu doesn't provide the hardware, it > also wouldn't provide the table, and SeaBIOS already doesn't install one > itself because there's no hardware. If the hardware is there, qemu > provides the table, or puts up with SeaBIOS's. > > - SRAT: Dependent on NUMA setup. Same case as with HPET. > > - MCFG: Seems to depend on hardware (q35). Same as with HPET. > > (I'll be out of the office next week -- if I don't follow up, that's the > reason.) > > Thanks > Laszlo > >