Re: [Xen-devel] [RFC 12/19] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 07/03/2014 03:04 PM, Ian Campbell wrote:
> On Thu, 2014-07-03 at 14:51 +0100, Julien Grall wrote:
>> On 07/03/2014 02:42 PM, Ian Campbell wrote:
>>> On Thu, 2014-07-03 at 14:01 +0100, Julien Grall wrote:
>>>> On 07/03/2014 01:53 PM, Ian Campbell wrote:
>>>>> On Thu, 2014-07-03 at 13:07 +0100, Julien Grall wrote:
>>>>>>>> If Xen reassigns the device to "nobody", it may receive some 
>>>>>>>> global/context
>>>>>>>> fault because the transaction has failed (indeed the context has been
>>>>>>>> marked invalid).
>>>>>>>
>>>>>>> Can you describe here what happen in this case (I presume Xen tears down
>>>>>>> the iommu to quiesce them somehow?)
>>>>>>
>>>>>> The SMMU drivers will mark the different Context Bank, S2CR, SMR as
>>>>>> invalid. If the device is attempt to access the memory then, we will
>>>>>> receive an interrupt in Xen.
>>>>>>
>>>>>> Actually it's only happen once, if the device is still enabled when the
>>>>>> domain is shutdown.
>>>>>
>>>>> My concern was with getting a storm of such interrupts after this point.
>>>>> If it only happens once and any subsequent ones are damped by some means
>>>>> then great.
>>>>
>>>> I guess, it can happen with a buggy device trying to access memory
>>>> alone. But I don't think we should care about this case.
>>>
>>> Ideally such a device wouldn't be able to DoS the rest of the system.
>>>
>>> Does the SMMU not have a bit to say: deny all MMIO from this context
>>> without raising an exception?
>>
>> AFAIK, no. We receive a transaction fault via the global interrupt. If
>> we disable this interrupt we also disable potentially helpful message
>> when the register are misconfigured.
> 
> That seems like something of a hardware shortcoming.
> 
> It might be worth asking one of the ARM guys what we should do with a
> device which won't shut up.

I will send an email to Marc & Will.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel