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 > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
