From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXUFx-0002sS-80 for qemu-devel@nongnu.org; Sun, 21 Feb 2016 08:41:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXUFs-0007Eu-7a for qemu-devel@nongnu.org; Sun, 21 Feb 2016 08:41:01 -0500 Received: from mout.web.de ([212.227.15.4]:62044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXUFr-0007EI-Tr for qemu-devel@nongnu.org; Sun, 21 Feb 2016 08:40:56 -0500 References: <1455852618-5224-1-git-send-email-peterx@redhat.com> <1455852618-5224-6-git-send-email-peterx@redhat.com> <56C9A1B8.6070909@gmail.com> <56C9A8D1.4010604@gmail.com> From: Jan Kiszka Message-ID: <56C9BE5D.60808@web.de> Date: Sun, 21 Feb 2016 14:40:45 +0100 MIME-Version: 1.0 In-Reply-To: <56C9A8D1.4010604@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V3xTACIkud8AeohGMDnbjOebm0N9Ft36r" Subject: Re: [Qemu-devel] [PATCH 05/13] acpi: add DMAR scope definition for root IOAPIC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: marcel@redhat.com, Peter Xu , qemu-devel@nongnu.org Cc: Rita Sinha , ehabkost@redhat.com, mst@redhat.com, jasowang@redhat.com, pbonzini@redhat.com, imammedo@redhat.com, rth@twiddle.net This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V3xTACIkud8AeohGMDnbjOebm0N9Ft36r Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 dev= ice >>> in the system reported via ACPI MADT must be explicitly enumerated un= der >>> one specific remapping hardware unit. This patch adds the root-comple= x >>> IOAPIC into the default DMAR device. >>> >>> Please refer to VT-d spec 8.3.1.1 for more information. >>> >>> Signed-off-by: Peter Xu >>> --- >>> 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 =3D acpi_data_push(table_data, sizeof *io_apic); >>> io_apic->type =3D ACPI_APIC_IO; >>> io_apic->length =3D sizeof(*io_apic); >>> -#define ACPI_BUILD_IOAPIC_ID 0x0 >>> io_apic->io_apic_id =3D ACPI_BUILD_IOAPIC_ID; >>> io_apic->address =3D cpu_to_le32(IO_APIC_DEFAULT_ADDRESS); >>> io_apic->interrupt =3D cpu_to_le32(0); >>> @@ -2511,6 +2513,9 @@ build_dmar_q35(GArray *table_data, GArray *link= er) >>> AcpiDmarHardwareUnit *drhd; >>> uint8_t dmar_flags =3D 0; >>> IntelIOMMUState *intel_iommu =3D acpi_get_iommu(); >>> + AcpiDmarDeviceScope *scope =3D NULL; >>> + /* Root complex IOAPIC use one path[0] only */ >>> + uint16_t scope_size =3D 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 =3D acpi_data_push(table_data, sizeof(*drhd)); >>> drhd->type =3D cpu_to_le16(ACPI_DMAR_TYPE_HARDWARE_UNIT); >>> - drhd->length =3D cpu_to_le16(sizeof(*drhd)); /* No device scop= e >>> now */ >>> + drhd->length =3D cpu_to_le16(sizeof(*drhd) + scope_size); >>> drhd->flags =3D ACPI_DMAR_INCLUDE_PCI_ALL; >>> drhd->pci_segment =3D cpu_to_le16(0); >>> drhd->address =3D cpu_to_le64(Q35_HOST_BRIDGE_IOMMU_ADDR); >>> >>> + /* Scope definition for the root-complex IOAPIC */ >>> + scope =3D acpi_data_push(table_data, scope_size); >>> + scope->entry_type =3D cpu_to_le16(ACPI_DMAR_DEV_SCOPE_TYPE_IOAPI= C); >>> + scope->length =3D 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=3D0xf0 >> 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. >=20 > 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 --V3xTACIkud8AeohGMDnbjOebm0N9Ft36r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlbJvl0ACgkQitSsb3rl5xSolgCgykwFM7OHJKzNbMlTFAPFwzTc v74AnjdwLvTifVOxqmVfaluJUPmxb7dQ =Qh+3 -----END PGP SIGNATURE----- --V3xTACIkud8AeohGMDnbjOebm0N9Ft36r--