On Wed, Oct 28, 2015 at 11:13:29PM +0900, David Woodhouse wrote:> On Wed, 2015-10-28 at 16:05 +0200, Michael S. Tsirkin wrote: > > > > Short answer - platforms need a way to discover, and express different > > security requirements of different devices. > > Sure. PLATFORMS need that. Do not let it go anywhere near your device > drivers. Including the virtio drivers.But would there be any users of this outside the virtio subsystem? If no, maybe virtio core is a logical place to keep this.> > If they continue to lack that, we'll need a custom API in virtio, > > and while this seems a bit less elegant, I would not see that as > > the end of the world at all, there are not that many virtio drivers. > > No. If they continue to lack that, we fix them. This is a *platform* > issue. The DMA API shall do the right thing. Do not second-guess it. > > > (From the other mail)I don't have a problem with extending DMA API to address more usecases.> > > > OK so I guess that means we should prefer a transport-specific > > > > interface in virtio-pci then. > > > > > > Why? > > > > Because you said you are doing something device tree specific for > > ARM, aren't you? > > Nonono. The ARM platform code might do that, and the DMA API on ARM > *might* give you I/O virtual addresses that look a lot like the > physical addresses you asked it to map. That's none of your business. > Drivers use DMA API. No more talky.Well for virtio they don't ATM. And 1:1 mapping makes perfect sense for the wast majority of users, so I can't switch them over until the DMA API actually addresses all existing usecases.> -- > dwmw2 > >
On Wed, 2015-10-28 at 16:22 +0200, Michael S. Tsirkin wrote:> On Wed, Oct 28, 2015 at 11:13:29PM +0900, David Woodhouse wrote: > > On Wed, 2015-10-28 at 16:05 +0200, Michael S. Tsirkin wrote: > > > > > > Short answer - platforms need a way to discover, and express > > > different > > > security requirements of different devices. > > > > Sure. PLATFORMS need that. Do not let it go anywhere near your > > device > > drivers. Including the virtio drivers. > > But would there be any users of this outside the virtio subsystem? > If no, maybe virtio core is a logical place to keep this.Users of what? DMA API ops which basically do nothing? Sure ? there are *plenty* of cases where there isn't actually an IOMMU in active use and the DMA API just returns the same address it was given. Obviously that happens in platforms without an IOMMU, but it also happens in cases where an IOMMU exists but is in passthrough mode, and it also happens in cases where an IOMMU exists somewhere in the system but only translates for *other* devices. In all cases, drivers must just use the DMA API and *it* is responsible for doing the right thing.> I don't have a problem with extending DMA API to address > more usecases.No, this isn't an extension. This is fixing a bug, on certain platforms where the DMA API has currently done the wrong thing. We have historically worked around that bug by introducing *another* bug, which is not to *use* the DMA API in the virtio driver. Sure, we can co-ordinate those two bug-fixes. But let's not talk about them as anything other than bug-fixes.> > Drivers use DMA API. No more talky. > > Well for virtio they don't ATM. And 1:1 mapping makes perfect sense > for the wast majority of users, so I can't switch them over > until the DMA API actually addresses all existing usecases.That's still not your business; it's the platform's. And there are hardware implementations of the virtio protocols on real PCI cards. And we have the option of doing IOMMU translation for the virtio devices even in a virtual machine. Just don't get involved. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20151028/576ab6c7/attachment-0001.bin>
On Wed, Oct 28, 2015 at 11:32:34PM +0900, David Woodhouse wrote:> > I don't have a problem with extending DMA API to address > > more usecases. > > No, this isn't an extension. This is fixing a bug, on certain platforms > where the DMA API has currently done the wrong thing. > > We have historically worked around that bug by introducing *another* > bug, which is not to *use* the DMA API in the virtio driver. > > Sure, we can co-ordinate those two bug-fixes. But let's not talk about > them as anything other than bug-fixes.It was pretty practical not to use it. All virtio devices at the time without exception bypassed the IOMMU, so it was a question of omitting a couple of function calls in virtio versus hacking on DMA implementation on multiple platforms. We have more policy options now, so I agree it's time to revisit this. But for me, the most important thing is that we do coordinate.> > > Drivers use DMA API. No more talky. > > > > Well for virtio they don't ATM. And 1:1 mapping makes perfect sense > > for the wast majority of users, so I can't switch them over > > until the DMA API actually addresses all existing usecases. > > That's still not your business; it's the platform's. And there are > hardware implementations of the virtio protocols on real PCI cards. And > we have the option of doing IOMMU translation for the virtio devices > even in a virtual machine. Just don't get involved. > > -- > dwmw2 > >I'm involved anyway, it's possible not to put all the code in the virtio subsystem in guest though. But I suspect we'll need to find a way for non-linux drivers within guest to work correctly too, and they might have trouble poking at things at the system level. So possibly virtio subsystem will have to tell platform "this device wants to bypass IOMMU" and then DMA API does the right thing. I'll look into this after my vacation ~1.5 weeks from now. -- MST