| Message ID | 20210810084505.2257983-1-jean-philippe@linaro.org |
|---|---|
| Headers | show |
| Series | virtio-iommu: Add ACPI support | expand |
Hi Jean, On 8/10/21 10:45 AM, Jean-Philippe Brucker wrote: > Allow instantiating a virtio-iommu device on ACPI systems by adding a > Virtual I/O Translation table (VIOT). Enable x86 support for VIOT. Don't you need your other patch "virtio-iommu: Default to bypass during boot"? Without this latter, for me the guest fails to boot. Thanks Eric > > With a simple configuration the table contains a virtio-iommu-pci node > and a pci-range node: > > qemu-system-aarch64 -M virt -bios QEMU_EFI.fd > -device virtio-iommu ... > > $ iasl -d ... > [000h 0000 4] Signature : "VIOT" > > [024h 0036 2] Node count : 0002 > [026h 0038 2] Node offset : 0030 > > [030h 0048 1] Type : 03 [VirtIO-PCI IOMMU] > [032h 0050 2] Length : 0010 > [034h 0052 2] PCI Segment : 0000 > [036h 0054 2] PCI BDF number : 0030 > > [040h 0064 1] Type : 01 [PCI Range] > [042h 0066 2] Length : 0018 > [044h 0068 4] Endpoint start : 00000000 > [048h 0072 2] PCI Segment start : 0000 > [04Ah 0074 2] PCI Segment end : 0000 > [04Ch 0076 2] PCI BDF start : 0000 > [04Eh 0078 2] PCI BDF end : 00FF > [050h 0080 2] Output node : 0030 > > With a more complex topology multiple PCI Range nodes describe the system: > > qemu-system-aarch64 -bios QEMU_EFI.fd -device virtio-iommu > -M virt,default_bus_bypass_iommu=true > -device pxb-pcie,bus_nr=0x10,id=pcie.1000,bus=pcie.0 > -device pxb-pcie,bus_nr=0x20,id=pcie.2000,bus=pcie.0,bypass_iommu=true > -device pxb-pcie,bus_nr=0x30,id=pcie.3000,bus=pcie.0 > > [024h 0036 2] Node count : 0003 > [026h 0038 2] Node offset : 0030 > > [030h 0048 1] Type : 03 [VirtIO-PCI IOMMU] > [032h 0050 2] Length : 0010 > [034h 0052 2] PCI Segment : 0000 > [036h 0054 2] PCI BDF number : 0020 > > [040h 0064 1] Type : 01 [PCI Range] > [042h 0066 2] Length : 0018 > [044h 0068 4] Endpoint start : 00003000 > [048h 0072 2] PCI Segment start : 0000 > [04Ah 0074 2] PCI Segment end : 0000 > [04Ch 0076 2] PCI BDF start : 3000 > [04Eh 0078 2] PCI BDF end : 32FF > [050h 0080 2] Output node : 0030 > > [058h 0088 1] Type : 01 [PCI Range] > [05Ah 0090 2] Length : 0018 > [05Ch 0092 4] Endpoint start : 00001000 > [060h 0096 2] PCI Segment start : 0000 > [062h 0098 2] PCI Segment end : 0000 > [064h 0100 2] PCI BDF start : 1000 > [066h 0102 2] PCI BDF end : 11FF > [068h 0104 2] Output node : 0030 > > > The VIOT table description will be in the next release of ACPI. > In the meantime you can find a description at > https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > Linux support for VIOT was added in version 5.14 > > Eric Auger (1): > pc: Allow instantiating a virtio-iommu device > > Jean-Philippe Brucker (5): > acpi: Add VIOT structure definitions > hw/acpi: Add VIOT table > hw/arm/virt-acpi-build: Add VIOT table for virtio-iommu > hw/arm/virt: Remove device tree restriction for virtio-iommu > pc: Add VIOT table for virtio-iommu > > hw/acpi/viot.h | 13 ++++++ > include/hw/acpi/acpi-defs.h | 60 ++++++++++++++++++++++++++ > include/hw/i386/pc.h | 2 + > hw/acpi/viot.c | 82 ++++++++++++++++++++++++++++++++++++ > hw/arm/virt-acpi-build.c | 7 +++ > hw/arm/virt.c | 10 +---- > hw/i386/acpi-build.c | 5 +++ > hw/i386/pc.c | 18 +++++++- > hw/virtio/virtio-iommu-pci.c | 7 --- > hw/acpi/Kconfig | 4 ++ > hw/acpi/meson.build | 1 + > hw/arm/Kconfig | 1 + > hw/i386/Kconfig | 1 + > 13 files changed, 195 insertions(+), 16 deletions(-) > create mode 100644 hw/acpi/viot.h > create mode 100644 hw/acpi/viot.c >
Hi Eric, On Tue, Aug 17, 2021 at 04:58:01PM +0200, Eric Auger wrote: > Hi Jean, > > On 8/10/21 10:45 AM, Jean-Philippe Brucker wrote: > > Allow instantiating a virtio-iommu device on ACPI systems by adding a > > Virtual I/O Translation table (VIOT). Enable x86 support for VIOT. > > Don't you need your other patch > "virtio-iommu: Default to bypass during boot"? > > Without this latter, for me the guest fails to boot. Good point, I think I've been lucky during my testing. My bootloader and kernel are on virtio-blk-pci devices and as I wasn't explicitly enabling the "iommu_platform" parameter, they would bypass the IOMMU. When enabling the parameter, boot hangs since the IOMMU isn't enabled when the bootloader needs to fetch the kernel, and DMA faults. That parameter is specific to virtio devices. Using another storage for bootloader and kernel will result in failure to boot. I've been postponing the boot-bypass patch since it requires a specification change to be done right, but it's next on my list. Thanks, Jean
Hi Jean, On 8/27/21 3:30 PM, Jean-Philippe Brucker wrote: > Hi Eric, > > On Tue, Aug 17, 2021 at 04:58:01PM +0200, Eric Auger wrote: >> Hi Jean, >> >> On 8/10/21 10:45 AM, Jean-Philippe Brucker wrote: >>> Allow instantiating a virtio-iommu device on ACPI systems by adding a >>> Virtual I/O Translation table (VIOT). Enable x86 support for VIOT. >> Don't you need your other patch >> "virtio-iommu: Default to bypass during boot"? >> >> Without this latter, for me the guest fails to boot. > Good point, I think I've been lucky during my testing. My bootloader and > kernel are on virtio-blk-pci devices and as I wasn't explicitly enabling > the "iommu_platform" parameter, they would bypass the IOMMU. When enabling > the parameter, boot hangs since the IOMMU isn't enabled when the > bootloader needs to fetch the kernel, and DMA faults. That parameter is > specific to virtio devices. Using another storage for bootloader and > kernel will result in failure to boot. > > I've been postponing the boot-bypass patch since it requires a > specification change to be done right, but it's next on my list. The boot-bypass feature seems a critical feature to overcome the current v3 limitation. Are there big spec changes required? Maybe we shall work on this in parallel of this series because, to me, it will delay the integration of virtio-iommu in libvirt for instance. Thanks Eric > > Thanks, > Jean >
On Wed, Sep 29, 2021 at 11:18:39AM +0200, Eric Auger wrote: > > I've been postponing the boot-bypass patch since it requires a > > specification change to be done right, but it's next on my list. > The boot-bypass feature seems a critical feature to overcome the current > v3 limitation. Are there big spec changes required? Maybe we shall work > on this in parallel of this series because, to me, it will delay the > integration of virtio-iommu in libvirt for instance. I agree. The spec change is ready but I wanted to tidy up the driver implementation first. I'll send something out this week Thanks, Jean