search for: platform_iommu

On Thu, 2018-08-02 at 20:19 +0300, Michael S. Tsirkin wrote: > > I see. So yes, given that device does not know or care, using > virtio features is an awkward fit. > > So let's say as a quick fix for you maybe we could generalize the > xen_domain hack, instead of just checking xen_domain check some static > branch. Then teach xen and others to enable that.> > OK

On Thu, 2018-08-02 at 20:19 +0300, Michael S. Tsirkin wrote: > > I see. So yes, given that device does not know or care, using > virtio features is an awkward fit. > > So let's say as a quick fix for you maybe we could generalize the > xen_domain hack, instead of just checking xen_domain check some static > branch. Then teach xen and others to enable that.> > OK

...ning that they can't even set a flag in qemu though. If that's the case the stack in question is way too inflexible. > Both in the flag naming and the implementation there is an implication > of DMA API == IOMMU, which is fundamentally wrong. Maybe we need to extend the meaning of PLATFORM_IOMMU or rename it. It's possible that some setups will benefit from a more fine-grained approach where some aspects of the DMA API are bypassed, others aren't. This seems to be what was being asked for in this thread, with comments claiming IOMMU flag adds too much overhead. > The DMA API...

...ning that they can't even set a flag in qemu though. If that's the case the stack in question is way too inflexible. > Both in the flag naming and the implementation there is an implication > of DMA API == IOMMU, which is fundamentally wrong. Maybe we need to extend the meaning of PLATFORM_IOMMU or rename it. It's possible that some setups will benefit from a more fine-grained approach where some aspects of the DMA API are bypassed, others aren't. This seems to be what was being asked for in this thread, with comments claiming IOMMU flag adds too much overhead. > The DMA API...

.... > > > > Right but as I tried to say doing that brings us to a bunch of issues > with using DMA APIs in virtio. Put simply DMA APIs weren't designed for > guest to hypervisor communication. I'm not sure I see the problem, see below > When we do (as is the case with PLATFORM_IOMMU right now) this adds a > bunch of overhead which we need to get rid of if we are to switch to > PLATFORM_IOMMU by default. We need to fix that. So let's differenciate the two problems of having an IOMMU (real or emulated) which indeeds adds overhead etc... and using the DMA API. At the...

.... > > > > Right but as I tried to say doing that brings us to a bunch of issues > with using DMA APIs in virtio. Put simply DMA APIs weren't designed for > guest to hypervisor communication. I'm not sure I see the problem, see below > When we do (as is the case with PLATFORM_IOMMU right now) this adds a > bunch of overhead which we need to get rid of if we are to switch to > PLATFORM_IOMMU by default. We need to fix that. So let's differenciate the two problems of having an IOMMU (real or emulated) which indeeds adds overhead etc... and using the DMA API. At the...

...custom ones that do the appropriate swiotlb gunk. > > Cheers, > Ben. > Right but as I tried to say doing that brings us to a bunch of issues with using DMA APIs in virtio. Put simply DMA APIs weren't designed for guest to hypervisor communication. When we do (as is the case with PLATFORM_IOMMU right now) this adds a bunch of overhead which we need to get rid of if we are to switch to PLATFORM_IOMMU by default. We need to fix that. -- MST

On Thu, May 31, 2018 at 09:09:24AM +0530, Anshuman Khandual wrote: > On 05/24/2018 12:51 PM, Ram Pai wrote: > > On Wed, May 23, 2018 at 09:50:02PM +0300, Michael S. Tsirkin wrote: > >> subj: s/virito/virtio/ > >> > > ..snip.. > >>> machine_subsys_initcall_sync(pseries, tce_iommu_bus_notifier_init); > >>> + > >>> +bool

On Thu, May 31, 2018 at 09:09:24AM +0530, Anshuman Khandual wrote: > On 05/24/2018 12:51 PM, Ram Pai wrote: > > On Wed, May 23, 2018 at 09:50:02PM +0300, Michael S. Tsirkin wrote: > >> subj: s/virito/virtio/ > >> > > ..snip.. > >>> machine_subsys_initcall_sync(pseries, tce_iommu_bus_notifier_init); > >>> + > >>> +bool

...ing to set, because they are not using an iommu. They probably don't even do any address translation. > > Both in the flag naming and the implementation there is an implication > > of DMA API == IOMMU, which is fundamentally wrong. > > Maybe we need to extend the meaning of PLATFORM_IOMMU or rename it. And the explanation. > > It's possible that some setups will benefit from a more > fine-grained approach where some aspects of the DMA > API are bypassed, others aren't. Hell no. DMA API = abstraction for any possble platform wart. We are not going to make thi...

...dma api. make extra decisions in platform code then. > > > > > > > > > Both in the flag naming and the implementation there is an implication > > > of DMA API == IOMMU, which is fundamentally wrong. > > > > Maybe we need to extend the meaning of PLATFORM_IOMMU or rename it. > > > > It's possible that some setups will benefit from a more > > fine-grained approach where some aspects of the DMA > > API are bypassed, others aren't. > > > > This seems to be what was being asked for in this thread, > > with c...

...rm code then. > > > > > > > > > > > > > > Both in the flag naming and the implementation there is an implication > > > > of DMA API == IOMMU, which is fundamentally wrong. > > > > > > Maybe we need to extend the meaning of PLATFORM_IOMMU or rename it. > > > > > > It's possible that some setups will benefit from a more > > > fine-grained approach where some aspects of the DMA > > > API are bypassed, others aren't. > > > > > > This seems to be what was being asked for in...

...e do, because our emulation platforms have an IOMMU > for all virtio devices). > > Will Right that's not very different from placing the device within the IOMMU domain but in fact bypassing the IOMMU. I wonder whether anyone ever needs a non coherent virtio-mmio. If yes we can extend PLATFORM_IOMMU to cover that or add another bit. What exactly do the non-coherent ops do that causes the corruption? -- MST

...; A platform will be able override dma-range using the dev->bus_dma_mask > field starting in 4.19. But we'll still need a way how to > > a) document in the virtio spec that all bus dma quirks are to be > applied I agree it's a good idea. In particular I suspect that PLATFORM_IOMMU should be extended to cover that. But see below. > b) a way to document in a virtio-related spec how the bus handles > dma for Ben's totally fucked up hypervisor. Without that there > is not way we'll get interoperable implementations. So in this case however I'...

On Fri, Aug 03, 2018 at 12:05:07AM -0700, Christoph Hellwig wrote: > On Thu, Aug 02, 2018 at 04:13:09PM -0500, Benjamin Herrenschmidt wrote: > > So let's differenciate the two problems of having an IOMMU (real or > > emulated) which indeeds adds overhead etc... and using the DMA API. > > > > At the moment, virtio does this all over the place: > > > >

On Fri, Aug 03, 2018 at 12:05:07AM -0700, Christoph Hellwig wrote: > On Thu, Aug 02, 2018 at 04:13:09PM -0500, Benjamin Herrenschmidt wrote: > > So let's differenciate the two problems of having an IOMMU (real or > > emulated) which indeeds adds overhead etc... and using the DMA API. > > > > At the moment, virtio does this all over the place: > > > >

On Tue, Jul 31, 2018 at 03:36:22PM -0500, Benjamin Herrenschmidt wrote: > On Tue, 2018-07-31 at 10:30 -0700, Christoph Hellwig wrote: > > > However the question people raise is that DMA API is already full of > > > arch-specific tricks the likes of which are outlined in your post linked > > > above. How is this one much worse? > > > > None of these warts

On Tue, Jul 31, 2018 at 03:36:22PM -0500, Benjamin Herrenschmidt wrote: > On Tue, 2018-07-31 at 10:30 -0700, Christoph Hellwig wrote: > > > However the question people raise is that DMA API is already full of > > > arch-specific tricks the likes of which are outlined in your post linked > > > above. How is this one much worse? > > > > None of these warts

...64 input_start = 0; > + u64 input_end = -1UL; > + int ret; > + > + if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) > + return -ENODEV; I'm a bit confused about what will happen if this device happens to be behind an iommu itself. If we can't handle that, should we clear PLATFORM_IOMMU e.g. like the balloon does? > + > + viommu = devm_kzalloc(dev, sizeof(*viommu), GFP_KERNEL); > + if (!viommu) > + return -ENOMEM; > + > + spin_lock_init(&viommu->request_lock); > + ida_init(&viommu->domain_ids); > + viommu->dev = dev; > + viommu->vd...

...64 input_start = 0; > + u64 input_end = -1UL; > + int ret; > + > + if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) > + return -ENODEV; I'm a bit confused about what will happen if this device happens to be behind an iommu itself. If we can't handle that, should we clear PLATFORM_IOMMU e.g. like the balloon does? > + > + viommu = devm_kzalloc(dev, sizeof(*viommu), GFP_KERNEL); > + if (!viommu) > + return -ENOMEM; > + > + spin_lock_init(&viommu->request_lock); > + ida_init(&viommu->domain_ids); > + viommu->dev = dev; > + viommu->vd...