On 2015/4/7 2:47, Mark Salter wrote: > On Fri, 2015-04-03 at 18:03 +0800, Shannon Zhao wrote: >> > From: Shannon Zhao >> > >> > This patch series generate six ACPI v5.1 tables for machine virt on ARM. >> > The set of generated tables are: >> > - RSDP >> > - RSDT >> > - MADT >> > - GTDT >> > - FADT >> > - DSDT >> > - MCFG (For PCIe host bridge) >> > >> > These tables are created dynamically using the function of aml-build.c, >> > taking into account the needed information passed from the virt machine model. >> > When the generation is finalized, it use fw_cfg to expose the tables to guest. >> > >> > You can fetch this from following repo: >> > http://git.linaro.org/people/shannon.zhao/qemu.git ACPI_ARM_v4 >> > >> > And this patchset refers to Alexander Spyridakis's patches which are sent to >> > qemu-devel mailing list before. >> > http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg03987.html >> > >> > Thanks to Laszlo's work on UEFI (ArmVirtualizationQemu) supporting downloading >> > ACPI tables over fw_cfg, we now can use ACPI in VM. I have done following vm >> > startup test: >> > >> > xp, windows2008, sles11 on X86 >> > Fedora Linux kernel on ARM64 >> > >> > Note: >> > As upstream kernel doesn't support ACPI PCI host bridge on ARM64, so I use the >> > Fedora Linux kernel from following address: >> > https://git.fedorahosted.org/cgit/kernel-arm64.git/log/?h=devel >> > But maybe this has a bug which cause unsuccessfully initializing BAR, therefore >> > virtio-pci can't work. I apply the following patch and the virtio-pci, e1000 >> > work well. >> > >> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c >> > index 8456e72..32f8869 100644 >> > --- a/arch/arm64/kernel/pci.c >> > +++ b/arch/arm64/kernel/pci.c >> > @@ -240,7 +240,7 @@ static acpi_status setup_resource(struct acpi_resource *acpi_res, void *data) >> > if (pci_remap_iospace(res, start) < 0) >> > return AE_OK; >> > >> > - info->res_offset[info->res_num] = port - addr.address.minimum; >> > + info->res_offset[info->res_num] = port; >> > } else >> > info->res_offset[info->res_num] = addr.address.translation_offset; > I don't think this is right. What does the working devicetree node look > like? What does the non-working PCIe table entry look like? What is the > range of PCI bus ioport addresses supported by the virtual device and > what CPU physical range is used to access that PCI ioport range? > Hi Mark, I just pick up the related part of the dts and acpi table. I think at this case the pci bus address and cpu physical address is 1:1 mapped. The dts node is: ranges = <0x1000000 0x0 0x0 0x0 0x3eff0000 0x0 0x10000 0x2000000 0x0 0x10000000 0x0 0x10000000 0x0 0x2eff0000>; reg = <0x0 0x3f000000 0x0 0x1000000>; bus-range = <0x0 0xf>; The ACPI table entry: Method (_CBA, 0, NotSerialized) // _CBA: Configuration Base Address { Return (0x3F000000) } Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x000F, // Range Maximum 0x0000, // Translation Offset 0x0010, // Length ,, ) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x10000000, // Range Minimum 0x3EFF0000, // Range Maximum 0x00000000, // Translation Offset 0x2EFF0000, // Length ,, , AddressRangeMemory, TypeStatic) DWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x3EFF0000, // Range Minimum 0x3F000000, // Range Maximum 0x00000000, // Translation Offset 0x00010000, // Length ,, , TypeStatic) }) Return(RBUF) } -- Thanks, Shannon