hardware: provision system with iommu enabled

[snits]

With beaker it is possible using the key_value element to find systems that have an iommu enabled (currently for x86, and in the near future aarch64 as well) by looking to for the VIRT_IOMMU key having a value of one.

Example of beaker xml to find a system with the setting, here looking for an Intel system with more than 1 disk and an iommu enabled:

<hostrequires>
  <and>
    <key_value op="=" key="VIRT_IOMMU" value="1"/>
    <key_value op=">" key="NR_DISKS" value="1"/>
    <cpu>
      <!-- GenuineIntel, AuthenticAMD -->
      <vendor op="==" value="GenuineIntel"/>
    </cpu>
    <system>
      <hypervisor op="=" value=""/>
      <has_console op="=" value="True"/>
    </system>
  </and>
</hostrequires>

Currently this key is created during system inventory by beaker-system-scan. beaker-system-scan, depending on the system architecture, looks for the relevant acpi table (DMAR for Intel, IVRS for AMD, and IORT for ARM) and does a sanity check to see that it has an expected entry. The main reason behind this is because by default the Intel IOMMU kernel module is not enabled, so by checking the acpi tables it can be seen that it is enabled in the bios. For AMD and ARM it would probably be simpler to look and see that the /sys/kernel/iommu_groups directly is populated. That would also work for checking an Intel based system, if it is booted with intel_iommu=on.

Another thought though, is there currently a way for someone to provision a guest that has a device passed through from the host, or a host capable of that? If yes, then the key might not be of use to someone beyond me or needed. If there already is a way to find a host capable of providing that support to a guest that would probably work for me if I can provision the host.

[happz]

Seems like a low-hanging fruit:

• beaker would transform this into key_value element
• artemis would do the same - we should check whether this is something AWS/OpenStack may deliver, but Beaker would
• virtual might be able to construct corresponding VM, if there's a support for such a parameter
• the rest - container, local - would simply emit the expected "sorry, no can do" warning and proceed.

[qiankehan]

For virtual.libvirt, there is 3 types of emulated iommu devices:

1. intel: supported arch is x86_64(q35 machine type). Requires libvirt>=2.1.0, qemu>=2.2.0, guest kernel>=3.1
2. smmuv3: supported arch is aarch64(virt machine type). Requires libvirt>=5.5.0, qemu=>3.0, guest kernel>=3.10
3. virtio: supported arches is x86_64(q35) and aarch64(virt). Requires libvirt=>8.3.0, qemu>=5.0, guest kernel>=5.1.

So there are 2 ways to implement iommu to virtual:

• intel(for x86_64) + smmuv3(for aarch64)
• virtio(for both arches)

I prefer the first one because it could work on centos8(libvirt of centos8 is based on 8.0.0)

[qiankehan]

For the iommu support of testcloud, I have send a PR https://pagure.io/testcloud/pull-request/172

[happz]

@qiankehan on the specification level, do you think that simple iommu: true, as in "has IOMMU", would suffice? The models supported by virtual and testcloud seem more like implementation details of the virtual plugin, something that the plugin would pick depending on the requested architecture rather than a detail the user would request.

On the other hand, it may be useful, even though I don't have any use case for it right now. We can construct it similarly to zcrypt or virtualization:

iommu:
    ".*" or "any" for "must have IOMMU, don't care about the model", or an actual model, like "virtio"
    model: ...

[qiankehan]

@qiankehan on the specification level, do you think that simple iommu: true, as in "has IOMMU", would suffice? The models supported by virtual and testcloud seem more like implementation details of the virtual plugin, something that the plugin would pick depending on the requested architecture rather than a detail the user would request.

On the other hand, it may be useful, even though I don't have any use case for it right now. We can construct it similarly to zcrypt or virtualization:

iommu:
    ".*" or "any" for "must have IOMMU, don't care about the model", or an actual model, like "virtio"
    model: ...

For iommu: true, the problem is the version of virtualization components and the guest of kernel may not support the virtual iommu. So I think your idea is better. Then the specification will be like:

iommu:
is-supported: true|false
model: "virtio"|"smmuv3"|"intel"

The first property will be used in the beaker plugin. The second property will be used in the virtual plugin. For the artemis plugin, both could be used: artemis.openstack1 will use model property; artemis.beaker will use is-supported property, just like the beaker plugin; For artemis.azure, it is the same to the beaker plugin because the iommu is set by the policy2 secureBootEnabled; For artemis.aws, I did find out how to set iommu in its document.