Kernel KVM-PPC virtualization development
 help / color / mirror / Atom feed
From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
	mpe@ellerman.id.au, benh@kernel.crashing.org, agraf@suse.com
Subject: Re: [PATCH V2 2/2] powerpc/kvm: Update kvmppc_set_arch_compat() for ISA v3.00
Date: Tue, 01 Nov 2016 02:47:31 +0000	[thread overview]
Message-ID: <1477968451.2143.7.camel@gmail.com> (raw)
In-Reply-To: <20161031054436.6vv76jci5aebfpd6@oak.ozlabs.ibm.com>

On Mon, 2016-10-31 at 16:44 +1100, Paul Mackerras wrote:
> On Mon, Oct 31, 2016 at 11:28:23AM +1100, Suraj Jitindar Singh wrote:
> > 
> > The function kvmppc_set_arch_compat() is used to determine the
> > value of the
> > processor compatibility register (PCR) for a guest running in a
> > given
> > compatibility mode. There is currently no support for v3.00 of the
> > ISA.
> > 
> > Add support for v3.00 of the ISA which adds an ISA v2.07
> > compatilibity mode
> > to the PCR.
> > 
> > We also add a check to ensure the processor we are running on is
> > capable of
> > emulating the chosen processor (for example a POWER7 cannot emulate
> > a
> > POWER8, similarly with a POWER8 and a POWER9).
> > 
> > Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
> > ---
> >  arch/powerpc/kvm/book3s_hv.c | 32 +++++++++++++++++++++++---------
> >  1 file changed, 23 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/powerpc/kvm/book3s_hv.c
> > b/arch/powerpc/kvm/book3s_hv.c
> > index 3686471..24681e7 100644
> > --- a/arch/powerpc/kvm/book3s_hv.c
> > +++ b/arch/powerpc/kvm/book3s_hv.c
> > @@ -311,24 +311,38 @@ static int kvmppc_set_arch_compat(struct
> > kvm_vcpu *vcpu, u32 arch_compat)
> >  			 * If an arch bit is set in PCR, all the
> > defined
> >  			 * higher-order arch bits also have to be
> > set.
> >  			 */
> > -			pcr = PCR_ARCH_206 | PCR_ARCH_205;
> > +			if (cpu_has_feature(CPU_FTR_ARCH_206))
> > +				pcr |= PCR_ARCH_205;
> > +			if (cpu_has_feature(CPU_FTR_ARCH_207S))
> > +				pcr |= PCR_ARCH_206;
> > +			if (cpu_has_feature(CPU_FTR_ARCH_300))
> > +				pcr |= PCR_ARCH_207;
> >  			break;
> >  		case PVR_ARCH_206:
> >  		case PVR_ARCH_206p:
> > -			pcr = PCR_ARCH_206;
> > +			/* Must be at least v2.06 to (emulate) it
> > */
> > +			if (!cpu_has_feature(CPU_FTR_ARCH_206))
> > +				return -EINVAL;
> > +			if (cpu_has_feature(CPU_FTR_ARCH_207S))
> > +				pcr |= PCR_ARCH_206;
> > +			if (cpu_has_feature(CPU_FTR_ARCH_300))
> > +				pcr |= PCR_ARCH_207;
> >  			break;
> >  		case PVR_ARCH_207:
> > +			/* Must be at least v2.07 to (emulate) it
> > */
> > +			if (!cpu_has_feature(CPU_FTR_ARCH_207S))
> > +				return -EINVAL;
> > +			if (cpu_has_feature(CPU_FTR_ARCH_300))
> > +				pcr |= PCR_ARCH_207;
> > +			break;
> > +		case PVR_ARCH_300:
> > +			/* Must be at least v3.00 to (emulate) it
> > */
> > +			if (!cpu_has_feature(CPU_FTR_ARCH_300))
> > +				return -EINVAL;
> >  			break;
> I can't help thinking that the repetitive structure of the lines
> you're adding must imply a regularity that could be expressed more
> concisely.  If you defined a dummy PCR_ARCH_300 bit as 0x10, perhaps
> you could do something like this:
> 
> 	if (cpu_has_feature(CPU_FTR_ARCH_300))
> 		host_pcr_bit = PCR_ARCH_300;
> 	else if (cpu_has_feature(CPU_FTR_ARCH_207S))
> 		host_pcr_bit = PCR_ARCH_207;
> 	else
else if
> 		host_pcr_bit = PCR_ARCH_206;
else
	host_pcr_bit = PCR_ARCH_205;
> 
> 	switch (arch_compat) {
> 	case PVR_ARCH_205:
> 		guest_pcr_bit = PCR_ARCH_205;
> 		break;
> 	case PVR_ARCH_206:
> 		guest_pcr_bit = PCR_ARCH_206;
> 		break;
> 	case PVR_ARCH_207:
> 	case PVR_ARCH_207S:
> 		guest_pcr_bit = PCR_ARCH_207;
> 		break;
> 	case PVR_ARCH_300:
> 		guest_pcr_bit = PCR_ARCH_300;
> 		break;
> 	default:
> 		return -EINVAL;
> 	}
> 
> 	if (guest_pcr_bit > host_pcr_bit)
> 		return -EINVAL;
> 
> 	pcr = host_pcr_bit - guest_pcr_bit;
That approach is simpler and more extensible, I guess I don't really
like that it relies on the assumption that the PCR bits remain
consecutive and breaks if that assumption becomes invalid, which may
never be the case. I guess we can assume they will be for now and fix
it in the event that ever changes.
> 
> The translation from arch_compat to guest_pcr_bit might look neater
> as
> a table lookup on the low bits of arch_compat, after a bounds check.
Is that really necessary? I don't see the benefit and the code is more
readable in it's current form IMO.

Something like this?

unsigned long guest_pcr_bits = {0,              /* 0 */ 
                                0,              /* 1 */ 
                                PCR_ARCH_205,   /* 0x0F000002 */
                                PCR_ARCH_206,   /* 0x0F000003 */
                                PCR_ARCH_207,   /* 0x0F000004 */
                                PCR_ARCH_300 }; /* 0x0F000005 */
if (arch_compat <= PVR_ARCH_300 && arch_compat >= PVR_ARCH_205)
        guest_pcr_bit = guest_pcr_bits[arch_compat & 0xF]; 
else    
        return -EINVAL;
> 
> Paul.

      reply	other threads:[~2016-11-01  2:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-31  0:28 [PATCH V2 0/2] powerpc: add support for ISA v2.07 compat level Suraj Jitindar Singh
2016-10-31  0:28 ` [PATCH V2 1/2] powerpc: Define new ISA v3.00 logical PVR value and PCR register value Suraj Jitindar Singh
2016-10-31  0:28 ` [PATCH V2 2/2] powerpc/kvm: Update kvmppc_set_arch_compat() for ISA v3.00 Suraj Jitindar Singh
2016-10-31  5:44   ` Paul Mackerras
2016-11-01  2:47     ` Suraj Jitindar Singh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1477968451.2143.7.camel@gmail.com \
    --to=sjitindarsingh@gmail.com \
    --cc=agraf@suse.com \
    --cc=benh@kernel.crashing.org \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox