On 16 Jul 2012, at 15:39, Avi Kivity <avi at redhat.com> wrote: > On 07/16/2012 05:12 PM, Christoffer Dall wrote: >>> >>> And you said the reason of disabling preemption as CPU-specific data such as caches. >>> But as far as I know, the l1 caches are coherent. >>> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438e/BABFHDFE.html) >>> >>> Can you please explain why preemption disable is necessary in detail? >>> >> >> 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. > Seems to me that whatever operation you do has to survive vcpu > migration. So there should be some big hammer after vcpu migration to > cause everything to be synchronized. Given that, you can do everything > with preemption enabled, and trust the migration handler to fix things > up if you were preempted. > > (of course the operation itself may need to be locally unpreemptible if > you touch multiple registers, but that still allows you to run most > handlers with preemption enabled, like most archs do). It may be that we need two classes of handlers then. M.
