From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: xen/arm: On chip memory mappings Date: Tue, 19 May 2015 10:23:05 +0100 Message-ID: <555B00F9.4020601@citrix.com> References: <20150519051600.GD10142@toto> <1432026548.12989.28.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1432026548.12989.28.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , "Edgar E. Iglesias" Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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