On 2015/4/7 2:47, Mark Salter wrote:
> On Fri, 2015-04-03 at 18:03 +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao <shannon.z...@linaro.org>
>> >
>> > 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
pcie@10000000 {
interrupt-map-mask = <0x1800 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 0x8001 0x0 0x3 0x4 0x0 0x0 0x0
0x2 0x8001 0x0 0x4 0x4 0x0 0x0 0x0 0x3 0x8001 0x0 0x5 0x4 0x0 0x0 0x0 0x4
0x8001 0x0 0x6 0x4 0x800 0x0 0x0 0x1 0x8001 0x0 0x4 0x4 0x800 0x0 0x0 0x2
0x8001 0x0 0x5 0x4 0x800 0x0 0x0 0x3 0x8001 0x0 0x6 0x4 0x800 0x0 0x0 0x4
0x8001 0x0 0x3 0x4 0x1000 0x0 0x0 0x1 0x8001 0x0 0x5 0x4 0x1000 0x0 0x0 0x2
0x8001 0x0 0x6 0x4 0x1000 0x0 0x0 0x3 0x8001 0x0 0x3 0x4 0x1000 0x0 0x0 0x4
0x8001 0x0 0x4 0x4 0x1800 0x0 0x0 0x1 0x8001 0x0 0x6 0x4 0x1800 0x0 0x0 0x2
0x8001 0x0 0x3 0x4 0x1800 0x0 0x0 0x3 0x8001 0x0 0x4 0x4 0x1800 0x0 0x0 0x4
0x8001 0x0 0x5 0x4>;
#interrupt-cells = <0x1>;
ranges = <0x1000000 0x0 0x0 0x0 0x3eff0000 0x0 0x10000
0x2000000 0x0 0x10000000 0x0 0x10000000 0x0
0x2eff0000>;
reg = <0x0 0x3f000000 0x0 0x1000000>;
bus-range = <0x0 0xf>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
compatible = "pci-host-ecam-generic";
};
Device (PCI0)
{
Name (_HID, "PNP0A08") // _HID: Hardware ID
Name (_CID, "PNP0A03") // _CID: Compatible ID
Name (_SEG, Zero) // _SEG: PCI Segment
Name (_BBN, Zero) // _BBN: BIOS Bus Number
Name (_UID, "PCI0") // _UID: Unique ID
Name (_STR, "PCIe 0 Device") // _STR: Description String
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)
}
}
