Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 12/07/2017 04:04 PM, Julien Grall wrote:
> Hi Jan,
> 
> On 07/12/17 15:45, Jan Beulich wrote:
>>>>> On 07.12.17 at 15:53, <marc.zyngier@xxxxxxx> wrote:
>>> On 07/12/17 13:52, Julien Grall wrote:
>>> There is exactly one case where set/way makes sense, and that's when
>>> you're the only CPU left in the system, your MMU is off, and you're
>>> about to go down.
>>
>> With this and ...
>>
>>> On top of bypassing the coherency, S/W CMOs do not prevent lines from
>>> migrating from one CPU to another. So you could happily be flushing by
>>> S/W, and still end up with dirty lines in your cache. Success!
>>
>> ... this I wonder what value emulating those insns then has in the first
>> place. Can't you as well simply skip and ignore them, with the same
>> (bad) result?
> 
> The result will be much much worst. Here a concrete example with a Linux
> Arm 32-bit:
> 
>     1) Cache enabled
>     2) Decompress
>     3) Nuke cache (S/W)
>     4) Cache off
>     5) Access new kernel
> 
> If you skip #3, the decompress data may not have reached the memory, so
> you would access stall data.
> 
> This would effectively mean we don't support Linux Arm 32-bit.

So Marc said that #3 "doesn't make sense", since although it might be
the only cpu on in the system, you're not "about to go down"; but Linux
32-bit is doing that anyway.

It sounds like from the slides the purpose of #3 might be to get stuff
out of the D-cache into the I-cache.  But why is the cache turned off?
And why doesn't Linux use the VA-based flushes rather than the S/W flushes?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel