On Thu, 2016-04-28 at 18:37 +0300, Michael S. Tsirkin wrote: > OK, so for intel, it seems that it's enough to set > pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO; > for the device. Yes, currently. Although that's vile. In fact what we *want* to happen is for the intel-iommu code simply to decline to provide DMA ops for this device, and let it fall back to the swiotlb or no-op DMA ops, as appropriate. As it is, we have the intel-iommu DMA ops *unconditionally, and they have a hack to manually fall back to calling swiotlb. It's all just horrid, which is why I want to clean it up with nice per-device DMA ops and discovery thereof :) > Do I have to poke at each iommu implementation to find > a way to do this, or is there some way to do it > portably? There *will* be.... Christoph has already done some of the cleanup in this space, and I need to take stock of what he's already done, and finish off the parts I want to build on top of it. > Not exactly - I think that future versions of qemu might lie > about some devices but not others. Can we keep this simple? QEMU currently lies about some devices. Let's implement a heuristic for the guest OS to know about that, and react accordingly. Then let's fix QEMU to tell the truth. All the time, unconditionally. Even on POWER/ARM where there's no obvious *way* for it to tell the truth (because you don't have the flexibility that DMAR tables do), and we need to devise a way to put it in the device-tree or fwcfg or something else. And only once QEMU consistently tells the *truth*, then we can start to do new stuff and let it actually change its behaviour. > DMAR is unfortunately not a good match for what people do with QEMU. > > There is a patchset on list fixing translation of assigned > devices. So the fix for these will simply be to do translation for > all assigned devices. It's harder for virtio as it isn't always > processed in QEMU - there's vhost in kernel and an out of process > vhost-user plugin. So we can end up e.g. with modern QEMU which > does translate in-process virtio but not out of process one. Right... just stop. Fix QEMU to tell the truth first, and *then* once we can trust it, we can start to change its behaviour. :) > Unfortunately people got used to be able to put any device > in any slot, and built external tools around that ability. > It's rather painful to break this assumption. Well, if you just said you have a patch set which allows translation of assigned devices then you are most of the way there, aren't you? We just need to fix the out-of-process virtio case, and everything can be either translated or untranslated? -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
