[Qemu-devel] [PATCH] ppc/kvm: use kvm_vm_check_extension() in kvmppc_is_pr()

[Qemu-devel] [PATCH] ppc/kvm: use kvm_vm_check_extension() in kvmppc_is_pr()

[Greg Kurz]

If the host has both KVM PR and KVM HV loaded and we pass:

	-machine pseries,accel=kvm,kvm-type=PR

the kvmppc_is_pr() returns false instead of true. Since the helper
is mostly used as fallback, it doesn't have any real impact with
recent kernels. A notable exception is the workaround to allow
migration between compatible hosts with different PVRs (eg, POWER8
and POWER8E), since KVM still doesn't provide a way to check if a
specific PVR is supported (see commit c363a37a450f for details).

According to the official KVM API documentation [1], KVM_PPC_GET_PVINFO
is "vm ioctl", but we check it as a global ioctl. The following function
in KVM is hence called with kvm == NULL and considers we're in HV mode.

int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
{
	int r;
	/* Assume we're using HV mode when the HV module is loaded */
	int hv_enabled = kvmppc_hv_ops ? 1 : 0;

	if (kvm) {
		/*
		 * Hooray - we know which VM type we're running on. Depend on
		 * that rather than the guess above.
		 */
		hv_enabled = is_kvmppc_hv_enabled(kvm);
	}

Let's use kvm_vm_check_extension() to fix the issue.

[1] https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 target/ppc/kvm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 6442dfcb95b3..1deaf106d2b9 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -120,7 +120,7 @@ static void kvm_kick_cpu(void *opaque)
 static bool kvmppc_is_pr(KVMState *ks)
 {
     /* Assume KVM-PR if the GET_PVINFO capability is available */
-    return kvm_check_extension(ks, KVM_CAP_PPC_GET_PVINFO) != 0;
+    return kvm_vm_check_extension(ks, KVM_CAP_PPC_GET_PVINFO) != 0;
 }
 
 static int kvm_ppc_register_host_cpu_type(void);

Re: [Qemu-devel] [PATCH] ppc/kvm: use kvm_vm_check_extension() in kvmppc_is_pr()

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

On Thu, Sep 14, 2017 at 12:48:04PM +0200, Greg Kurz wrote:
> If the host has both KVM PR and KVM HV loaded and we pass:
> 
> 	-machine pseries,accel=kvm,kvm-type=PR
> 
> the kvmppc_is_pr() returns false instead of true. Since the helper
> is mostly used as fallback, it doesn't have any real impact with
> recent kernels. A notable exception is the workaround to allow
> migration between compatible hosts with different PVRs (eg, POWER8
> and POWER8E), since KVM still doesn't provide a way to check if a
> specific PVR is supported (see commit c363a37a450f for details).
> 
> According to the official KVM API documentation [1], KVM_PPC_GET_PVINFO
> is "vm ioctl", but we check it as a global ioctl. The following function
> in KVM is hence called with kvm == NULL and considers we're in HV mode.
> 
> int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> {
> 	int r;
> 	/* Assume we're using HV mode when the HV module is loaded */
> 	int hv_enabled = kvmppc_hv_ops ? 1 : 0;
> 
> 	if (kvm) {
> 		/*
> 		 * Hooray - we know which VM type we're running on. Depend on
> 		 * that rather than the guess above.
> 		 */
> 		hv_enabled = is_kvmppc_hv_enabled(kvm);
> 	}
> 
> Let's use kvm_vm_check_extension() to fix the issue.
> 
> [1] https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>

Applied to ppc-for-2.11, good catch.

> ---
>  target/ppc/kvm.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 6442dfcb95b3..1deaf106d2b9 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -120,7 +120,7 @@ static void kvm_kick_cpu(void *opaque)
>  static bool kvmppc_is_pr(KVMState *ks)
>  {
>      /* Assume KVM-PR if the GET_PVINFO capability is available */
> -    return kvm_check_extension(ks, KVM_CAP_PPC_GET_PVINFO) != 0;
> +    return kvm_vm_check_extension(ks, KVM_CAP_PPC_GET_PVINFO) != 0;
>  }
>  
>  static int kvm_ppc_register_host_cpu_type(void);
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] [PATCH] ppc/kvm: use kvm_vm_check_extension() in kvmppc_is_pr()

[Thomas Huth]

On 14.09.2017 12:48, Greg Kurz wrote:
> If the host has both KVM PR and KVM HV loaded and we pass:
> 
> 	-machine pseries,accel=kvm,kvm-type=PR
> 
> the kvmppc_is_pr() returns false instead of true. Since the helper
> is mostly used as fallback, it doesn't have any real impact with
> recent kernels. A notable exception is the workaround to allow
> migration between compatible hosts with different PVRs (eg, POWER8
> and POWER8E), since KVM still doesn't provide a way to check if a
> specific PVR is supported (see commit c363a37a450f for details).
> 
> According to the official KVM API documentation [1], KVM_PPC_GET_PVINFO
> is "vm ioctl", but we check it as a global ioctl. The following function
> in KVM is hence called with kvm == NULL and considers we're in HV mode.
> 
> int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> {
> 	int r;
> 	/* Assume we're using HV mode when the HV module is loaded */
> 	int hv_enabled = kvmppc_hv_ops ? 1 : 0;
> 
> 	if (kvm) {
> 		/*
> 		 * Hooray - we know which VM type we're running on. Depend on
> 		 * that rather than the guess above.
> 		 */
> 		hv_enabled = is_kvmppc_hv_enabled(kvm);
> 	}
> 
> Let's use kvm_vm_check_extension() to fix the issue.
> 
> [1] https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  target/ppc/kvm.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 6442dfcb95b3..1deaf106d2b9 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -120,7 +120,7 @@ static void kvm_kick_cpu(void *opaque)
>  static bool kvmppc_is_pr(KVMState *ks)
>  {
>      /* Assume KVM-PR if the GET_PVINFO capability is available */
> -    return kvm_check_extension(ks, KVM_CAP_PPC_GET_PVINFO) != 0;
> +    return kvm_vm_check_extension(ks, KVM_CAP_PPC_GET_PVINFO) != 0;
>  }
>  
>  static int kvm_ppc_register_host_cpu_type(void);
> 

Ooops, good catch!

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [Qemu-devel] [PATCH] ppc/kvm: use kvm_vm_check_extension() in kvmppc_is_pr()

[Thomas Huth]

On 14.09.2017 12:48, Greg Kurz wrote:
> If the host has both KVM PR and KVM HV loaded and we pass:
> 
> 	-machine pseries,accel=kvm,kvm-type=PR
> 
> the kvmppc_is_pr() returns false instead of true. Since the helper
> is mostly used as fallback, it doesn't have any real impact with
> recent kernels. A notable exception is the workaround to allow
> migration between compatible hosts with different PVRs (eg, POWER8
> and POWER8E), since KVM still doesn't provide a way to check if a
> specific PVR is supported (see commit c363a37a450f for details).
> 
> According to the official KVM API documentation [1], KVM_PPC_GET_PVINFO
> is "vm ioctl", but we check it as a global ioctl. The following function
> in KVM is hence called with kvm == NULL and considers we're in HV mode.
> 
> int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> {
> 	int r;
> 	/* Assume we're using HV mode when the HV module is loaded */
> 	int hv_enabled = kvmppc_hv_ops ? 1 : 0;
> 
> 	if (kvm) {
> 		/*
> 		 * Hooray - we know which VM type we're running on. Depend on
> 		 * that rather than the guess above.
> 		 */
> 		hv_enabled = is_kvmppc_hv_enabled(kvm);
> 	}
> 
> Let's use kvm_vm_check_extension() to fix the issue.

By the way, what about the other CAPs that rely on hv_enabled? grepping
through the QEMU sources, I can see:

 cap_ppc_smt = kvm_check_extension(s, KVM_CAP_PPC_SMT);

 cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);

 int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);

 return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);

 !kvm_check_extension(cs->kvm_state, KVM_CAP_SW_TLB)) {

... do we need to fix them, too?

 Thomas

Re: [Qemu-devel] [PATCH] ppc/kvm: use kvm_vm_check_extension() in kvmppc_is_pr()

[Greg Kurz]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

On Thu, 14 Sep 2017 13:17:48 +0200
Thomas Huth <thuth@redhat.com> wrote:

> On 14.09.2017 12:48, Greg Kurz wrote:
> > If the host has both KVM PR and KVM HV loaded and we pass:
> > 
> > 	-machine pseries,accel=kvm,kvm-type=PR
> > 
> > the kvmppc_is_pr() returns false instead of true. Since the helper
> > is mostly used as fallback, it doesn't have any real impact with
> > recent kernels. A notable exception is the workaround to allow
> > migration between compatible hosts with different PVRs (eg, POWER8
> > and POWER8E), since KVM still doesn't provide a way to check if a
> > specific PVR is supported (see commit c363a37a450f for details).
> > 
> > According to the official KVM API documentation [1], KVM_PPC_GET_PVINFO
> > is "vm ioctl", but we check it as a global ioctl. The following function
> > in KVM is hence called with kvm == NULL and considers we're in HV mode.
> > 
> > int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > {
> > 	int r;
> > 	/* Assume we're using HV mode when the HV module is loaded */
> > 	int hv_enabled = kvmppc_hv_ops ? 1 : 0;
> > 
> > 	if (kvm) {
> > 		/*
> > 		 * Hooray - we know which VM type we're running on. Depend on
> > 		 * that rather than the guess above.
> > 		 */
> > 		hv_enabled = is_kvmppc_hv_enabled(kvm);
> > 	}
> > 
> > Let's use kvm_vm_check_extension() to fix the issue.  
> 
> By the way, what about the other CAPs that rely on hv_enabled? grepping
> through the QEMU sources, I can see:
> 
>  cap_ppc_smt = kvm_check_extension(s, KVM_CAP_PPC_SMT);
> 
>  cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
> 
>  int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
> 
>  return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> 
>  !kvm_check_extension(cs->kvm_state, KVM_CAP_SW_TLB)) {
> 
> ... do we need to fix them, too?
> 

I'm currently going through the KVM code to see which ones need to be
fixed. I'll send more patches shortly :)

Cheers,

--
Greg

>  Thomas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc/kvm: use kvm_vm_check_extension() in kvmppc_is_pr()

[Greg Kurz]

[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

On Thu, 14 Sep 2017 13:27:49 +0200
Greg Kurz <groug@kaod.org> wrote:

> On Thu, 14 Sep 2017 13:17:48 +0200
> Thomas Huth <thuth@redhat.com> wrote:
> 
> > On 14.09.2017 12:48, Greg Kurz wrote:  
> > > If the host has both KVM PR and KVM HV loaded and we pass:
> > > 
> > > 	-machine pseries,accel=kvm,kvm-type=PR
> > > 
> > > the kvmppc_is_pr() returns false instead of true. Since the helper
> > > is mostly used as fallback, it doesn't have any real impact with
> > > recent kernels. A notable exception is the workaround to allow
> > > migration between compatible hosts with different PVRs (eg, POWER8
> > > and POWER8E), since KVM still doesn't provide a way to check if a
> > > specific PVR is supported (see commit c363a37a450f for details).
> > > 
> > > According to the official KVM API documentation [1], KVM_PPC_GET_PVINFO
> > > is "vm ioctl", but we check it as a global ioctl. The following function
> > > in KVM is hence called with kvm == NULL and considers we're in HV mode.
> > > 
> > > int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > {
> > > 	int r;
> > > 	/* Assume we're using HV mode when the HV module is loaded */
> > > 	int hv_enabled = kvmppc_hv_ops ? 1 : 0;
> > > 
> > > 	if (kvm) {
> > > 		/*
> > > 		 * Hooray - we know which VM type we're running on. Depend on
> > > 		 * that rather than the guess above.
> > > 		 */
> > > 		hv_enabled = is_kvmppc_hv_enabled(kvm);
> > > 	}
> > > 
> > > Let's use kvm_vm_check_extension() to fix the issue.    
> > 
> > By the way, what about the other CAPs that rely on hv_enabled? grepping
> > through the QEMU sources, I can see:
> > 
> >  cap_ppc_smt = kvm_check_extension(s, KVM_CAP_PPC_SMT);
> > 

So this one was already fixed in David's ppc-for-2.11 branch thanks to
commit fa98fbfcdfcb9... which introduced a new KVM_CAP_PPC_SMT_POSSIBLE
cap, which is also a VM ioctl and needs to be fixed :)

    cap_ppc_smt_possible = kvm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);

> >  cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
> > 

Needs fixing.

> >  int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
> > 

Needs fixing.

> >  return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> > 

Needs fixing.

> >  !kvm_check_extension(cs->kvm_state, KVM_CAP_SW_TLB)) {
> > 

This seems to be e500 specific, and thus isn't affected.

> > ... do we need to fix them, too?
> >   
> 
> I'm currently going through the KVM code to see which ones need to be
> fixed. I'll send more patches shortly :)
> 
> Cheers,
> 
> --
> Greg
> 
> >  Thomas  
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]