On Thu, 15 Mar 2018, Peter Zijlstra wrote: > On Thu, Mar 15, 2018 at 12:45:03PM +0100, Thomas Gleixner wrote: > > On Thu, 15 Mar 2018, Vitaly Kuznetsov wrote: > > > The only user of these pages is currently KVM. Can we still have vCPUs > > > running on the outgoing CPU at this point? If case we can we're in > > > trouble and we need to somehow kick them out first. > > > > The first thing we do in unplug is to mark the CPU inactive, but I'm not > > sure whether that prevents something which was on the CPU before and > > perhaps preempted or is affine to that CPU to be scheduled in > > again. Peter???? > > I think we can still have tasks running at this point. > > AP_ACTIVE (sched_cpu_deactivate) simply takes the CPU out of the active > mask, which guarantees no new tasks will land on the CPU. > > We'll then proceed all the way to TEARDOWN_CPU as 'normal', at which > point we'll call stop_machine() which does the old DYING callbacks. > > It sounds like we want this done here, although possibly we can't do > vfree() from that context, in which case it needs to store the pointer > and do that from a BP callback (what used to be the OFFLINE callbacks or > something). So the wrmsr() wants to be in the dying range. The vfree() is questionable anyway because the re-onlining of that CPU will just allocate it again. So it could very well stay around. Thanks, tglx
