On 03/04/2017 09:27, David Hildenbrand wrote: >>> I don't see any reason any more for this lock, seemed to be used to protect >>> removal of kvm->arch.vpic / kvm->arch.vioapic when already partially >>> inititalized, now access is properly protected using kvm->arch.irqchip_mode >>> and this shouldn't be necessary anymore. >> Do more readers of irqchip_mode need memory barriers now? Definitely we need an smp_wmb() after setting INIT_IN_PROGRESS. >> > My assumption was that if vpic/vioapic checks worked until now without > memory barriers, the same should be true when checking against > irqchip_mode. All that was missing previously was smp_read_barrier_depends(). While a compiler _can_ do things that are prohibited by smp_read_barrier_depends(), it's much harder to trigger than for smp_rmb(). For smp_rmb(), the scheduler's whims may cause it to break the intended semantics. Paolo > But as we are dropping some implicit barriers and > irqchip_mode is updated more frequently, you may be right. > > Also, using rmb/wmb in a uniform fashion with irqchip_mode looks > cleaner, as we are removing all implicit "cannot happen because of XXX" > special cases.
