From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH RFC] xen: arm: use uncached foreign mappings when building guests Date: Thu, 2 Jan 2014 15:10:20 +0000 Message-ID: <52C5815C.5020908@citrix.com> References: <1387387710.28680.88.camel@kazak.uk.xensource.com> <52B1EC43.7030408@cantab.net> <1387447808.9925.24.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1387447808.9925.24.camel@kazak.uk.xensource.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 Cc: Julien Grall , Ian Jackson , Tim Deegan , xen-devel , David Vrabel , Stefano.Stabellini@citrix.com, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 19/12/13 10:10, Ian Campbell wrote: > On Wed, 2013-12-18 at 18:41 +0000, David Vrabel wrote: >> On 18/12/2013 17:28, Ian Campbell wrote: >>> When building an ARM guest we need to take care of cache maintenance >>> because the guest starts with MMU and cache disabled, which means we >>> need to make sure that the initial images (kernel, initrd, dtb) which we >>> write to guest memory are not in the cache. >>> >>> We thought we had solved this with "tools: libxc: flush data cache after >>> loading images into guest memory" (a0035ecc0d82) however it turns out >>> that there are a couple of issues with this approach: >>> >>> Firstly we need to do a cache flush from userspace, on arm64 this is >>> possible by directly using the instructions from userspace, but on arm32 >>> this is not possible and so we need to use a system call. Unfortunately >>> the system call provided by Linux for this purpose does not flush far >>> enough down the cache hierarchy. Extending the system call would not be >>> an insurmountable barrier, were it not for the second issue: >>> >>> Secondly, and more importantly, Catalin Marinas points out (via Marc >>> Zyngier) that there is a race between the cache flush and the point >>> where we tear down the mappings, where the processor might speculatively >>> pull some data into the cache (cache flushes are by Virtual Address, so >>> this race is unavoidable). >>> >>> If this happens then guest kernels which modify some code/data before >>> enabling MMUs + caches may see stale data in the cache. >> >> Would this same problem with occur with save/restore of a guest that has >> caching disabled? > > We basically only support guests running without caches at start of day. > We expect and require them to come up and enable caches and then keep > them enabled. Fortunately this is normal practice... There is still a (small) window where a guest is running with caches disabled and it may be saved/migrated at this point. Is this a concern? David