[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.
M.
--
Jazz is not dead. It just smells funny...
More information about the linux-arm-kernel
mailing list