[PATCH] virtio: Try to untangle DMA coherency

[Robin Murphy]

On 02/02/17 11:26, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 09:19:22PM +0200, Michael S. Tsirkin wrote:
>> On Wed, Feb 01, 2017 at 06:27:09PM +0000, Will Deacon wrote:
>>> On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote:
>>>> 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.
> 
>>> 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.
> 
>> 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 :(

> 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.

> 
> Will
>