Re: [PATCH v4 01/11] hw/acpi: Add VIOT table

[Jean-Philippe Brucker <jean-philippe@linaro.org>]

On Wed, Oct 06, 2021 at 10:09:50AM +0200, Igor Mammedov wrote:
> On Fri,  1 Oct 2021 18:33:49 +0100
> Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> 
> > Add a function that generates a Virtual I/O Translation table (VIOT),
> > describing the topology of paravirtual IOMMUs. The table is created when
> > instantiating a virtio-iommu device. It contains a virtio-iommu node and
> 
> perhaps
> s/when instantiating ... ./if a virtio-iommu device present/
> 
> > PCI Range nodes for endpoints managed by the IOMMU. By default, a single
> > node describes all PCI devices. When passing the "default_bus_bypass_iommu"
> > machine option and "bypass_iommu" PXB option, only buses that do not
> > bypass the IOMMU are described by PCI Range nodes.
> 
> 
> modulo comments, patch looks fine to me from ACPI point of view.
> 
> but I don't know if values used for describing PCI structures
> make any sense so this might need an ACK from a person who knows
> PCI innards better.

For what it's worth I mainly looked at other similar tables (IORT, DMAR
and IVRS) to figure out what values I should use

[...]
> > +static int build_pci_range_node(Object *obj, void *opaque)
> > +{
> > +    struct viot_pci_ranges *pci_ranges = opaque;
> > +    GArray *blob = pci_ranges->blob;
> > +
> > +    if (object_dynamic_cast(obj, TYPE_PCI_HOST_BRIDGE)) {
> > +        PCIBus *bus = PCI_HOST_BRIDGE(obj)->bus;
> > +
> > +        if (bus && !pci_bus_bypass_iommu(bus)) {
> > +            int min_bus, max_bus;
> > +
> > +            pci_bus_range(bus, &min_bus, &max_bus);
> > +
> > +            /* Type (PCI range) */
> see [1] below
> 
> > +            build_append_int_noprefix(blob, 1, 1);
> > +            /* Reserved */
> > +            build_append_int_noprefix(blob, 0, 1);
> > +            /* Length */
> > +            build_append_int_noprefix(blob, 24, 2);
> 
> spec should be fixed to state length value for fixed length structures
> like it's done in ACPI specs, I who we should poke at to make this happen.

That doesn't seem to be applied rigorously. Several fixed-size structures
don't state their sizes, for example "5.2.25.7 NVDIMM Block Data Window
Region Structure", "5.2.25.9 Platform Capabilities Structure", "5.2.26.1.1
ACPI_NAMESPACE_DEVICE based Secure Device Structure".

> 
> zzzz
> > +            /* Endpoint start */
> > +            build_append_int_noprefix(blob, PCI_BUILD_BDF(min_bus, 0), 4);
> > +            /* PCI Segment start */
> > +            build_append_int_noprefix(blob, 0, 2);
> > +            /* PCI Segment end */
> > +            build_append_int_noprefix(blob, 0, 2);
> zzzz
> see comment [2]
> 
> > +            /* PCI BDF start */
> > +            build_append_int_noprefix(blob, PCI_BUILD_BDF(min_bus, 0), 2);
> > +            /* PCI BDF end */
> > +            build_append_int_noprefix(blob, PCI_BUILD_BDF(max_bus, 0xff), 2);
> > +            /* Output node */
> > +            build_append_int_noprefix(blob, pci_ranges->output_node, 2);
> > +            /* Reserved */
> > +            build_append_int_noprefix(blob, 0, 6);
> > +
> > +            pci_ranges->count++;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> > +/*
> > + * Generate a VIOT table with one PCI-based virtio-iommu that manages PCI
> > + * endpoints.
> > + */
> 
> this comment needs to state spec name/version, otherwise it's not clear
> what code below is based on (example: build_dmar_q35).
> 
> Also since there is no final spec yet and spec doesn't have permanent
> hosting place (i.e. hosted by one of specs org), I'd consider
> link in cover letter 'dead' and not suitable for long term use.

Yes, I'll throw those documents out once the final spec is out

> So we should shovel spec docs/specs and point to it in this comment

I could write "Defined in the ACPI Specification (Version TBD)"
For all I know it could be version 6.5 or 7.0...

> 
> > +void build_viot(MachineState *ms, GArray *table_data, BIOSLinker *linker,
> > +                uint16_t virtio_iommu_bdf, const char *oem_id,
> > +                const char *oem_table_id)
> > +{
> > +    /* The virtio-iommu node follows the 48-bytes header */
> > +    int viommu_off = 48;
> > +    AcpiTable table = { .sig = "VIOT", .rev = 0,
> > +                        .oem_id = oem_id, .oem_table_id = oem_table_id };
> > +    struct viot_pci_ranges pci_ranges = {
> > +        .output_node = viommu_off,
> > +        .blob = g_array_new(false, true /* clear */, 1),
> > +    };
> > +
> > +    /* Build the list of PCI ranges that this viommu manages */
> > +    object_child_foreach_recursive(OBJECT(ms), build_pci_range_node,
> > +                                   &pci_ranges);
> > +
> > +    /* ACPI table header */
> > +    acpi_table_begin(&table, table_data);
> > +    /* Node count */
> > +    build_append_int_noprefix(table_data, pci_ranges.count + 1, 2);
> > +    /* Node offset */
> > +    build_append_int_noprefix(table_data, viommu_off, 2);
> > +    /* Reserved */
> > +    build_append_int_noprefix(table_data, 0, 8);
> > +
> > +    /* Virtio-iommu node */
> > +    /* Type (virtio-pci IOMMU)  */
> 
> (1)
> /* Type */
> > +    build_append_int_noprefix(table_data, 3, 1);
>   s:3,:3 /* virtio-pci IOMMU */,:
> 
> check-patch will spit out warning but that kind comment
> is common practice with ACPI code

> 
> > +    /* Reserved */
> > +    build_append_int_noprefix(table_data, 0, 1);
> > +    /* Length */
> > +    build_append_int_noprefix(table_data, 16, 2);
> > +    /* PCI Segment */
> > +    build_append_int_noprefix(table_data, 0, 2);
> (2)
> can we fetch _SEG value from device instead of hard-codding value here?

Looking for "segment" and "domain" I couldn't find any dynamic segment
number, 0 seems to be hardcoded everywhere (hw/acpi/pci.c,
hw/i386/acpi-build.c, hw/arm/virt.c, hw/arm/virt-acpi-build.c).

> 
> I might be obvious to PCI folks,
> but it would be better have at least a comment explaining
> where these values come from

I could add that "QEMU only implements segment 0"

Thanks,
Jean

> 
> Michael,
> what do you think?
> 
> > +    /* PCI BDF number */
> > +    build_append_int_noprefix(table_data, virtio_iommu_bdf, 2);
> > +    /* Reserved */
> > +    build_append_int_noprefix(table_data, 0, 8);
> > +
> > +    /* PCI ranges found above */
> > +    g_array_append_vals(table_data, pci_ranges.blob->data,
> > +                        pci_ranges.blob->len);
> > +    g_array_free(pci_ranges.blob, true);
> > +
> > +    acpi_table_end(linker, &table);
> > +}
> > +
> > diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
> > index 3b5e118c54..622b0b50b7 100644
> > --- a/hw/acpi/Kconfig
> > +++ b/hw/acpi/Kconfig
> > @@ -51,6 +51,10 @@ config ACPI_VMGENID
> >      default y
> >      depends on PC
> >  
> > +config ACPI_VIOT
> > +    bool
> > +    depends on ACPI
> > +
> >  config ACPI_HW_REDUCED
> >      bool
> >      select ACPI
> > diff --git a/hw/acpi/meson.build b/hw/acpi/meson.build
> > index 7d8c0eb43e..adf6347bc4 100644
> > --- a/hw/acpi/meson.build
> > +++ b/hw/acpi/meson.build
> > @@ -20,6 +20,7 @@ acpi_ss.add(when: 'CONFIG_ACPI_APEI', if_true: files('ghes.c'), if_false: files(
> >  acpi_ss.add(when: 'CONFIG_ACPI_PIIX4', if_true: files('piix4.c'))
> >  acpi_ss.add(when: 'CONFIG_ACPI_PCIHP', if_true: files('pcihp.c'))
> >  acpi_ss.add(when: 'CONFIG_ACPI_PCIHP', if_false: files('acpi-pci-hotplug-stub.c'))
> > +acpi_ss.add(when: 'CONFIG_ACPI_VIOT', if_true: files('viot.c'))
> >  acpi_ss.add(when: 'CONFIG_ACPI_X86_ICH', if_true: files('ich9.c', 'tco.c'))
> >  acpi_ss.add(when: 'CONFIG_IPMI', if_true: files('ipmi.c'), if_false: files('ipmi-stub.c'))
> >  acpi_ss.add(when: 'CONFIG_PC', if_false: files('acpi-x86-stub.c'))
>