From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlRh-00053S-QD for qemu-devel@nongnu.org; Fri, 19 Feb 2016 08:50:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWlRd-0005yx-KH for qemu-devel@nongnu.org; Fri, 19 Feb 2016 08:50:09 -0500 Date: Fri, 19 Feb 2016 14:49:53 +0100 From: Igor Mammedov Message-ID: <20160219144953.03aff7eb@nial.brq.redhat.com> In-Reply-To: <1455228365-13666-4-git-send-email-somlo@cmu.edu> References: <1455228365-13666-1-git-send-email-somlo@cmu.edu> <1455228365-13666-4-git-send-email-somlo@cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v8 3/5] acpi: pc: add fw_cfg device node to dsdt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: peter.maydell@linaro.org, ehabkost@redhat.com, mst@redhat.com, matt@codeblueprint.co.uk, stefanha@gmail.com, ard.biesheuvel@linaro.org, qemu-devel@nongnu.org, leif.lindholm@linaro.org, luto@amacapital.net, qemu-arm@nongnu.org, kraxel@redhat.com, pbonzini@redhat.com, lersek@redhat.com, rth@twiddle.net On Thu, 11 Feb 2016 17:06:03 -0500 "Gabriel L. Somlo" wrote: > Add a fw_cfg device node to the ACPI DSDT. While the guest-side > firmware can't utilize this information (since it has to access > the hard-coded fw_cfg device to extract ACPI tables to begin with), > having fw_cfg listed in ACPI will help the guest kernel keep a more > accurate inventory of in-use IO port regions. >=20 > Signed-off-by: Gabriel Somlo > Reviewed-by: Laszlo Ersek > Reviewed-by: Marc Mar=C3=AD > --- > hw/i386/acpi-build.c | 29 +++++++++++++++++++++++++++++ > 1 file changed, 29 insertions(+) >=20 > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > index 4554eb8..4762fd2 100644 > --- a/hw/i386/acpi-build.c > +++ b/hw/i386/acpi-build.c > @@ -2190,6 +2190,35 @@ build_dsdt(GArray *table_data, GArray *linker, > aml_append(scope, aml_name_decl("_S5", pkg)); > aml_append(dsdt, scope); > =20 > + /* create fw_cfg node, unconditionally */ > + { > + /* when using port i/o, the 8-bit data register *always* overlaps > + * with half of the 16-bit control register. Hence, the total si= ze > + * of the i/o region used is FW_CFG_CTL_SIZE; when using DMA, the > + * DMA control register is located at FW_CFG_DMA_IO_BASE + 4 */ > + uint8_t io_size =3D object_property_get_bool(OBJECT(pcms->fw_cfg= ), > + "dma_enabled", NULL) ? > + ROUND_UP(FW_CFG_CTL_SIZE, 4) + sizeof(dma_addr= _t) : > + FW_CFG_CTL_SIZE; > + > + scope =3D aml_scope("\\_SB"); > + dev =3D aml_device("FWCF"); > + > + aml_append(dev, aml_name_decl("_HID", aml_string("QEMU0002"))); =46rom my tests with different Windows versions, it doesn't prevent WS2003 and WS2008 from showing a prompt for unknown device that asks for a = driver. One however could shut it up by allowing OS look for a driver which is not found and then tell not to ask for it anymore. So existing users will have to perform this action once they have migrated to newer QEMU regardless of machine version. > + > + /* device present, functioning, decoding, not shown in UI */ > + aml_append(dev, aml_name_decl("_STA", aml_int(0xB))); > + > + crs =3D aml_resource_template(); > + aml_append(crs, > + aml_io(AML_DECODE16, FW_CFG_IO_BASE, FW_CFG_IO_BASE, 0x01, i= o_size) > + ); that creates \_SB.FWCF._CRS=20 + Name (_CRS, ResourceTemplate () // _CRS: Current Resource Set= tings + { + IO (Decode16, + 0x0510, // Range Minimum + 0x0510, // Range Maximum + 0x01, // Alignment + 0x0C, // Length + ) + }) which collides with \_SB.PCI0._CRS WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, Entire= Range, 0x0000, // Granularity 0x0000, // Range Minimum 0x0CF7, // Range Maximum 0x0000, // Translation Offset 0x0CF8, that shouldn't happen, and solution for this is to put FWCF device descriptor in \_SB.PCI0 scope so FWCF would consume from PCI0 IO range. That won't help Windows to notice a conflict, if there is any, as there aren't any drivers for QEMU0002 device but at least when Windows gets a driver it won't crash due above conflict. > + aml_append(dev, aml_name_decl("_CRS", crs)); > + > + aml_append(scope, dev); > + aml_append(dsdt, scope); > + } > + > if (misc->applesmc_io_base) { > scope =3D aml_scope("\\_SB.PCI0.ISA"); > dev =3D aml_device("SMC");