Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu

[Scott Wood <scottwood@freescale.com>]

On 11/22/2011 05:27 AM, Alexander Graf wrote:
> 
> 
> 
> 
> On 22.11.2011, at 12:19, Liu Yu-B13201 <B13201@freescale.com> wrote:
> 
>>
>>
>>> -----Original Message-----
>>> From: Alexander Graf [mailto:agraf@suse.de] 
>>> Sent: Tuesday, November 22, 2011 7:14 PM
>>> To: Liu Yu-B13201
>>> Cc: <kvm-ppc@vger.kernel.org>; Liu Yu-B13201
>>> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu
>>>
>>>
>>> On 22.11.2011, at 10:55, Liu Yu <yu.liu@freescale.com> 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.

Or just always use the supervisor version of SPRG4-7 for kernel access,
whether reading or writing -- this should always trap in PR-mode.

-Scott