[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 01/11] hw/acpi: Add VIOT table
From: |
Jean-Philippe Brucker |
Subject: |
Re: [PATCH v4 01/11] hw/acpi: Add VIOT table |
Date: |
Fri, 8 Oct 2021 16:20:11 +0100 |
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'))
>
- [PATCH v4 00/11] virtio-iommu: Add ACPI support, Jean-Philippe Brucker, 2021/10/01
- [PATCH v4 05/11] hw/arm/virt: Use object_property_set instead of qdev_prop_set, Jean-Philippe Brucker, 2021/10/01
- [PATCH v4 04/11] hw/arm/virt: Reject instantiation of multiple IOMMUs, Jean-Philippe Brucker, 2021/10/01
- [PATCH v4 06/11] hw/i386: Move vIOMMU uniqueness check into pc.c, Jean-Philippe Brucker, 2021/10/01
- [PATCH v4 01/11] hw/acpi: Add VIOT table, Jean-Philippe Brucker, 2021/10/01
- [PATCH v4 09/11] tests/acpi: add test cases for VIOT, Jean-Philippe Brucker, 2021/10/01
- [PATCH v4 07/11] pc: Allow instantiating a virtio-iommu device, Jean-Philippe Brucker, 2021/10/01