Open snits opened 10 months ago
Seems like a low-hanging fruit:
beaker
would transform this into key_value
elementartemis
would do the same - we should check whether this is something AWS/OpenStack may deliver, but Beaker wouldvirtual
might be able to construct corresponding VM, if there's a support for such a parametercontainer
, local
- would simply emit the expected "sorry, no can do" warning and proceed.For virtual.libvirt, there is 3 types of emulated iommu devices:
So there are 2 ways to implement iommu to virtual:
I prefer the first one because it could work on centos8(libvirt of centos8 is based on 8.0.0)
For the iommu support of testcloud, I have send a PR https://pagure.io/testcloud/pull-request/172
@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 on the specification level, do you think that simple
iommu: true
, as in "has IOMMU", would suffice? The models supported byvirtual
andtestcloud
seem more like implementation details of thevirtual
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
orvirtualization
: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.
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:
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.