Bug 1235580 - RFE: Enable the intel-iommu device in QEMU
Summary: RFE: Enable the intel-iommu device in QEMU
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Miroslav Rezanina
QA Contact: Pei Zhang
URL:
Whiteboard:
Depends On:
Blocks: 1235581 1333282
TreeView+ depends on / blocked
 
Reported: 2015-06-25 08:55 UTC by Daniel Berrangé
Modified: 2016-11-07 20:25 UTC (History)
19 users (show)

Fixed In Version: qemu-kvm-rhev-2.6.0-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1235581 (view as bug list)
Environment:
Last Closed: 2016-11-07 20:25:12 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2673 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2016-11-08 01:06:13 UTC

Description Daniel Berrangé 2015-06-25 08:55:08 UTC
Description of problem:
The vast majority of testing by both the community on OpenStack upstream and Red Hat QE for RHEL-OSP products is done inside virtualized guests, using either TCG or nested-KVM.

One of the few areas where we are unable to use virtualization is in the area of PCI device assignment. This means we are limited in our ability to setup automated test suites for OpenStack, by access to small pool of physical hardware nodes. If QEMU were to provide IOMMU device emulation then it would be possible to move some of our PCI device assignment testing into a virtualized environment.

The new QEMU intel-iommu device looks like it would satisfy the needs for basic testing, even if there are a limited number of QEMU PCI devices we can use it with.

NB, this is not a request for intel-iommu to be marked fully supported for production deployment. RHEL OpenStack team would merely like it for dev/test scenarios at this time, so tech-preview would be sufficient enablement, if supportability is a concern. As such there is also no hard deadline we need it by.

Comment 2 Alex Williamson 2015-06-26 15:43:32 UTC
The trouble here is that this is an RFE for a feature that has no practical purpose in a production environment.  It only works for emulated devices and we have no customers asking to assign emulated devices to nested guests.  I fully agree that it can be useful in a development scenario by enabling users that don't actually have IOMMU hardware to validate device assignment scenarios.  However, tech-preview implies that the feature is slated for eventual support.  In this case, I can't agree that the feature is destined for anything more than a best effort development tool.  Do we have an precedent for including such features?  How do we differentiate it from "Tech preview"?  How do we limit it such that production customers are not relying on this feature?  Isn't this typically where we would encourage testing and development on Fedora hosts?

Comment 3 Daniel Berrangé 2015-07-02 12:28:02 UTC
Agree that tech-preview is not a 100% match, as that implies future full support. I'm not really sure how we express this kind of thing officially - it seems a similar scenario to the nested virt use case, so we perhaps we'll need to align our stories there

Comment 5 Karen Noel 2016-01-18 23:56:08 UTC
(In reply to Daniel Berrange from comment #3)
> Agree that tech-preview is not a 100% match, as that implies future full
> support. I'm not really sure how we express this kind of thing officially -
> it seems a similar scenario to the nested virt use case, so we perhaps we'll
> need to align our stories there

We call nested virt tech preview and do not recommend it for production use cases. We limit it, too. We document its non-support status, so there will be no confusion.

Comment 6 Stephen Gordon 2016-01-19 15:38:43 UTC
(In reply to Karen Noel from comment #5)
> (In reply to Daniel Berrange from comment #3)
> > Agree that tech-preview is not a 100% match, as that implies future full
> > support. I'm not really sure how we express this kind of thing officially -
> > it seems a similar scenario to the nested virt use case, so we perhaps we'll
> > need to align our stories there
> 
> We call nested virt tech preview and do not recommend it for production use
> cases. We limit it, too. We document its non-support status, so there will
> be no confusion.

Following Bug # 1187762 we only called it out as technology preview as of RHEL 7.2 though right? Before that we called it unsupported but included it for testing purposes, seems like that is what we would want to do here too?

Comment 7 Karen Noel 2016-02-05 22:45:31 UTC
(In reply to Stephen Gordon from comment #6)
> (In reply to Karen Noel from comment #5)
> > (In reply to Daniel Berrange from comment #3)
> > > Agree that tech-preview is not a 100% match, as that implies future full
> > > support. I'm not really sure how we express this kind of thing officially -
> > > it seems a similar scenario to the nested virt use case, so we perhaps we'll
> > > need to align our stories there
> > 
> > We call nested virt tech preview and do not recommend it for production use
> > cases. We limit it, too. We document its non-support status, so there will
> > be no confusion.
> 
> Following Bug # 1187762 we only called it out as technology preview as of
> RHEL 7.2 though right? 

Right, but mainly to help people figure out how to use it and make it clear it's not supported.

> Before that we called it unsupported but included it
> for testing purposes, seems like that is what we would want to do here too?

No-iommu is slightly different because it taints the kernel. It's tech preview of emulated IOMMU support? Sort of. It's available for development purposes only. Use at your own risk. I don't think there is an official term for that, so it's hard to document. We'll have to think of something.

Comment 8 Miroslav Rezanina 2016-05-05 07:44:59 UTC
There's linking dependency to intel-iommu device in QEMU 2.6 so we have to decide whether we want to keep this device enabled or it has to be disabled as disabling (unlike in RHEL 7.2 using QEMU 2.3) will require fixing the code.

Comment 9 Miroslav Rezanina 2016-06-08 08:58:54 UTC
Scott, can you provide decision whether we are going to enable intel_iommu device for 7.3 or should we prepare patch to keep it disabled?

Comment 22 Pei Zhang 2016-09-22 03:11:47 UTC
Thanks Alex.

Set this bug as 'VERIFIED' as Comment 14, Comment 15, Comment 20 and Comment 21.

Comment 24 errata-xmlrpc 2016-11-07 20:25:12 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html


Note You need to log in before you can comment on or make changes to this bug.