On Tue, 07 Aug 2012 17:05:39 +0300, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 07/17/2012 12:06 PM, Marc Zyngier wrote:
>>>>>>
>>>>>> if a VM tries to do a cache maintenance operation specific to that
>>>>>> CPU
>>>>>> that traps we want to make sure that the emulation of such
operations
>>>>>> happen on the same physical CPU to ensure correct semantics.
>>>>>
>>>>> Can you give an example of those cache maintenance operations?
>>>>
>>>> When the guest does cache maintenance by set/way, these operations
>>>> must occur on the local CPU, and only there.. To ensure they get
>>>> propagated, we trap these, execute the operation on the current CPU
and
>>>> put a flag to nuke the caches on the other CPUs next time they run
this
>>>> vcpu.
>>>
>>> Yes, but what are those cache maintenance operations? Invalidates? I
>>> come from the x86 world where the only maintenance you do is enable
the
>>> cache and flush it if you change the physical memory map.
>>
>> Both clean and invalidate. Most operations are coherent across CPUs,
>> except when using the cache geometry. In this case, they are local to
>> the CPU. Fortunately, this is a rare event (for Linux, when booting or
>> resuming from suspend). All other cache ops are broacasted in HW.
>>
>
> vcpu migration is supposed to be transparent. What happens if you
> perform the operation locally, then the vcpu is migrated?
Migrated as in "moved to another physical CPU"? We have a per-vcpu cpumask
indicating which CPU must perform a full cache clean/invalidate, which we
test in kvm_arch_vcpu_load().
M.
--
Fast, cheap, reliable. Pick two.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
