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

[Jan Kiszka]

On 2016-06-18 14:32, Peter Xu wrote:
> 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.

You need proper error handling and a readable error message because
nothing else will stop the user from doing -device intel-iommu -device
amd-iommu.

Jan

signature.asc
Description: OpenPGP digital signature