Add the iommu specification for hardware

[qiankehan]

Pull Request Checklist

• implement the feature
• write the documentation
• extend the test coverage
• update the specification
• adjust plugin docstring
• modify the json schema
• mention the version
• include a release note

[qiankehan]

Thanks for your reviews~ I have updated the PR~

[qiankehan]

Hi, I have updated the PR and add the beaker plugin support. Please help review it. Thank you~

[martinhoyer]

I'm not sure about the 'model' part. In beaker, I don't see a way to filter by (maybe I'm missing something).

While other provisioning methods could theoretically support this going forward, I wouldn't expose it to users if there is no use for it now.
We can filter by cpu to at least get the intel/amd/arm.

[happz]

I'm not sure about the 'model' part. In beaker, I don't see a way to filter by (maybe I'm missing something).

While other provisioning methods could theoretically support this going forward, I wouldn't expose it to users if there is no use for it now. We can filter by cpu to at least get the intel/amd/arm.

IIUIC, libvirt and qemu-based plugins, like virtual, can and will make use of this requirement. And I would like to avoid encoding one requirement into another, i.e. using cpu.vendor-name to pick a model of IOMMU. That complicates reasoning about requirements and makes the picture opaque: do they use it to select a CPU, or something else we don’t support yet? It’s happening with hostname quite often.

More discussion in #2392

[martinhoyer]

I'm not sure about the 'model' part. In beaker, I don't see a way to filter by (maybe I'm missing something).
While other provisioning methods could theoretically support this going forward, I wouldn't expose it to users if there is no use for it now. We can filter by cpu to at least get the intel/amd/arm.

IIUIC, libvirt and qemu-based plugins, like virtual, can and will make use of this requirement. And I would like to avoid encoding one requirement into another, i.e. using cpu.vendor-name to pick a model of IOMMU. That complicates reasoning about requirements and makes the picture opaque: do they use it to select a CPU, or something else we don’t support yet? It’s happening with hostname quite often.

More discussion in #2392

Ok cool, from the discussion I got the impression it'll be only used by beaker provisioning.

[thrix]

LGTM

[happz]

Added discuss label - we're still unsure about model-name being used to pick the IOMMU "model". We're considering model, model-name, but also platform, driver, and maybe other ideas. Leaving the PR open for now, we're going to get back to it next week.

[thrix]

This was discussed on the hacking meeting, and we will go with current version.

[psss]

Just did a quick check with the following provision step config:

provision:
    how: beaker
    hardware:
        iommu:
            is-supported: true

But don't see VIRT_IOMMU mentioned in the Beaker job xml. Have I missed anything? @happz, does it work for you?

[psss]

The change looks good, but I don't see any hardware requirement generated in the Beaker job. This would also deserve at least a short release note.

[happz]

Just did a quick check with the following provision step config:

provision:
    how: beaker
    hardware:
        iommu:
            is-supported: true

But don't see VIRT_IOMMU mentioned in the Beaker job xml. Have I missed anything? @happz, does it work for you?

I believe that is cause by the branch being outdated, it's missing this patch: 2bef9dd

[happz]

/packit build

[psss]

I believe that is cause by the branch being outdated, it's missing this patch: 2bef9dd

Right, now it works! 👍

[psss]

Added a short release note, fixed & simplified the test in 9deed7e. Now should be good for merge.

[psss]

/packit build

[psss]

/packit build

[psss]

/packit build