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);
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
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>
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
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
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 >
© 2016 - 2024 Red Hat, Inc.