On 25.11.2011, at 07:52, Liu Yu-B13201 <B13201@xxxxxxxxxxxxx> wrote: > > >> -----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? Because we would have to make sure that the secondaries use no magic-page accesses before doing their hypercall. That means we have to do the hypercall really early in secondary booutup code - which is subarch specific :) Alex -- 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
