[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose i
From: |
Shannon Zhao |
Subject: |
Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM |
Date: |
Tue, 7 Apr 2015 10:43:53 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
On 2015/4/7 2:47, Mark Salter wrote:
> On Fri, 2015-04-03 at 18:03 +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao <address@hidden>
>> >
>> > 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
dts-pcie
Description: Text document
ACPI-PCIe-entry
Description: Text document
- Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT table, (continued)
- Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT table, Peter Maydell, 2015/04/09
- Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT table, Igor Mammedov, 2015/04/09
- Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT table, Laszlo Ersek, 2015/04/09
- Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT table, Peter Maydell, 2015/04/09
- Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT table, Laszlo Ersek, 2015/04/09
[Qemu-devel] [PATCH v4 08/20] hw/arm/virt-acpi-build: Generate MADT table, Shannon Zhao, 2015/04/03
[Qemu-devel] [PATCH v4 17/20] hw/acpi/aml-build: Add aml_create_dword_field() term, Shannon Zhao, 2015/04/03
Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM, Mark Salter, 2015/04/06
Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM, Peter Maydell, 2015/04/07
Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM, Shannon Zhao, 2015/04/07
Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM, Igor Mammedov, 2015/04/07
Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM, Michael S. Tsirkin, 2015/04/08
Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM, Michael S. Tsirkin, 2015/04/15