On 17 Jul 2012, at 09:37, Avi Kivity <avi at redhat.com> wrote: > On 07/16/2012 10:46 PM, Marc Zyngier wrote: >> 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. > > 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. > >> >>> 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. > > Maybe. x86 also special cases NMI since it needs to run on the same cpu. Right. Given how we handle the CP15 exceptions, we may have to work out something clever... Thanks, M.
