diff mbox

[v4,00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM

Message ID 1428055432-12120-1-git-send-email-zhaoshenglong@huawei.com
State New
Headers show

Commit Message

Shannon Zhao April 3, 2015, 10:03 a.m. UTC
From: Shannon Zhao <shannon.zhao@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.

changes since v3:
  * rebase on upstream qemu
  * fix _HID of CPU (Heyi Guo)
  * Add PCIe host bridge
  
changes since v2:
  * rebase on Igor Mammedov's new branch ASL_API_v3
  * use rsdt instead of xsdt according to Igor Mammedov's suggestion

changes since v1:
  * fix bug found by Laszlo
  * move common helpers into dedictated file and change generating
    table order according to Igor's comments
  * fix copyright and function name according to Michael's comments


Shannon Zhao (20):
  hw/i386: Move ACPI header definitions in an arch-independent location
  hw/i386/acpi-build: move generic acpi building helpers into dedictated
    file
  hw/arm/virt-acpi-build: Basic framework for building ACPI tables on
    ARM
  hw/acpi/aml-build: Add aml_memory32_fixed() term
  hw/acpi/aml-build: Add aml_interrupt() term
  hw/arm/virt-acpi-build: Generation of DSDT table for virt devices
  hw/arm/virt-acpi-build: Generate FADT table and update ACPI headers
  hw/arm/virt-acpi-build: Generate MADT table
  hw/arm/virt-acpi-build: Generate GTDT table
  hw/arm/virt-acpi-build: Generate RSDT table
  hw/arm/virt-acpi-build: Generate RSDP table
  hw/arm/virt-acpi-build: Add PCIe info and generate MCFG table
  hw/acpi/aml-build: Add ToUUID macro
  hw/acpi/aml-build: Add aml_or() term
  hw/acpi/aml-build: Add aml_not() term
  hw/acpi/aml-build: Add aml_else() term
  hw/acpi/aml-build: Add aml_create_dword_field() term
  hw/acpi/aml-build: Add aml_dword_io() term
  hw/arm/virt-acpi-build: Add PCIe controller in ACPI DSDT table
  hw/arm/virt: Enable dynamic generation of ACPI v5.1 tables

 default-configs/arm-softmmu.mak      |   1 +
 default-configs/i386-softmmu.mak     |   3 +
 default-configs/mips-softmmu.mak     |   3 +
 default-configs/mips64-softmmu.mak   |   3 +
 default-configs/mips64el-softmmu.mak |   3 +
 default-configs/mipsel-softmmu.mak   |   3 +
 default-configs/x86_64-softmmu.mak   |   3 +
 hw/acpi/Makefile.objs                |   5 +-
 hw/acpi/aml-build.c                  | 189 +++++++++-
 hw/arm/Makefile.objs                 |   1 +
 hw/arm/virt-acpi-build.c             | 678 +++++++++++++++++++++++++++++++++++
 hw/arm/virt.c                        |  78 +++-
 hw/i2c/Makefile.objs                 |   2 +-
 hw/i386/acpi-build.c                 |  81 +----
 hw/i386/acpi-defs.h                  | 368 -------------------
 include/hw/acpi/acpi-defs.h          | 479 +++++++++++++++++++++++++
 include/hw/acpi/aml-build.h          |  45 ++-
 include/hw/arm/virt-acpi-build.h     |  79 ++++
 tests/bios-tables-test.c             |   2 +-
 19 files changed, 1564 insertions(+), 462 deletions(-)
 create mode 100644 hw/arm/virt-acpi-build.c
 delete mode 100644 hw/i386/acpi-defs.h
 create mode 100644 include/hw/acpi/acpi-defs.h
 create mode 100644 include/hw/arm/virt-acpi-build.h

Comments

Peter Maydell April 7, 2015, 9:19 a.m. UTC | #1
On 7 April 2015 at 03:43, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> 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,

Is this claiming that the non-cacheable PCI MMIO region is cacheable?
If so that isn't right...

>                         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

I rather suspect this is wrong, since (my guess without looking
at the spec) it looks like it defines a 1:1 mapping between
the addresses used to interact with the PCIe IO window and
the IO addresses, which is obviously not what you want.
My guess is you need to set the translation offset at least,
but check the spec.

-- PMM
Peter Maydell April 7, 2015, 9:43 a.m. UTC | #2
On 7 April 2015 at 10:32, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Apr 07, 2015 at 10:19:22AM +0100, Peter Maydell wrote:
>> On 7 April 2015 at 03:43, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> > 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,
>>
>> Is this claiming that the non-cacheable PCI MMIO region is cacheable?
>> If so that isn't right...
>
> I suspect that's fine.
> Some parts of MMIO might be cacheable. This really depends on the
> device

No, this is the PCI "non-cacheable MMIO" window. (We don't have
a cacheable MMIO window on this board). In the DTB we advertise
it as non-cacheable, and we should do the same in ACPI.

-- PMM
Peter Maydell April 7, 2015, 12:07 p.m. UTC | #3
On 7 April 2015 at 03:43, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> 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

In all the other sections, the Length entry is (rangemax - rangemin) + 1,
but in this one it is not, which suggests an error. Probably your
rangemax here is wrong, since 0x3eff0000 is actually the first address
in the IO window.

(If ACPI is effectively describing the length of the range in
two separate places, it's a shame it doesn't sanity check that
they both agree...)

-- PMM
diff mbox

Patch

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;