Messages in this thread | | | Subject | Re: [PATCH v3 0/3] virtio DMA API core stuff | From | David Woodhouse <> | Date | Thu, 19 Nov 2015 23:38:06 +0000 |
| |
On Thu, 2015-11-19 at 13:59 -0800, Andy Lutomirski wrote: > > > > > So thinking hard about it, I don't see any real drawbacks to making this > > conditional on a new feature bit, that Xen can then set.. > > Can you elaborate? If I run QEMU, hosting Xen, hosting Linux, and the > virtio device is provided by QEMU, then how does Xen set the bit? > Similarly, how would Xen set the bit for a real physical device?
Right. This is *not* a fundamental characteristic of the device. This is all about how your *particular* hypervisor (in the set of turtles- all-the-way-down) happened to expose the thing to you.
This is why it lives in the DMAR table, in the Intel world, which *tells* you which devices are behind which IOMMU (and which are not). And why I keep repeating myself that it has nothing to do with the actual device or the virtio drivers.
I understand that POWER and other platforms don't currently have a clean way to indicate that certain device don't have translation. And I understand that we may end up with a *quirk* which ensures that the DMA API does the right thing (i.e. nothing) in certain cases.
But we should *NOT* be involving the virtio device drivers in that quirk, in any way. And putting a feature bit in the virtio device itself doesn't seem at all sane either.
Bear in mind that qemu-system-x86_64 currently has the *same* problem with assigned physical devices. It's claiming they're translated, and they're not.
-- dwmw2
[unhandled content-type:application/x-pkcs7-signature] | |