Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1265606 > unrolled thread
| Started by | "Michael S. Tsirkin" <mst@redhat.com> |
|---|---|
| First post | 2015-11-09 13:20 +0100 |
| Last post | 2015-11-10 20:40 +0100 |
| Articles | 4 on this page of 24 — 7 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v4 0/6] virtio core DMA API conversion "Michael S. Tsirkin" <mst@redhat.com> - 2015-11-09 13:20 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Paolo Bonzini <pbonzini@redhat.com> - 2015-11-09 13:30 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 00:30 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski <luto@amacapital.net> - 2015-11-10 01:50 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski <luto@amacapital.net> - 2015-11-10 03:20 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 06:30 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski <luto@amacapital.net> - 2015-11-10 06:40 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 11:40 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion "Michael S. Tsirkin" <mst@redhat.com> - 2015-11-10 13:50 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 21:40 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski <luto@amacapital.net> - 2015-11-10 20:00 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 23:30 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski <luto@amacapital.net> - 2015-11-11 00:50 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-11 01:50 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski <luto@amacapital.net> - 2015-11-11 05:50 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-11 06:10 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski <luto@amacapital.net> - 2015-11-10 06:40 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 07:30 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Jan Kiszka <jan.kiszka@siemens.com> - 2015-11-10 09:20 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 04:10 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Knut Omang <knut.omang@oracle.com> - 2015-11-10 10:50 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 11:50 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Joerg Roedel <jroedel@suse.de> - 2015-11-10 11:30 +0100
Re: [PATCH v4 0/6] virtio core DMA API conversion Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-11-10 20:40 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | Knut Omang <knut.omang@oracle.com> |
|---|---|
| Date | 2015-11-10 10:50 +0100 |
| Message-ID | <qtdIS-3jG-21@gated-at.bofh.it> |
| In reply to | #1266196 |
On Tue, 2015-11-10 at 13:04 +1100, Benjamin Herrenschmidt wrote: > On Mon, 2015-11-09 at 16:46 -0800, Andy Lutomirski wrote: > > The problem here is that in some of the problematic cases the > > virtio > > driver may not even be loaded. If someone runs an L1 guest with an > > IOMMU-bypassing virtio device and assigns it to L2 using vfio, then > > *boom* L1 crashes. (Same if, say, DPDK gets used, I think.) > > > > > > > > The only way out of this while keeping the "platform" stuff would > > > be to > > > also bump some kind of version in the virtio config (or PCI > > > header). I > > > have no other way to differenciate between "this is an old qemu > > > that > > > doesn't do the 'bypass property' yet" from "this is a virtio > > > device > > > that doesn't bypass". > > > > > > Any better idea ? > > > > I'd suggest that, in the absence of the new DT binding, we assume > > that > > any PCI device with the virtio vendor ID is passthrough on powerpc. > > I > > can do this in the virtio driver, but if it's in the platform code > > then vfio gets it right too (i.e. fails to load). > > The problem is there isn't *a* virtio vendor ID. It's the RedHat > vendor > ID which will be used by more than just virtio, so we need to > specifically list the devices. > > Additionally, that still means that once we have a virtio device that > actually uses the iommu, powerpc will not work since the "workaround" > above will kick in. > > The "in absence of the new DT binding" doesn't make that much sense. > > Those platforms use device-trees defined since the dawn of ages by > actual open firmware implementations, they either have no iommu > representation in there (Macs, the platform code hooks it all up) or > have various properties related to the iommu but no concept of > "bypass" > in there. > > We can *add* a new property under some circumstances that indicates a > bypass on a per-device basis, however that doesn't completely solve > it: > > - As I said above, what does the absence of that property mean ? An > old qemu that does bypass on all virtio or a new qemu trying to tell > you that the virtio device actually does use the iommu (or some other > environment that isn't qemu) ? > > - On things like macs, the device-tree is generated by openbios, it > would have to have some added logic to try to figure that out, which > means it needs to know *via different means* that some or all virtio > devices bypass the iommu. > > I thus go back to my original statement, it's a LOT easier to handle > if > the device itself is self describing, indicating whether it is set to > bypass a host iommu or not. For L1->L2, well, that wouldn't be the > first time qemu/VFIO plays tricks with the passed through device > configuration space... > > Note that the above can be solved via some kind of compromise: The > device self describes the ability to honor the iommu, along with the > property (or ACPI table entry) that indicates whether or not it does. > > IE. We could use the revision or ProgIf field of the config space for > example. Or something in virtio config. If it's an "old" device, we > know it always bypass. If it's a new device, we know it only bypasses > if the corresponding property is in. I still would have to sort out > the > openbios case for mac among others but it's at least a workable > direction. > > BTW. Don't you have a similar problem on x86 that today qemu claims > that everything honors the iommu in ACPI ? > > Unless somebody can come up with a better idea... Can something be done by means of PCIe capabilities? ATS (Address Translation Support) seems like a natural choice? Knut > Cheers, > Ben. > > -- > To unsubscribe from this list: send the line "unsubscribe sparclinux" > in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Benjamin Herrenschmidt <benh@kernel.crashing.org> |
|---|---|
| Date | 2015-11-10 11:50 +0100 |
| Message-ID | <qteEV-3V9-9@gated-at.bofh.it> |
| In reply to | #1266362 |
On Tue, 2015-11-10 at 10:45 +0100, Knut Omang wrote: > Can something be done by means of PCIe capabilities? > ATS (Address Translation Support) seems like a natural choice? Euh no... ATS is something else completely.... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Joerg Roedel <jroedel@suse.de> |
|---|---|
| Date | 2015-11-10 11:30 +0100 |
| Message-ID | <qtelz-3Oi-1@gated-at.bofh.it> |
| In reply to | #1266196 |
On Tue, Nov 10, 2015 at 01:04:36PM +1100, Benjamin Herrenschmidt wrote: > The "in absence of the new DT binding" doesn't make that much sense. > > Those platforms use device-trees defined since the dawn of ages by > actual open firmware implementations, they either have no iommu > representation in there (Macs, the platform code hooks it all up) or > have various properties related to the iommu but no concept of "bypass" > in there. > > We can *add* a new property under some circumstances that indicates a > bypass on a per-device basis, however that doesn't completely solve it: > > - As I said above, what does the absence of that property mean ? An > old qemu that does bypass on all virtio or a new qemu trying to tell > you that the virtio device actually does use the iommu (or some other > environment that isn't qemu) ? You have the same problem when real PCIe devices appear that speak virtio. I think the only real (still not very nice) solution is to add a quirk to powerpc platform code that sets noop dma-ops for the existing virtio vendor/device-ids and add a DT property to opt-out of that quirk. New vendor/device-ids (as for real devices) would just not be covered by the quirk and existing emulated devices continue to work. The absence of the property just means that the quirk is in place and the system assumes no translation for virtio devices. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Benjamin Herrenschmidt <benh@kernel.crashing.org> |
|---|---|
| Date | 2015-11-10 20:40 +0100 |
| Message-ID | <qtmVR-Qu-27@gated-at.bofh.it> |
| In reply to | #1266383 |
On Tue, 2015-11-10 at 11:27 +0100, Joerg Roedel wrote: > > You have the same problem when real PCIe devices appear that speak > virtio. I think the only real (still not very nice) solution is to add a > quirk to powerpc platform code that sets noop dma-ops for the existing > virtio vendor/device-ids and add a DT property to opt-out of that quirk. > > New vendor/device-ids (as for real devices) would just not be covered by > the quirk and existing emulated devices continue to work. Why woud real devices use new vendor/device IDs ? Also there are other cases such as using virtio between 2 partitions, which we could do under PowerVM ... that would require proper iommu usage with existing IDs. > The absence of the property just means that the quirk is in place and > the system assumes no translation for virtio devices. The only way that works forward for me (and possibly sparc & others, what about ARM ?) is if we *change* something in virtio qemu at the same time as we add some kind of property. For example the ProgIf field or revision ID field. That way I can key on that change. It's still tricky because I would have to somewhat tell my various firmwares (SLOF, OpenBIOS, OPAL, ...) so they can create the appropriate property, it's still hacky, but it would be workable. Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web