From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Tue, 22 Nov 2011 22:02:53 +0000
Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu
Message-Id: <4ECC1C0D.6070302@freescale.com>
List-Id: <kvm-ppc.vger.kernel.org>
References: <1321955703-1628-1-git-send-email-yu.liu@freescale.com>
In-Reply-To: <1321955703-1628-1-git-send-email-yu.liu@freescale.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: kvm-ppc@vger.kernel.org

On 11/22/2011 03:45 PM, Yoder Stuart-B08248 wrote:
> Hmm...not sure which approach makes sense.
> 
> So to make sure I understand Scott's proposal the sequence would
> be something like:
> 
>    -after secondaries CPUs are released from spin and can
>     determine they are running under KVM they:
>       -disable interrupts
>       -set a flag indicating they are waiting for paravirt
>        patching to complete
>       -spin in a loop until a flag is set that indicates
>        paravirt patch is complete
>       -make the paravirt hcall
> 
>   -boot CPU
>       -waits for all secondaries to set the 'waiting for 
>        paravirt' flag
>       -makes the paravirt hcall
>       -patches the kernel
>       -sets 'paravirt complete' flag
> 
> Is that basically correct?

That's not my proposal.

My proposal is just to add something like this at the end of
kvm_map_magic_page():

if (not the cpu doing the patching) {
	while (!kvm_patching_done)
		cpu_relax();
}

And even that is only really worth it if there are races besides SPRG3-7
to worry about.  Using the privileged version of SPRG3-7 inside the
kernel would avoid needing anything special for KVM, and would make SPRG
access slightly simpler than they are now (no separate W/R versions to
keep track of) -- I'm not sure why the kernel bothers with the user-read
version of the SPRs in the first place.

-Scott