On Thu, Feb 02, 2017 at 01:34:03PM +0000, Robin Murphy wrote:

On 02/02/17 11:26, Will Deacon wrote:

quoted

On Wed, Feb 01, 2017 at 09:19:22PM +0200, Michael S. Tsirkin wrote:

quoted

On Wed, Feb 01, 2017 at 06:27:09PM +0000, Will Deacon wrote:

quoted

On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote:

quoted

I'd like to do that instead. It's fastboot doing the unreasonable thing
here and deviating from what every other legacy device without exception
did for years. If this means fastboot will need to update to virtio 1,
all the better.

The problem still exists with virtio 1, unless we require that the
"dma-coherent" property is set/unset correctly when VIRTIO_F_IOMMU_PLATFORM
is advertised by the device (which is what I suggested in my reply).

I'm not ignoring that, but I need to understand that part a bit better.
I'll reply to that patch in a day or two after looking at how _CCA is
supposed to work.

Thanks. I do think that whatever solution we come up with for virtio 1
should influence what we do for legacy.

quoted

quoted

We can't detect the fastmodel,

Surely, it puts a hardware id somewhere? I think you mean
fastmodel isn't always affected, right?

I don't think there's a hardware ID. The thing is, the fastmodel is a
toolkit for building all sorts of platforms: you can chop and change
the CPUs, the peripherals, the memory, the interrupt controller, the
interconnect etc. Pretty much everything can be customised. So, for
any fastmodel configuration that places virtio upstream of the SMMU
(which is common, because virtio is one of the few DMA-capable peripherals
that the fastmodel supports), we need to do something special.

quoted

I'd like to see basically

if (fastmodel)
	a pile of special work-arounds
else
	not less hacky but more common virtio work-arounds

:)

And then I can apply whatever comes from @arm.com and not
worry about breaking actual hardware.

What we could do is call iommu_group_get(&vdev->dev) for legacy

Actually, that should be vdev->dev.parent - I'm now not sure quite what
I managed to successfully test yesterday, but apparently it wasn't this
patch :(

quoted

devices if CONFIG_ARM64. If that returns non-NULL, then we know that
the device is upstream of an SMMU, which means it must be the fastmodel.

We can boot 32-bit kernels on models, so I'd be inclined to keep
CONFIG_ARM included, but I do tend to agree that explicitly checking for
an IOMMU is probably the cleanest approach if we reposition this as a
more specific quirk. I'll split apart the "Fast Models are wacky" vs.
"uh-oh device coherency" aspects and spin a v2 so that we can
(hopefully) sort the regression out ASAP.

Robin.

I am inclined to say, for 4.10 let's revert
c7070619f3408d9a0dffbed9149e6f00479cf43b since what it fixes is not a
regression in 4.10.  So I think we can defer the fix to 4.11.
I think we still want f7f6634d23830ff74335734fbdb28ea109c1f349
for hosts with virtio 1 support.

All this will hopefully push hosts to just implement virtio 1.
For mmio the changes are very small: several new registers,
that's all. You want this for proper 64 bit dma mask anyway.

quoted

Will