Bug 1235580
| Summary: | RFE: Enable the intel-iommu device in QEMU | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Daniel Berrangé <berrange> | |
| Component: | qemu-kvm-rhev | Assignee: | Miroslav Rezanina <mrezanin> | |
| Status: | CLOSED ERRATA | QA Contact: | Pei Zhang <pezhang> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 7.3 | CC: | ailan, alex.williamson, berrange, chayang, fbaudin, hhuang, huding, jinzhao, juzhang, kchamart, knoel, mrezanin, mst, pezhang, sgordon, sherold, virt-maint, xfu, xiywang | |
| Target Milestone: | rc | Keywords: | FutureFeature | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | qemu-kvm-rhev-2.6.0-1.el7 | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1235581 (view as bug list) | Environment: | ||
| Last Closed: | 2016-11-07 20:25:12 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1235581, 1333282 | |||
|
Description
Daniel Berrangé
2015-06-25 08:55:08 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? 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 (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. (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? (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. 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. 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? Thanks Alex. Set this bug as 'VERIFIED' as Comment 14, Comment 15, Comment 20 and Comment 21. 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 |