> -----Original Message----- > From: Alexander Graf [mailto:agraf@xxxxxxx] > Sent: Wednesday, November 23, 2011 5:28 AM > To: Yoder Stuart-B08248 > Cc: Wood Scott-B07421; Liu Yu-B13201; <kvm-ppc@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu > > > On 22.11.2011, at 22:11, Yoder Stuart-B08248 wrote: > > > > > > >> -----Original Message----- > >> From: kvm-ppc-owner@xxxxxxxxxxxxxxx > [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On Behalf Of > >> Alexander Graf > >> Sent: Tuesday, November 22, 2011 2:45 PM > >> To: Wood Scott-B07421 > >> Cc: Liu Yu-B13201; <kvm-ppc@xxxxxxxxxxxxxxx> > >> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu > >> > >> > >> On 22.11.2011, at 19:36, Scott Wood > <scottwood@xxxxxxxxxxxxx> wrote: > >> > >>> On 11/22/2011 05:27 AM, Alexander Graf wrote: > >>>> > >>>> > >>>> > >>>> > >>>> On 22.11.2011, at 12:19, Liu Yu-B13201 > <B13201@xxxxxxxxxxxxx> wrote: > >>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Alexander Graf [mailto:agraf@xxxxxxx] > >>>>>> Sent: Tuesday, November 22, 2011 7:14 PM > >>>>>> To: Liu Yu-B13201 > >>>>>> Cc: <kvm-ppc@xxxxxxxxxxxxxxx>; Liu Yu-B13201 > >>>>>> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu > >>>>>> > >>>>>> > >>>>>> On 22.11.2011, at 10:55, Liu Yu <yu.liu@xxxxxxxxxxxxx> wrote: > >>>>>> > >>>>>>> Previously, only primary vcpu get enabled paravirt. > >>>>>> > >>>>>> Please fix it the other way around. Thd hypercall is > CPU local and > >>>>>> should stay that way, so we have to call it on each > vcpu inside the > >>>>>> guest. > >>>>>> > >>>>> > >>>>> The guest kernel already use on_each_cpu() But seems it doesn't > >>>>> work. > >>>>> The place primary cpu do hypercall is still in early_init where > >>>>> secondary cpus don't get kicked. > >>>> > >>>> Ouch. Then let's go with this approach and > >>>> > >>>> a) update the hypercall documentation > >>>> b) change the guest code to not loop through all cpus > >>>> c) flush the tlb cache on all vcpus from the hc handler > >>> > >>> It's currently only our internal tree that does it from > early_init (as > >>> part of the idle paravirt patch, to avoid races -- though I can't > >>> recall now what the problematic race is there). It > should have been > >>> changed for the SPRG4-7 paravirt as well. We don't want > a secondary > >>> CPU to take an exception and save something into a > paravirt SPRG, but > >>> read from the hardware SPRG, due to the patching being incomplete. > >>> > >>> An alternative would be to still do it after secondaries > are up, but > >>> instead of just doing the hcall in kvm_map_magic_page, > all but one cpu > >>> would be held in a loop with interrupts off until the > patching is complete. > >> > >> That sounds good. Then they can all do the hcall > themselves and contine running. > > > > Why do the secondaries need to spin...can they just make the call > > as the very first thing when coming out of the spin table? > > > > Just let the boot CPU do the patching before releasing > > the secondaries. > > That is very subarch-specific, so we'd have to treat e500 > different from 440 different from book3s_32 different from > book3s_64 I suppose. > If you want to go through that exercise, it might be worth > it. The overall thing would be easier then at the end of the > day - except for the startup code for secondaries. > I'm still worried that the spin may affect host and other guests and give users a bad experience. Why the method like this patch would be very subarch-specific? Thanks, Yu -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
