qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [V11 2/4] hw/i386: ACPI IVRS table


From: Peter Xu
Subject: Re: [Qemu-devel] [V11 2/4] hw/i386: ACPI IVRS table
Date: Sat, 18 Jun 2016 20:32:44 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

On Sat, Jun 18, 2016 at 11:18:29AM +0300, David Kiarie wrote:
> On Tue, May 24, 2016 at 10:06 AM, Valentine Sinitsyn
> <address@hidden> wrote:
> > Hi all,
> >
> >
> > On 24.05.2016 11:54, Peter Xu wrote:
> >>
> >> On Sun, May 22, 2016 at 01:21:52PM +0300, David Kiarie wrote:
> >> [...]
> >>>
> >>> +static void
> >>> +build_amd_iommu(GArray *table_data, GArray *linker)
> >>> +{
> >>> +    int iommu_start = table_data->len;
> >>> +    bool iommu_ambig;
> >>> +
> >>> +    /* IVRS definition  - table header has an extra 2-byte field */
> >>> +    acpi_data_push(table_data, (sizeof(AcpiTableHeader)));
> >>> +    /* common virtualization information */
> >>> +    build_append_int_noprefix(table_data, AMD_IOMMU_HOST_ADDRESS_WIDTH
> >>> << 8, 4);
> >>> +    /* reserved */
> >>> +    build_append_int_noprefix(table_data, 0, 8);
> >>> +
> >>> +    AMDVIState *s = (AMDVIState *)object_resolve_path_type("",
> >>> +                        TYPE_AMD_IOMMU_DEVICE, &iommu_ambig);
> >>> +
> >>> +    /* IVDB definition - type 10h */
> >>> +    if (!iommu_ambig) {
> >>> +        /* IVHD definition - type 10h */
> >>> +        build_append_int_noprefix(table_data, 0x10, 1);
> >>> +        /* virtualization flags */
> >>> +        build_append_int_noprefix(table_data, (IVHD_HT_TUNEN |
> >>> +                     IVHD_PPRSUP | IVHD_IOTLBSUP | IVHD_PREFSUP), 1);
> >>> +        /* ivhd length */
> >>> +        build_append_int_noprefix(table_data, 0x20, 2);
> >>> +        /* iommu device id */
> >>> +        build_append_int_noprefix(table_data, PCI_DEVICE_ID_RD890_IOMMU,
> >>> 2);
> >>> +        /* offset of capability registers */
> >>> +        build_append_int_noprefix(table_data, s->capab_offset, 2);
> >>> +        /* mmio base register */
> >>> +        build_append_int_noprefix(table_data, s->mmio.addr, 8);
> >>> +        /* pci segment */
> >>> +        build_append_int_noprefix(table_data, 0, 2);
> >>> +        /* interrupt numbers */
> >>> +        build_append_int_noprefix(table_data, 0, 2);
> >>> +        /* feature reporting */
> >>> +        build_append_int_noprefix(table_data, (IVHD_EFR_GTSUP |
> >>> +                    IVHD_EFR_HATS | IVHD_EFR_GATS), 4);
> >>> +        /* Add device flags here
> >>> +         *   These are 4-byte device entries currently reporting the
> >>> range of
> >>> +         *   devices 00h - ffffh; all devices
> >>> +         *   Device setting affecting all devices should be made here
> >>> +         *
> >>> +         *   Refer to
> >>> +         *
> >>> (http://developer.amd.com/wordpress/media/2012/10/488821.pdf)
> >>> +         *   Table 95
> >>
> >>
> >> I failed to find Table 95 in the document. Is that typo?
> >
> > I guess it should be "Table 75". David, am I right?
> > On a side note, 2.0 specification you mention is rather outdated.
> > Please consider referencing something newer, like 2.6.
> >
> >
> >>
> >> [...]
> >>
> >>>   static
> >>>   void acpi_build(AcpiBuildTables *tables, MachineState *machine)
> >>>   {
> >>> @@ -2657,6 +2721,7 @@ void acpi_build(AcpiBuildTables *tables,
> >>> MachineState *machine)
> >>>       AcpiMcfgInfo mcfg;
> >>>       PcPciInfo pci;
> >>>       uint8_t *u;
> >>> +    IommuType IOMMUType = has_iommu();
> >>>       size_t aml_len = 0;
> >>>       GArray *tables_blob = tables->table_data;
> >>>       AcpiSlicOem slic_oem = { .id = NULL, .table_id = NULL };
> >>> @@ -2722,7 +2787,13 @@ void acpi_build(AcpiBuildTables *tables,
> >>> MachineState *machine)
> >>>           acpi_add_table(table_offsets, tables_blob);
> >>>           build_mcfg_q35(tables_blob, tables->linker, &mcfg);
> >>>       }
> >>> -    if (acpi_has_iommu()) {
> >>> +
> >>> +    if (IOMMUType == TYPE_AMD) {
> >>> +        acpi_add_table(table_offsets, tables_blob);
> >>> +        build_amd_iommu(tables_blob, tables->linker);
> >>> +    }
> >>> +
> >>> +    if (IOMMUType == TYPE_INTEL) {
> >>>           acpi_add_table(table_offsets, tables_blob);
> >>>           build_dmar_q35(tables_blob, tables->linker);
> >>>       }
> >>
> >>
> >> Nit: I'd prefer:
> >>
> >>      if (type == Intel) {
> >>      ...
> >>      } else if (type == AMD) {
> >>      ...
> >>      }
> >>
> 
> I missed this is the last version of the patch I should fix it in next 
> version.
> 
> On taking a closer look at this there might be larger problem where
> with the advent of -device <iommu-type> users can possibly emulate two
> IOMMUs at the same time ? A proposed solution was to have
> pci_setup_iommu check that DMA hook as not been setup yet and fail if
> yes. I should send a fix for that too.

Currently we should only support single vIOMMU.  If you are going to
rebase to x86-iommu codes, there is a patch that includes the check:

  "[PATCH v9 02/25] x86-iommu: provide x86_iommu_get_default"

by:

  assert(x86_iommu_default == NULL);

Maybe we should print something more readable, like "multiple vIOMMUs
are not supported yet", rather than an assertion fail.

-- peterx



reply via email to

[Prev in Thread] Current Thread [Next in Thread]