Re: xen/arm: On chip memory mappings

[Julien Grall <julien.grall@citrix.com>]

On 19/05/2015 10:09, Ian Campbell wrote:
> On Tue, 2015-05-19 at 15:16 +1000, Edgar E. Iglesias wrote:
>> Hi,

Hi,

>> The rules for combining the memory attributes from S1 and S2 translations
>> suggest that mapping things at S2 with Normal memory Inner/Outer WB cacheable
>> would give the guest/S1 flexibility in choosing the final attributes.
>> It seems to me like guest drivers have the best knowledge to decide how to
>> map the node memory regions.
>>
>> Keeping the S2 shareability set to inner (like we already do for memory)
>> seems to be a good idea though.
>>
>> So the question I had is, why do we map nodes at S2 with DEVICE attributes at all?
>> Am I missing something?
>
> I think the concern was exposing potentially UNPREDICTABLE /
> IMPLEMENTATION DEFINED etc behaviour via a guest which maps MMIO regions
> as normal memory in S1. By using a device memory mapping in S2 we force
> a safe overall result.
>
> I've not refreshed my memory on the way round this goes though, perhaps
> the worry is/was unfounded. In particular perhaps on v8 this ends up as
> CONSTRAINED UNPREDICTABLE which might be safe enough (again, I've not
> checked).
>
> I'd rather not have v7 and v8 differ in such a fundamental default, but
> it might be justified I suppose. Likewise for e.g. doing something
> different for dom0/hw-dom vs. others.

I remember a similar discussion with Christoffer few months ago (it was 
for ACPI). And the answer was:

"No, real access to MMIO regions of devices must be mapped as device
type in stage-2 if you don't want potential information leaks or weird
things to happen where a guest can tweak and time memory operations
such that they happen in a different context than the VM executing the
memory access.

You can argue that the latter is not necessary for Dom0 as Xen trusts
Dom0 completely, but I would still argue that it is the right approach
to take proper care of it, thus;"

Regards,

-- 
Julien Grall