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. 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
