Re: [Xen-devel] [PATCH v5 20/22] xen/arm: ITS: Map ITS translation space

[Marc Zyngier <marc.zyngier@xxxxxxx>]

On 02/09/15 16:45, Ian Campbell wrote:
> On Tue, 2015-08-18 at 23:37 +0100, Marc Zyngier wrote:
>> On Tue, 18 Aug 2015 20:14:43 +0100 Julien Grall <julien.grall@xxxxxxxxxx> 
>> wrote:
>>
>>> Marc pointed me today that if the processor is writing into 
>>> GITS_TRANSLATER it may be able to deadlock the system.
>>>
>>> Reading more closely the spec (8.1.3 IHI0069A), there is undefined 
>>> behavior when writing to this register with wrong access size.
>>>
>>> Currently the page table are shared between the processor and the SMMU, 
>>>
>>> so that means that a domain will be able to deadlock the processor and 
>>> therefore the whole platform.
>>
>> Indeed. A CPU should *never* be able to write to the GITS_TRANSLATER
>> register. What would be the meaning anyway? How would a DeviceID be
>> sampled? This is definitely UNPREDICTIBLE territory, and you want to
>> make sure a guest cannot directly write to the HW.
>>
>>> So we should never expose GITS_TRANSLATER into the processor page 
>>> table. 
>>> Which means unsharing some parts if not all of the page tables between 
>>> the processor and the SMMU.
>>
>> Agreed. It looks to me like the CPU should only see the the virtual
>> ITS, and nothing else.
> 
> It's rather unfortunate that using an ITS therefore precludes sharing stage
> -2 page tables between MMU and SMMU, which it seems otherwise the
> architecture designers have tried hard to allow.
> 
> Do you know if this will be fixed in some future revision (although given
> we now need to have the functionality anyway I'm not sure it help more than
>  saving a few pages of memory :-()

I don't have any idea if something is being worked on to address this,
but I think you may be able to share at least the page tables describing
the memory, which should really be the bulk of the page tables.

        M.
-- 
Jazz is not dead. It just smells funny...

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