On Mon, Jan 14, 2019 at 09:19:35PM +0100, Christoph Hellwig wrote: > > Christoph is saying that !IOMMU_PLATFORM devices should hide the > > compatibility code in a special per-device DMA API implementation. > > Which would be fine especially if we can manage not to introduce a bunch > > of indirect calls all over the place and hurt performance. It's just > > that the benefit is unlikely to be big (e.g. we can't also get rid of > > the virtio specific memory barriers) so no one was motivated enough to > > work on it. > > No. Oh ok then. > The problem is that we still haven't fully specified what > IOMMU_PLATFORM and !IOMMU_PLATFORM actually mean. Your > "ACCESS_PLATFORM/ORDER_PLATFORM" commit in the virtio-spec repo > improves it a little bit, but it is still far from enough. > > As a start VIRTIO_F_ORDER_PLATFORM and VIRTIO_F_ACCESS_PLATFORM > absolutely MUST be set for hardware implementations. Otherwise said > hardware has no chance of working on anything but the most x86-like > systems. I think you are exaggerating a little here. Limited access with e.g. need to flush caches is common on lower end but less common on higher end systems used for virtualization. As you point out that changes with e.g. SEV but then SEV is a pretty niche thing so far. So I would make that a SHOULD probably. > Second software implementations SHOULD set VIRTIO_F_ACCESS_PLATFORM, > because otherwise we can't add proper handling for things like SEV or > the IBM "secure hypervisor" thing. Yes. If host does not have access to all of memory it SHOULD set VIRTIO_F_ACCESS_PLATFORM. It seems rather straight-forward to add conformance clauses for this, thanks for reminding me. > Last but not least a lot of wording outside the area describing these > flags really needs some major updates in terms of DMA access. Thanks for the reminder. Yes generally spec tends to still say e.g. "physical address" where it really means a "DMA address" in Linux terms. Whether changing that will make things much clearer I'm not sure. E.g. hardware designers don't much care I guess. If you want to list the most problematic cases, e.g. in a github issue, we might get to clarifying them sooner. Thanks! -- MST
