[Qemu-devel] [PATCH 0/3] kvm: use kvm_vm_check_extension() with VM capabilities

[Qemu-devel] [PATCH 0/3] kvm: use kvm_vm_check_extension() with VM capabilities

[Greg Kurz]

Some VM capabilities are currently checked with kvm_check_extension(). This
doesn't have any impact for most host architectures because they don't depend
on the KVM type. However, this is a problem for server-class ppc hosts that
can support the PR and HV KVM types. Both implementations can co-exist in the
kernel at the same time and we decide which one will be used with the "type"
argument of the KVM_CREATE_VM ioctl.

Each KVM type has a different set of capabilities, and checking them with
kvm_check_extension() will always cause KVM to assume we're in HV mode,
even if they are VM specific and we have explicitely requested to run in
PR mode. This may produce unexpected results.

A similar issue was recently fix in the ppc code:

https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg03751.html

This series goes a bit further, and turns more kvm_check_extension() into
kvm_vm_check_extension() where appropriate.

--
Greg

---

Greg Kurz (3):
      kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()
      kvm: check KVM_CAP_NR_VCPUS with kvm_vm_check_extension()
      ppc/kvm: check some capabilities with kvm_vm_check_extension()


 accel/kvm/kvm-all.c |   47 ++++++++++++++++++++++++-----------------------
 target/ppc/kvm.c    |    6 +++---
 2 files changed, 27 insertions(+), 26 deletions(-)

[Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

[Greg Kurz]

On a server-class ppc host, this capability depends on the KVM type,
ie, HV or PR. If both KVM are present in the kernel, we will always
get the HV specific value, even if we explicitely requested PR on
the command line.

This can have an impact if we're using hugepages or a balloon device.

Since we've already created the VM at the time any user calls
kvm_has_sync_mmu(), switching to kvm_vm_check_extension() is
enough to fix any potential issue.

It is okay for the other archs that also implement KVM_CAP_SYNC_MMU,
ie, mips, s390, x86 and arm, because they don't depend on the VM being
created or not.

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

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index f85553a85194..323c567cfb68 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2234,7 +2234,7 @@ int kvm_device_access(int fd, int group, uint64_t attr,
 /* Return 1 on success, 0 on failure */
 int kvm_has_sync_mmu(void)
 {
-    return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
+    return kvm_vm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
 }
 
 int kvm_has_vcpu_events(void)

[Qemu-devel] [PATCH 2/3] kvm: check KVM_CAP_NR_VCPUS with kvm_vm_check_extension()

[Greg Kurz]

On a modern server-class ppc host with the following CPU topology:

Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                32
On-line CPU(s) list:   0,8,16,24
Off-line CPU(s) list:  1-7,9-15,17-23,25-31
Thread(s) per core:    1

If both KVM PR and KVM HV loaded and we pass:

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

We expect QEMU to warn that this exceeds the number of online CPUs:

Warning: Number of SMP cpus requested (8) exceeds the recommended
 cpus supported by KVM (4)
Warning: Number of hotpluggable cpus requested (8) exceeds the
 recommended cpus supported by KVM (4)

but nothing is printed...

This happens because on ppc the KVM_CAP_NR_VCPUS capability is VM
specific  ndreally depends on the KVM type, but we currently use it
as a global capability. And KVM returns a fallback value based on
KVM HV being present. Maybe KVM on POWER shouldn't presume anything
as long as it doesn't have a VM, but in all cases, we should call
KVM_CREATE_VM first and use KVM_CAP_NR_VCPUS as a VM capability.

This patch hence changes kvm_recommended_vcpus() accordingly and
moves the sanity checking of smp_cpus after the VM creation.

It is okay for the other archs that also implement KVM_CAP_NR_VCPUS,
ie, mips, s390, x86 and arm, because they don't depend on the VM
being created or not.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 accel/kvm/kvm-all.c |   45 +++++++++++++++++++++++----------------------
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 323c567cfb68..d10534de2da1 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1533,7 +1533,7 @@ static void kvm_irqchip_create(MachineState *machine, KVMState *s)
  */
 static int kvm_recommended_vcpus(KVMState *s)
 {
-    int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
+    int ret = kvm_vm_check_extension(s, KVM_CAP_NR_VCPUS);
     return (ret) ? ret : 4;
 }
 
@@ -1623,27 +1623,6 @@ static int kvm_init(MachineState *ms)
         s->nr_slots = 32;
     }
 
-    /* check the vcpu limits */
-    soft_vcpus_limit = kvm_recommended_vcpus(s);
-    hard_vcpus_limit = kvm_max_vcpus(s);
-
-    while (nc->name) {
-        if (nc->num > soft_vcpus_limit) {
-            fprintf(stderr,
-                    "Warning: Number of %s cpus requested (%d) exceeds "
-                    "the recommended cpus supported by KVM (%d)\n",
-                    nc->name, nc->num, soft_vcpus_limit);
-
-            if (nc->num > hard_vcpus_limit) {
-                fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
-                        "the maximum cpus supported by KVM (%d)\n",
-                        nc->name, nc->num, hard_vcpus_limit);
-                exit(1);
-            }
-        }
-        nc++;
-    }
-
     kvm_type = qemu_opt_get(qemu_get_machine_opts(), "kvm-type");
     if (mc->kvm_type) {
         type = mc->kvm_type(kvm_type);
@@ -1678,6 +1657,28 @@ static int kvm_init(MachineState *ms)
     }
 
     s->vmfd = ret;
+
+    /* check the vcpu limits */
+    soft_vcpus_limit = kvm_recommended_vcpus(s);
+    hard_vcpus_limit = kvm_max_vcpus(s);
+
+    while (nc->name) {
+        if (nc->num > soft_vcpus_limit) {
+            fprintf(stderr,
+                    "Warning: Number of %s cpus requested (%d) exceeds "
+                    "the recommended cpus supported by KVM (%d)\n",
+                    nc->name, nc->num, soft_vcpus_limit);
+
+            if (nc->num > hard_vcpus_limit) {
+                fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
+                        "the maximum cpus supported by KVM (%d)\n",
+                        nc->name, nc->num, hard_vcpus_limit);
+                exit(1);
+            }
+        }
+        nc++;
+    }
+
     missing_cap = kvm_check_extension_list(s, kvm_required_capabilites);
     if (!missing_cap) {
         missing_cap =

[Qemu-devel] [PATCH 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension()

[Greg Kurz]

The following capabilities are VM specific:
- KVM_CAP_PPC_SMT_POSSIBLE
- KVM_CAP_PPC_HTAB_FD
- KVM_CAP_PPC_ALLOC_HTAB

If both KVM HV and KVM PR are present, checking them always return
the HV value, even if we explicitely requested to use PR.

This has no visible effect for KVM_CAP_PPC_ALLOC_HTAB, because we also
try the KVM_PPC_ALLOCATE_HTAB ioctl which is only suppored by HV. As
a consequence, the spapr code doesn't even check KVM_CAP_PPC_HTAB_FD.

However, this will cause kvmppc_hint_smt_possible(), introduced by
commit fa98fbfcdfcb9, to report several VSMT modes (eg, Available
VSMT modes: 8 4 2 1) whereas PR only support mode 1.

This patch fixes all three anyway to use kvm_vm_check_extension(). It
is okay since the VM is already created at the time kvm_arch_init() or
kvmppc_reset_htab() is called.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 target/ppc/kvm.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 1deaf106d2b9..208c70e81426 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -131,7 +131,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
     cap_interrupt_level = kvm_check_extension(s, KVM_CAP_PPC_IRQ_LEVEL);
     cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE);
     cap_booke_sregs = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_SREGS);
-    cap_ppc_smt_possible = kvm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);
+    cap_ppc_smt_possible = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);
     cap_ppc_rma = kvm_check_extension(s, KVM_CAP_PPC_RMA);
     cap_spapr_tce = kvm_check_extension(s, KVM_CAP_SPAPR_TCE);
     cap_spapr_tce_64 = kvm_check_extension(s, KVM_CAP_SPAPR_TCE_64);
@@ -143,7 +143,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
     cap_ppc_watchdog = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_WATCHDOG);
     /* Note: we don't set cap_papr here, because this capability is
      * only activated after this by kvmppc_set_papr() */
-    cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
+    cap_htab_fd = kvm_vm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
     cap_fixup_hcalls = kvm_check_extension(s, KVM_CAP_PPC_FIXUP_HCALL);
     cap_ppc_smt = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT);
     cap_htm = kvm_vm_check_extension(s, KVM_CAP_PPC_HTM);
@@ -2353,7 +2353,7 @@ int kvmppc_reset_htab(int shift_hint)
         /* Full emulation, tell caller to allocate htab itself */
         return 0;
     }
-    if (kvm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
+    if (kvm_vm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
         int ret;
         ret = kvm_vm_ioctl(kvm_state, KVM_PPC_ALLOCATE_HTAB, &shift);
         if (ret == -ENOTTY) {

Re: [Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

[David Gibson]

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

On Thu, Sep 14, 2017 at 09:25:22PM +0200, Greg Kurz wrote:
> On a server-class ppc host, this capability depends on the KVM type,
> ie, HV or PR. If both KVM are present in the kernel, we will always
> get the HV specific value, even if we explicitely requested PR on
> the command line.
> 
> This can have an impact if we're using hugepages or a balloon device.
> 
> Since we've already created the VM at the time any user calls
> kvm_has_sync_mmu(), switching to kvm_vm_check_extension() is
> enough to fix any potential issue.
> 
> It is okay for the other archs that also implement KVM_CAP_SYNC_MMU,
> ie, mips, s390, x86 and arm, because they don't depend on the VM being
> created or not.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

> ---
>  accel/kvm/kvm-all.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index f85553a85194..323c567cfb68 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -2234,7 +2234,7 @@ int kvm_device_access(int fd, int group, uint64_t attr,
>  /* Return 1 on success, 0 on failure */
>  int kvm_has_sync_mmu(void)
>  {
> -    return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> +    return kvm_vm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
>  }
>  
>  int kvm_has_vcpu_events(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 2/3] kvm: check KVM_CAP_NR_VCPUS with kvm_vm_check_extension()

[David Gibson]

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

On Thu, Sep 14, 2017 at 09:25:32PM +0200, Greg Kurz wrote:
1;4803;0c> On a modern server-class ppc host with the following CPU topology:
> 
> Architecture:          ppc64le
> Byte Order:            Little Endian
> CPU(s):                32
> On-line CPU(s) list:   0,8,16,24
> Off-line CPU(s) list:  1-7,9-15,17-23,25-31
> Thread(s) per core:    1
> 
> If both KVM PR and KVM HV loaded and we pass:
> 
>         -machine pseries,accel=kvm,kvm-type=PR -smp 8
> 
> We expect QEMU to warn that this exceeds the number of online CPUs:
> 
> Warning: Number of SMP cpus requested (8) exceeds the recommended
>  cpus supported by KVM (4)
> Warning: Number of hotpluggable cpus requested (8) exceeds the
>  recommended cpus supported by KVM (4)
> 
> but nothing is printed...
> 
> This happens because on ppc the KVM_CAP_NR_VCPUS capability is VM
> specific  ndreally depends on the KVM type, but we currently use it
> as a global capability. And KVM returns a fallback value based on
> KVM HV being present. Maybe KVM on POWER shouldn't presume anything
> as long as it doesn't have a VM, but in all cases, we should call
> KVM_CREATE_VM first and use KVM_CAP_NR_VCPUS as a VM capability.
> 
> This patch hence changes kvm_recommended_vcpus() accordingly and
> moves the sanity checking of smp_cpus after the VM creation.
> 
> It is okay for the other archs that also implement KVM_CAP_NR_VCPUS,
> ie, mips, s390, x86 and arm, because they don't depend on the VM
> being created or not.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

> ---
>  accel/kvm/kvm-all.c |   45 +++++++++++++++++++++++----------------------
>  1 file changed, 23 insertions(+), 22 deletions(-)
> 
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index 323c567cfb68..d10534de2da1 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -1533,7 +1533,7 @@ static void kvm_irqchip_create(MachineState *machine, KVMState *s)
>   */
>  static int kvm_recommended_vcpus(KVMState *s)
>  {
> -    int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
> +    int ret = kvm_vm_check_extension(s, KVM_CAP_NR_VCPUS);
>      return (ret) ? ret : 4;
>  }
>  
> @@ -1623,27 +1623,6 @@ static int kvm_init(MachineState *ms)
>          s->nr_slots = 32;
>      }
>  
> -    /* check the vcpu limits */
> -    soft_vcpus_limit = kvm_recommended_vcpus(s);
> -    hard_vcpus_limit = kvm_max_vcpus(s);
> -
> -    while (nc->name) {
> -        if (nc->num > soft_vcpus_limit) {
> -            fprintf(stderr,
> -                    "Warning: Number of %s cpus requested (%d) exceeds "
> -                    "the recommended cpus supported by KVM (%d)\n",
> -                    nc->name, nc->num, soft_vcpus_limit);
> -
> -            if (nc->num > hard_vcpus_limit) {
> -                fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
> -                        "the maximum cpus supported by KVM (%d)\n",
> -                        nc->name, nc->num, hard_vcpus_limit);
> -                exit(1);
> -            }
> -        }
> -        nc++;
> -    }
> -
>      kvm_type = qemu_opt_get(qemu_get_machine_opts(), "kvm-type");
>      if (mc->kvm_type) {
>          type = mc->kvm_type(kvm_type);
> @@ -1678,6 +1657,28 @@ static int kvm_init(MachineState *ms)
>      }
>  
>      s->vmfd = ret;
> +
> +    /* check the vcpu limits */
> +    soft_vcpus_limit = kvm_recommended_vcpus(s);
> +    hard_vcpus_limit = kvm_max_vcpus(s);
> +
> +    while (nc->name) {
> +        if (nc->num > soft_vcpus_limit) {
> +            fprintf(stderr,
> +                    "Warning: Number of %s cpus requested (%d) exceeds "
> +                    "the recommended cpus supported by KVM (%d)\n",
> +                    nc->name, nc->num, soft_vcpus_limit);
> +
> +            if (nc->num > hard_vcpus_limit) {
> +                fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
> +                        "the maximum cpus supported by KVM (%d)\n",
> +                        nc->name, nc->num, hard_vcpus_limit);
> +                exit(1);
> +            }
> +        }
> +        nc++;
> +    }
> +
>      missing_cap = kvm_check_extension_list(s, kvm_required_capabilites);
>      if (!missing_cap) {
>          missing_cap =
> 

-- 
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 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension()

[Thomas Huth]

On 14.09.2017 21:25, Greg Kurz wrote:
> The following capabilities are VM specific:
> - KVM_CAP_PPC_SMT_POSSIBLE
> - KVM_CAP_PPC_HTAB_FD

BTW, looks like kvmppc_has_cap_htab_fd() is dead code ... should we
either remove it or check it somewhere?

> - KVM_CAP_PPC_ALLOC_HTAB
> 
> If both KVM HV and KVM PR are present, checking them always return
> the HV value, even if we explicitely requested to use PR.
> 
> This has no visible effect for KVM_CAP_PPC_ALLOC_HTAB, because we also
> try the KVM_PPC_ALLOCATE_HTAB ioctl which is only suppored by HV. As
> a consequence, the spapr code doesn't even check KVM_CAP_PPC_HTAB_FD.
>
> However, this will cause kvmppc_hint_smt_possible(), introduced by
> commit fa98fbfcdfcb9, to report several VSMT modes (eg, Available
> VSMT modes: 8 4 2 1) whereas PR only support mode 1.
> 
> This patch fixes all three anyway to use kvm_vm_check_extension(). It
> is okay since the VM is already created at the time kvm_arch_init() or
> kvmppc_reset_htab() is called.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  target/ppc/kvm.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 1deaf106d2b9..208c70e81426 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -131,7 +131,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>      cap_interrupt_level = kvm_check_extension(s, KVM_CAP_PPC_IRQ_LEVEL);
>      cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE);
>      cap_booke_sregs = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_SREGS);
> -    cap_ppc_smt_possible = kvm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);
> +    cap_ppc_smt_possible = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);
>      cap_ppc_rma = kvm_check_extension(s, KVM_CAP_PPC_RMA);
>      cap_spapr_tce = kvm_check_extension(s, KVM_CAP_SPAPR_TCE);
>      cap_spapr_tce_64 = kvm_check_extension(s, KVM_CAP_SPAPR_TCE_64);
> @@ -143,7 +143,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>      cap_ppc_watchdog = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_WATCHDOG);
>      /* Note: we don't set cap_papr here, because this capability is
>       * only activated after this by kvmppc_set_papr() */
> -    cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
> +    cap_htab_fd = kvm_vm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
>      cap_fixup_hcalls = kvm_check_extension(s, KVM_CAP_PPC_FIXUP_HCALL);
>      cap_ppc_smt = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT);
>      cap_htm = kvm_vm_check_extension(s, KVM_CAP_PPC_HTM);
> @@ -2353,7 +2353,7 @@ int kvmppc_reset_htab(int shift_hint)
>          /* Full emulation, tell caller to allocate htab itself */
>          return 0;
>      }
> -    if (kvm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
> +    if (kvm_vm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
>          int ret;
>          ret = kvm_vm_ioctl(kvm_state, KVM_PPC_ALLOCATE_HTAB, &shift);
>          if (ret == -ENOTTY) {

Looking at the comment in the code after the "if (ret == -ENOTTY)" line,
it sounds like there is a bug in the kernel and the
KVM_CAP_PPC_ALLOC_HTAB should depend on the hv_enabled variable, too?
Anyway, that's another topic, your patch is fine!

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

Re: [Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

[Thomas Huth]

On 14.09.2017 21:25, Greg Kurz wrote:
> On a server-class ppc host, this capability depends on the KVM type,
> ie, HV or PR. If both KVM are present in the kernel, we will always
> get the HV specific value, even if we explicitely requested PR on
> the command line.
> 
> This can have an impact if we're using hugepages or a balloon device.
> 
> Since we've already created the VM at the time any user calls
> kvm_has_sync_mmu(), switching to kvm_vm_check_extension() is
> enough to fix any potential issue.
> 
> It is okay for the other archs that also implement KVM_CAP_SYNC_MMU,
> ie, mips, s390, x86 and arm, because they don't depend on the VM being
> created or not.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  accel/kvm/kvm-all.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index f85553a85194..323c567cfb68 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -2234,7 +2234,7 @@ int kvm_device_access(int fd, int group, uint64_t attr,
>  /* Return 1 on success, 0 on failure */
>  int kvm_has_sync_mmu(void)
>  {
> -    return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> +    return kvm_vm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
>  }

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

... but while you're at it, maybe it would be better to use a bool
variable for the state of this extension, too, and only check for the
extension one time at the end of kvm_init() ? kvm_has_sync_mmu() is
apparently used multiple times in other source files, so we might be
able to save some cycles by doing the syscall only once?

 Thomas

Re: [Qemu-devel] [PATCH 2/3] kvm: check KVM_CAP_NR_VCPUS with kvm_vm_check_extension()

[Thomas Huth]

On 14.09.2017 21:25, Greg Kurz wrote:
> On a modern server-class ppc host with the following CPU topology:
> 
> Architecture:          ppc64le
> Byte Order:            Little Endian
> CPU(s):                32
> On-line CPU(s) list:   0,8,16,24
> Off-line CPU(s) list:  1-7,9-15,17-23,25-31
> Thread(s) per core:    1
> 
> If both KVM PR and KVM HV loaded and we pass:
> 
>         -machine pseries,accel=kvm,kvm-type=PR -smp 8
> 
> We expect QEMU to warn that this exceeds the number of online CPUs:
> 
> Warning: Number of SMP cpus requested (8) exceeds the recommended
>  cpus supported by KVM (4)
> Warning: Number of hotpluggable cpus requested (8) exceeds the
>  recommended cpus supported by KVM (4)
> 
> but nothing is printed...
> 
> This happens because on ppc the KVM_CAP_NR_VCPUS capability is VM
> specific  ndreally depends on the KVM type, but we currently use it
> as a global capability. And KVM returns a fallback value based on
> KVM HV being present. Maybe KVM on POWER shouldn't presume anything
> as long as it doesn't have a VM, but in all cases, we should call
> KVM_CREATE_VM first and use KVM_CAP_NR_VCPUS as a VM capability.
> 
> This patch hence changes kvm_recommended_vcpus() accordingly and
> moves the sanity checking of smp_cpus after the VM creation.
> 
> It is okay for the other archs that also implement KVM_CAP_NR_VCPUS,
> ie, mips, s390, x86 and arm, because they don't depend on the VM
> being created or not.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  accel/kvm/kvm-all.c |   45 +++++++++++++++++++++++----------------------
>  1 file changed, 23 insertions(+), 22 deletions(-)
> 
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index 323c567cfb68..d10534de2da1 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -1533,7 +1533,7 @@ static void kvm_irqchip_create(MachineState *machine, KVMState *s)
>   */
>  static int kvm_recommended_vcpus(KVMState *s)
>  {
> -    int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
> +    int ret = kvm_vm_check_extension(s, KVM_CAP_NR_VCPUS);
>      return (ret) ? ret : 4;
>  }
>  
> @@ -1623,27 +1623,6 @@ static int kvm_init(MachineState *ms)
>          s->nr_slots = 32;
>      }
>  
> -    /* check the vcpu limits */
> -    soft_vcpus_limit = kvm_recommended_vcpus(s);
> -    hard_vcpus_limit = kvm_max_vcpus(s);
> -
> -    while (nc->name) {
> -        if (nc->num > soft_vcpus_limit) {
> -            fprintf(stderr,
> -                    "Warning: Number of %s cpus requested (%d) exceeds "
> -                    "the recommended cpus supported by KVM (%d)\n",
> -                    nc->name, nc->num, soft_vcpus_limit);
> -
> -            if (nc->num > hard_vcpus_limit) {
> -                fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
> -                        "the maximum cpus supported by KVM (%d)\n",
> -                        nc->name, nc->num, hard_vcpus_limit);
> -                exit(1);
> -            }
> -        }
> -        nc++;
> -    }
> -
>      kvm_type = qemu_opt_get(qemu_get_machine_opts(), "kvm-type");
>      if (mc->kvm_type) {
>          type = mc->kvm_type(kvm_type);
> @@ -1678,6 +1657,28 @@ static int kvm_init(MachineState *ms)
>      }
>  
>      s->vmfd = ret;
> +
> +    /* check the vcpu limits */
> +    soft_vcpus_limit = kvm_recommended_vcpus(s);
> +    hard_vcpus_limit = kvm_max_vcpus(s);
> +
> +    while (nc->name) {
> +        if (nc->num > soft_vcpus_limit) {
> +            fprintf(stderr,
> +                    "Warning: Number of %s cpus requested (%d) exceeds "
> +                    "the recommended cpus supported by KVM (%d)\n",
> +                    nc->name, nc->num, soft_vcpus_limit);
> +
> +            if (nc->num > hard_vcpus_limit) {
> +                fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
> +                        "the maximum cpus supported by KVM (%d)\n",
> +                        nc->name, nc->num, hard_vcpus_limit);
> +                exit(1);
> +            }
> +        }
> +        nc++;
> +    }
> +
>      missing_cap = kvm_check_extension_list(s, kvm_required_capabilites);
>      if (!missing_cap) {
>          missing_cap =
> 

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

Re: [Qemu-devel] [PATCH 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension()

[David Gibson]

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

On Thu, Sep 14, 2017 at 09:25:43PM +0200, Greg Kurz wrote:
> The following capabilities are VM specific:
> - KVM_CAP_PPC_SMT_POSSIBLE
> - KVM_CAP_PPC_HTAB_FD
> - KVM_CAP_PPC_ALLOC_HTAB
> 
> If both KVM HV and KVM PR are present, checking them always return
> the HV value, even if we explicitely requested to use PR.
> 
> This has no visible effect for KVM_CAP_PPC_ALLOC_HTAB, because we also
> try the KVM_PPC_ALLOCATE_HTAB ioctl which is only suppored by HV. As
> a consequence, the spapr code doesn't even check KVM_CAP_PPC_HTAB_FD.
> 
> However, this will cause kvmppc_hint_smt_possible(), introduced by
> commit fa98fbfcdfcb9, to report several VSMT modes (eg, Available
> VSMT modes: 8 4 2 1) whereas PR only support mode 1.
> 
> This patch fixes all three anyway to use kvm_vm_check_extension(). It
> is okay since the VM is already created at the time kvm_arch_init() or
> kvmppc_reset_htab() is called.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>

Applied to ppc-for-2.11.

> ---
>  target/ppc/kvm.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 1deaf106d2b9..208c70e81426 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -131,7 +131,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>      cap_interrupt_level = kvm_check_extension(s, KVM_CAP_PPC_IRQ_LEVEL);
>      cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE);
>      cap_booke_sregs = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_SREGS);
> -    cap_ppc_smt_possible = kvm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);
> +    cap_ppc_smt_possible = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);
>      cap_ppc_rma = kvm_check_extension(s, KVM_CAP_PPC_RMA);
>      cap_spapr_tce = kvm_check_extension(s, KVM_CAP_SPAPR_TCE);
>      cap_spapr_tce_64 = kvm_check_extension(s, KVM_CAP_SPAPR_TCE_64);
> @@ -143,7 +143,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>      cap_ppc_watchdog = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_WATCHDOG);
>      /* Note: we don't set cap_papr here, because this capability is
>       * only activated after this by kvmppc_set_papr() */
> -    cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
> +    cap_htab_fd = kvm_vm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
>      cap_fixup_hcalls = kvm_check_extension(s, KVM_CAP_PPC_FIXUP_HCALL);
>      cap_ppc_smt = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT);
>      cap_htm = kvm_vm_check_extension(s, KVM_CAP_PPC_HTM);
> @@ -2353,7 +2353,7 @@ int kvmppc_reset_htab(int shift_hint)
>          /* Full emulation, tell caller to allocate htab itself */
>          return 0;
>      }
> -    if (kvm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
> +    if (kvm_vm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
>          int ret;
>          ret = kvm_vm_ioctl(kvm_state, KVM_PPC_ALLOCATE_HTAB, &shift);
>          if (ret == -ENOTTY) {
> 

-- 
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 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension()

[David Gibson]

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

On Fri, Sep 15, 2017 at 07:15:41AM +0200, Thomas Huth wrote:
> On 14.09.2017 21:25, Greg Kurz wrote:
> > The following capabilities are VM specific:
> > - KVM_CAP_PPC_SMT_POSSIBLE
> > - KVM_CAP_PPC_HTAB_FD
> 
> BTW, looks like kvmppc_has_cap_htab_fd() is dead code ... should we
> either remove it or check it somewhere?

It's checked in kvmppc_get_htab_fd().

-- 
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 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension()

[Thomas Huth]

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

On 15.09.2017 08:35, David Gibson wrote:
> On Fri, Sep 15, 2017 at 07:15:41AM +0200, Thomas Huth wrote:
>> On 14.09.2017 21:25, Greg Kurz wrote:
>>> The following capabilities are VM specific:
>>> - KVM_CAP_PPC_SMT_POSSIBLE
>>> - KVM_CAP_PPC_HTAB_FD
>>
>> BTW, looks like kvmppc_has_cap_htab_fd() is dead code ... should we
>> either remove it or check it somewhere?
> 
> It's checked in kvmppc_get_htab_fd().

That function checks the "cap_htab_fd" variable, but is not using the
kvmppc_has_cap_htab_fd() function which I was referring to.

 Thomas


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

Re: [Qemu-devel] [PATCH 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension()

[David Gibson]

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

On Fri, Sep 15, 2017 at 10:18:49AM +0200, Thomas Huth wrote:
> On 15.09.2017 08:35, David Gibson wrote:
> > On Fri, Sep 15, 2017 at 07:15:41AM +0200, Thomas Huth wrote:
> >> On 14.09.2017 21:25, Greg Kurz wrote:
> >>> The following capabilities are VM specific:
> >>> - KVM_CAP_PPC_SMT_POSSIBLE
> >>> - KVM_CAP_PPC_HTAB_FD
> >>
> >> BTW, looks like kvmppc_has_cap_htab_fd() is dead code ... should we
> >> either remove it or check it somewhere?
> > 
> > It's checked in kvmppc_get_htab_fd().
> 
> That function checks the "cap_htab_fd" variable, but is not using the
> kvmppc_has_cap_htab_fd() function which I was referring to.

Oh, sorry, good point.

We should remove it.

-- 
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 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension()

[Greg Kurz]

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

On Fri, 15 Sep 2017 07:15:41 +0200
Thomas Huth <thuth@redhat.com> wrote:

> On 14.09.2017 21:25, Greg Kurz wrote:
> > The following capabilities are VM specific:
> > - KVM_CAP_PPC_SMT_POSSIBLE
> > - KVM_CAP_PPC_HTAB_FD  
> 
> BTW, looks like kvmppc_has_cap_htab_fd() is dead code ... should we
> either remove it or check it somewhere?
> 

Heh you're right :)

The only user for cap_htab_fd is kvmppc_get_htab_fd(), in order to provide a
sensible error message that KVM doesn't allow saving HPTEs (ie, migration isn't
supported with some older KVM HV). It doesn't need kvmppc_has_cap_htab_fd() for
that since all the code sits in target/ppc/kvm.c.

I can't think of any other use, so I guess we can drop it.

> > - KVM_CAP_PPC_ALLOC_HTAB
> > 
> > If both KVM HV and KVM PR are present, checking them always return
> > the HV value, even if we explicitely requested to use PR.
> > 
> > This has no visible effect for KVM_CAP_PPC_ALLOC_HTAB, because we also
> > try the KVM_PPC_ALLOCATE_HTAB ioctl which is only suppored by HV. As
> > a consequence, the spapr code doesn't even check KVM_CAP_PPC_HTAB_FD.
> >
> > However, this will cause kvmppc_hint_smt_possible(), introduced by
> > commit fa98fbfcdfcb9, to report several VSMT modes (eg, Available
> > VSMT modes: 8 4 2 1) whereas PR only support mode 1.
> > 
> > This patch fixes all three anyway to use kvm_vm_check_extension(). It
> > is okay since the VM is already created at the time kvm_arch_init() or
> > kvmppc_reset_htab() is called.
> > 
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >  target/ppc/kvm.c |    6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> > index 1deaf106d2b9..208c70e81426 100644
> > --- a/target/ppc/kvm.c
> > +++ b/target/ppc/kvm.c
> > @@ -131,7 +131,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> >      cap_interrupt_level = kvm_check_extension(s, KVM_CAP_PPC_IRQ_LEVEL);
> >      cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE);
> >      cap_booke_sregs = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_SREGS);
> > -    cap_ppc_smt_possible = kvm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);
> > +    cap_ppc_smt_possible = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);
> >      cap_ppc_rma = kvm_check_extension(s, KVM_CAP_PPC_RMA);
> >      cap_spapr_tce = kvm_check_extension(s, KVM_CAP_SPAPR_TCE);
> >      cap_spapr_tce_64 = kvm_check_extension(s, KVM_CAP_SPAPR_TCE_64);
> > @@ -143,7 +143,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> >      cap_ppc_watchdog = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_WATCHDOG);
> >      /* Note: we don't set cap_papr here, because this capability is
> >       * only activated after this by kvmppc_set_papr() */
> > -    cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
> > +    cap_htab_fd = kvm_vm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
> >      cap_fixup_hcalls = kvm_check_extension(s, KVM_CAP_PPC_FIXUP_HCALL);
> >      cap_ppc_smt = kvm_vm_check_extension(s, KVM_CAP_PPC_SMT);
> >      cap_htm = kvm_vm_check_extension(s, KVM_CAP_PPC_HTM);
> > @@ -2353,7 +2353,7 @@ int kvmppc_reset_htab(int shift_hint)
> >          /* Full emulation, tell caller to allocate htab itself */
> >          return 0;
> >      }
> > -    if (kvm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
> > +    if (kvm_vm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
> >          int ret;
> >          ret = kvm_vm_ioctl(kvm_state, KVM_PPC_ALLOCATE_HTAB, &shift);
> >          if (ret == -ENOTTY) {  
> 
> Looking at the comment in the code after the "if (ret == -ENOTTY)" line,
> it sounds like there is a bug in the kernel and the
> KVM_CAP_PPC_ALLOC_HTAB should depend on the hv_enabled variable, too?

It already does :)

commit a8acaece5d88db234d0b82b8692dea15d602f622
Author: David Gibson <david@gibson.dropbear.id.au>
Date:   Wed Nov 23 16:14:07 2016 +1100

    KVM: PPC: Correctly report KVM_CAP_PPC_ALLOC_HTAB
    
    At present KVM on powerpc always reports KVM_CAP_PPC_ALLOC_HTAB as enabled.
    However, the ioctl() it advertises (KVM_PPC_ALLOCATE_HTAB) only actually
    works on KVM HV.  On KVM PR it will fail with ENOTTY.
    
    QEMU already has a workaround for this, so it's not breaking things in
    practice, but it would be better to advertise this correctly.
    
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>

> Anyway, that's another topic, your patch is fine!
> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>


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

Re: [Qemu-devel] [PATCH 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension()

[Thomas Huth]

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

On 15.09.2017 10:43, Greg Kurz wrote:
> On Fri, 15 Sep 2017 07:15:41 +0200
> Thomas Huth <thuth@redhat.com> wrote:
> 
>> On 14.09.2017 21:25, Greg Kurz wrote:
>>> The following capabilities are VM specific:
>>> - KVM_CAP_PPC_SMT_POSSIBLE
>>> - KVM_CAP_PPC_HTAB_FD  
>>
>> BTW, looks like kvmppc_has_cap_htab_fd() is dead code ... should we
>> either remove it or check it somewhere?
>>
> 
> Heh you're right :)
> 
> The only user for cap_htab_fd is kvmppc_get_htab_fd(), in order to provide a
> sensible error message that KVM doesn't allow saving HPTEs (ie, migration isn't
> supported with some older KVM HV). It doesn't need kvmppc_has_cap_htab_fd() for
> that since all the code sits in target/ppc/kvm.c.
> 
> I can't think of any other use, so I guess we can drop it.

OK. If you've got some spare minutes, could you maybe send a patch?

[...]
>>> @@ -2353,7 +2353,7 @@ int kvmppc_reset_htab(int shift_hint)
>>>          /* Full emulation, tell caller to allocate htab itself */
>>>          return 0;
>>>      }
>>> -    if (kvm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
>>> +    if (kvm_vm_check_extension(kvm_state, KVM_CAP_PPC_ALLOC_HTAB)) {
>>>          int ret;
>>>          ret = kvm_vm_ioctl(kvm_state, KVM_PPC_ALLOCATE_HTAB, &shift);
>>>          if (ret == -ENOTTY) {  
>>
>> Looking at the comment in the code after the "if (ret == -ENOTTY)" line,
>> it sounds like there is a bug in the kernel and the
>> KVM_CAP_PPC_ALLOC_HTAB should depend on the hv_enabled variable, too?
> 
> It already does :)
> 
> commit a8acaece5d88db234d0b82b8692dea15d602f622

Oh, right, seems like I was looking at an older kernel branch :-/ So
never mind, we're fine here.

 Thomas


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

Re: [Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

[Greg Kurz]

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

On Fri, 15 Sep 2017 07:32:10 +0200
Thomas Huth <thuth@redhat.com> wrote:

> On 14.09.2017 21:25, Greg Kurz wrote:
> > On a server-class ppc host, this capability depends on the KVM type,
> > ie, HV or PR. If both KVM are present in the kernel, we will always
> > get the HV specific value, even if we explicitely requested PR on
> > the command line.
> > 
> > This can have an impact if we're using hugepages or a balloon device.
> > 
> > Since we've already created the VM at the time any user calls
> > kvm_has_sync_mmu(), switching to kvm_vm_check_extension() is
> > enough to fix any potential issue.
> > 
> > It is okay for the other archs that also implement KVM_CAP_SYNC_MMU,
> > ie, mips, s390, x86 and arm, because they don't depend on the VM being
> > created or not.
> > 
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >  accel/kvm/kvm-all.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> > index f85553a85194..323c567cfb68 100644
> > --- a/accel/kvm/kvm-all.c
> > +++ b/accel/kvm/kvm-all.c
> > @@ -2234,7 +2234,7 @@ int kvm_device_access(int fd, int group, uint64_t attr,
> >  /* Return 1 on success, 0 on failure */
> >  int kvm_has_sync_mmu(void)
> >  {
> > -    return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> > +    return kvm_vm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> >  }  
> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> 
> ... but while you're at it, maybe it would be better to use a bool
> variable for the state of this extension, too, and only check for the
> extension one time at the end of kvm_init() ? kvm_has_sync_mmu() is
> apparently used multiple times in other source files, so we might be
> able to save some cycles by doing the syscall only once?
> 
>  Thomas
> 
> 

Oops, I had overlooked your answer... yes it makes sense indeed.

I'll post a v2 of this patch (not resending the whole series).

Cheers,

--
Greg

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