Re: [Xen-devel] xen/arm: On chip memory mappings

[Julien Grall <julien.grall@xxxxxxxxxx>]

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

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