[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 05/13] acpi: add DMAR scope definition for root
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 05/13] acpi: add DMAR scope definition for root IOAPIC |
Date: |
Sun, 21 Feb 2016 14:40:45 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2016-02-21 13:08, Marcel Apfelbaum wrote:
> On 02/21/2016 01:38 PM, Marcel Apfelbaum wrote:
>> On 02/19/2016 05:30 AM, Peter Xu wrote:
>>> To enable interrupt remapping for intel IOMMU device, each IOAPIC device
>>> in the system reported via ACPI MADT must be explicitly enumerated under
>>> one specific remapping hardware unit. This patch adds the root-complex
>>> IOAPIC into the default DMAR device.
>>>
>>> Please refer to VT-d spec 8.3.1.1 for more information.
>>>
>>> Signed-off-by: Peter Xu <address@hidden>
>>> ---
>>> hw/i386/acpi-build.c | 23 +++++++++++++++++++++--
>>> include/hw/acpi/acpi-defs.h | 15 +++++++++++++++
>>> 2 files changed, 36 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>>> index d9e4f91..1cefe43 100644
>>> --- a/hw/i386/acpi-build.c
>>> +++ b/hw/i386/acpi-build.c
>>> @@ -76,6 +76,9 @@
>>> #define ACPI_BUILD_DPRINTF(fmt, ...)
>>> #endif
>>>
>>> +/* Default IOAPIC ID */
>>> +#define ACPI_BUILD_IOAPIC_ID 0x0
>>> +
>>> typedef struct AcpiCpuInfo {
>>> DECLARE_BITMAP(found_cpus, ACPI_CPU_HOTPLUG_ID_LIMIT);
>>> } AcpiCpuInfo;
>>> @@ -392,7 +395,6 @@ build_madt(GArray *table_data, GArray *linker,
>>> AcpiCpuInfo *cpu)
>>> io_apic = acpi_data_push(table_data, sizeof *io_apic);
>>> io_apic->type = ACPI_APIC_IO;
>>> io_apic->length = sizeof(*io_apic);
>>> -#define ACPI_BUILD_IOAPIC_ID 0x0
>>> io_apic->io_apic_id = ACPI_BUILD_IOAPIC_ID;
>>> io_apic->address = cpu_to_le32(IO_APIC_DEFAULT_ADDRESS);
>>> io_apic->interrupt = cpu_to_le32(0);
>>> @@ -2511,6 +2513,9 @@ build_dmar_q35(GArray *table_data, GArray *linker)
>>> AcpiDmarHardwareUnit *drhd;
>>> uint8_t dmar_flags = 0;
>>> IntelIOMMUState *intel_iommu = acpi_get_iommu();
>>> + AcpiDmarDeviceScope *scope = NULL;
>>> + /* Root complex IOAPIC use one path[0] only */
>>> + uint16_t scope_size = sizeof(*scope) + sizeof(uint16_t);
>>>
>>> assert(intel_iommu);
>>>
>>> @@ -2526,11 +2531,25 @@ build_dmar_q35(GArray *table_data, GArray
>>> *linker)
>>> /* DMAR Remapping Hardware Unit Definition structure */
>>> drhd = acpi_data_push(table_data, sizeof(*drhd));
>>> drhd->type = cpu_to_le16(ACPI_DMAR_TYPE_HARDWARE_UNIT);
>>> - drhd->length = cpu_to_le16(sizeof(*drhd)); /* No device scope
>>> now */
>>> + drhd->length = cpu_to_le16(sizeof(*drhd) + scope_size);
>>> drhd->flags = ACPI_DMAR_INCLUDE_PCI_ALL;
>>> drhd->pci_segment = cpu_to_le16(0);
>>> drhd->address = cpu_to_le64(Q35_HOST_BRIDGE_IOMMU_ADDR);
>>>
>>> + /* Scope definition for the root-complex IOAPIC */
>>> + scope = acpi_data_push(table_data, scope_size);
>>> + scope->entry_type = cpu_to_le16(ACPI_DMAR_DEV_SCOPE_TYPE_IOAPIC);
>>> + scope->length = scope_size;
>>> + /*
>>> + * An arbitary but unique bus number, to be used to generate
>>> + * source ID for IOAPIC device in BDF format.
>>> + */
>>> +#define ACPI_IOAPIC_BUS_IR (0xf0)
>>> +#define ACPI_IOAPIC_DEVFN_IR (0x00)
>>
>> Hi,
>>
>> How do you know for sure there is no bus (or bus & device) having the
>> number 0xf0 in the system?
>> Now that we support multiple Root Complexes, using the pxb-pcie
>> device we can simply add a PCI root bus like this:
>> -device pxb-pcie,bus_nr=0xf0
>> or we can add enough switches to get to this number.
>>
>> You could dynamically query for an unused PCI bus, but the number
>> would change between the runs.
>> Or, I suppose you can reserve a slot on bus 0 for that. It is
>> interesting how it works on a real machine.
>
> thinking about it more, maybe we should let the firmware to assign the
> bus/dev/fun for the IO APIC?
We have the same problem over with VT-d and IR.
I don't think the firmware is not the right place, otherwise there would
be an interface in hw to adjust that parameters. I think we should
simply make sure that the qemu user cannot assign devices to those
addresses as they are reserved for the platform devices (the HPET
requires another ID), or even reserve the hole bus for the platform.
Jan
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU, Peter Xu, 2016/02/18
- [Qemu-devel] [PATCH 01/13] q35: add "int-remap" flag to enable intr, Peter Xu, 2016/02/18
- [Qemu-devel] [PATCH 02/13] acpi: enable INTR for DMAR report structure, Peter Xu, 2016/02/18
- [Qemu-devel] [PATCH 03/13] intel_iommu: allow queued invalidation for IR, Peter Xu, 2016/02/18
- [Qemu-devel] [PATCH 04/13] intel_iommu: set IR bit for ECAP register, Peter Xu, 2016/02/18
- [Qemu-devel] [PATCH 05/13] acpi: add DMAR scope definition for root IOAPIC, Peter Xu, 2016/02/18
[Qemu-devel] [PATCH 06/13] intel_iommu: define interrupt remap table addr register, Peter Xu, 2016/02/18
[Qemu-devel] [PATCH 07/13] intel_iommu: handle interrupt remap enable, Peter Xu, 2016/02/18
[Qemu-devel] [PATCH 08/13] intel_iommu: define several structs for IOMMU IR, Peter Xu, 2016/02/18
[Qemu-devel] [PATCH 09/13] intel_iommu: provide helper function vtd_get_iommu, Peter Xu, 2016/02/18
[Qemu-devel] [PATCH 10/13] ioapic-common: add iommu for IOAPICCommonState, Peter Xu, 2016/02/18
[Qemu-devel] [PATCH 11/13] intel_iommu: add IR translation faults defines, Peter Xu, 2016/02/18
[Qemu-devel] [PATCH 12/13] intel_iommu: ioapic: IR support for emulated IOAPIC, Peter Xu, 2016/02/18