[PATCH v4 00/12] arm/arm64: KVM: host cache maintenance when guest caches are off

Marc Zyngier marc.zyngier at arm.com
Wed Feb 19 05:43:57 EST 2014

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 <marc.zyngier at arm.com> 
>>> 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.

Jazz is not dead. It just smells funny...

More information about the linux-arm-kernel mailing list