[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