On Tue, Sep 15, 2015 at 10:06:45AM +0800, Shannon Zhao wrote: > > > On 2015/9/14 22:57, Gabriel L. Somlo wrote: > > Add a fw_cfg device node to the ACPI DSDT. This is mostly > > informational, as the authoritative fw_cfg MMIO region(s) > > are listed in the Device Tree. However, since we are building > > ACPI tables, we might as well be thorough while at it... > > > > Signed-off-by: Gabriel Somlo <so...@cmu.edu> > > --- > > hw/arm/virt-acpi-build.c | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c > > index 9088248..dcf9752 100644 > > --- a/hw/arm/virt-acpi-build.c > > +++ b/hw/arm/virt-acpi-build.c > > @@ -110,6 +110,18 @@ static void acpi_dsdt_add_rtc(Aml *scope, const > > MemMapEntry *rtc_memmap, > > aml_append(scope, dev); > > } > > > > +static void acpi_dsdt_add_fw_cfg(Aml *scope, const MemMapEntry > > *fw_cfg_memmap) > > +{ > > + Aml *dev = aml_device("FWCF"); > > + aml_append(dev, aml_name_decl("_HID", aml_string("QEMU0002"))); > > + > > + Aml *crs = aml_resource_template(); > > + aml_append(crs, aml_memory32_fixed(fw_cfg_memmap->base, > > + fw_cfg_memmap->size, > > AML_READ_WRITE)); > > + aml_append(dev, aml_name_decl("_CRS", crs)); > > + aml_append(scope, dev); > > +} > > + > > static void acpi_dsdt_add_flash(Aml *scope, const MemMapEntry > > *flash_memmap) > > { > > Aml *dev, *crs; > > @@ -519,6 +531,7 @@ build_dsdt(GArray *table_data, GArray *linker, > > VirtGuestInfo *guest_info) > > (irqmap[VIRT_UART] + ARM_SPI_BASE)); > > acpi_dsdt_add_rtc(scope, &memmap[VIRT_RTC], > > (irqmap[VIRT_RTC] + ARM_SPI_BASE)); > > + acpi_dsdt_add_fw_cfg(scope, &memmap[VIRT_FW_CFG]); > > acpi_dsdt_add_flash(scope, &memmap[VIRT_FLASH]); > > acpi_dsdt_add_virtio(scope, &memmap[VIRT_MMIO], > > (irqmap[VIRT_MMIO] + ARM_SPI_BASE), > > NUM_VIRTIO_TRANSPORTS); > > > > This looks fine to me. But from what you said, the kernel driver is not > in upstream kernel yet, so this would be applied after the kernel patch > applied in case of unexpected change.
I guess that's ok if you're only talking about the arm side of things -- although I can't imagine how any of the above would need to change depending on what happens with the guest-side kernel sysfs driver... We're talking a node name ("FWCF"), a _HID ("QEMU0002"), and a mmio region (given to us by memmap[VIRT_FW_CFG]), and that's all there is to it... However, on the i386 side, this needs to go in *before* I can continue working on the guest-side kernel sysfs drivers. One of the requirements I got was not to probe IOports or MMIO registers blindly, but rather to use DT on arm and ACPI on i386 to first make sure fw_cfg is expected to be there, before tickling its registers :) So I need (at least the i386 part of) this series in qemu before I can move ahead with the (guest) kernel driver... Thanks, --Gabriel