Message-ID: <1461858505.33870.108.camel@infradead.org>
Date:	Thu, 28 Apr 2016 16:48:25 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Joerg Roedel <joro@...tes.org>, Kevin Wolf <kwolf@...hat.com>,
	Wei Liu <wei.liu2@...rix.com>,
	Andy Lutomirski <luto@...nel.org>, qemu-block@...gnu.org,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Jason Wang <jasowang@...hat.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	qemu-devel@...gnu.org, peterx@...hat.com,
	linux-kernel@...r.kernel.org, Amit Shah <amit.shah@...hat.com>,
	iommu@...ts.linux-foundation.org,
	Stefan Hajnoczi <stefanha@...hat.com>, kvm@...r.kernel.org,
	cornelia.huck@...ibm.com, pbonzini@...hat.com,
	virtualization@...ts.linux-foundation.org,
	Anthony PERARD <anthony.perard@...rix.com>
Subject: Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

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


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5760 bytes)

Powered by blists - more mailing lists