[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.