From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH v4 00/12] arm/arm64: KVM: host cache maintenance when guest caches are off Date: Wed, 19 Feb 2014 10:43:57 +0000 Message-ID: <53048AED.1070308@arm.com> References: <1392737253-10480-1-git-send-email-marc.zyngier@arm.com> <56ae8a2975cd21765b90d98260862af1@www.loen.fr> <20140219101246.GD30457@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Eric Northup , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" , KVM To: Catalin Marinas Return-path: Received: from fw-tnat.austin.arm.com ([217.140.110.23]:57853 "EHLO collaborate-mta1.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751144AbaBSKoA (ORCPT ); Wed, 19 Feb 2014 05:44:00 -0500 In-Reply-To: <20140219101246.GD30457@arm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 19/02/14 10:12, Catalin Marinas wrote: > On Wed, Feb 19, 2014 at 09:02:34AM +0000, Marc Zyngier wrote: >> On 2014-02-18 20:57, Eric Northup wrote: >>> On Tue, Feb 18, 2014 at 7:27 AM, Marc Zyngier >>> wrote: >>>> >>>> When we run a guest with cache disabled, we don't flush the cache to >>>> the Point of Coherency, hence possibly missing bits of data that >>>> have >>>> been written in the cache, but have not yet reached memory. >>>> >>>> We also have the opposite issue: when a guest enables its cache, >>>> whatever sits in the cache is suddenly going to become visible, >>>> shadowing whatever the guest has written into RAM. >>>> >>>> There are several approaches to these issues: >>>> - Using the DC bit when caches are off: this breaks guests assuming >>>> caches off while doing DMA operations. Bootloaders, for example. >>>> It also breaks the I-D coherency. >>>> - Fetch the memory attributes on translation fault, and flush the >>>> cache while handling the fault. This relies on using the PAR_EL1 >>>> register to obtain the Stage-1 memory attributes, and tends to be >>>> slow. >>>> - Detecting the translation faults occuring with MMU off (and >>>> performing a cache clean), and trapping SCTLR_EL1 to detect the >>>> moment when the guest is turning its caches on (and performing a >>>> cache invalidation). Trapping of SCTLR_EL1 is then disabled to >>>> ensure the best performance. >>> >>> This will preclude noticing the 2nd .. Nth cache off -> on cycles, >>> right? Will any guests care - doesn't kexec go through a caches-off >>> state? >> >> kexec, bootloaders, and whatever firmware requires to switch caches on >> and then off. Guest does care, but we don't have an (efficient) >> architectural solution to that. >> >> The best I can think of so far is a "switch-the-damned-thing-off" >> hypercall that would do the above before returning to the guest. > > We could push for a PSCI extension to cover such cases as well, though > even for a host, we may not need to involve the secure world for kexec. > > An alternative is to trap the set/way cache flushing and re-activate the > MMU trapping in the guest. If the MMU is still on, disable trapping > until the next set/way (since that's a normal function on power-down > code sequences). But it doesn't look nice ;). No, it doesn't... I may have a go at it though, and see what breaks. We already have all the code ready, just need to throw some glue at it. M. -- Jazz is not dead. It just smells funny...