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? -- error compiling committee.c: too many arguments to function _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
