[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 3/3] ppc/kvm: check some capabilities with kvm_vm_
From: |
Greg Kurz |
Subject: |
Re: [Qemu-ppc] [PATCH 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension() |
Date: |
Fri, 15 Sep 2017 10:43:20 +0200 |
On Fri, 15 Sep 2017 07:15:41 +0200
Thomas Huth <address@hidden> 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 <address@hidden>
> > ---
> > 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 <address@hidden>
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 <address@hidden>
Signed-off-by: Paul Mackerras <address@hidden>
> Anyway, that's another topic, your patch is fine!
>
> Reviewed-by: Thomas Huth <address@hidden>
pgpCOPL3687xW.pgp
Description: OpenPGP digital signature
- Re: [Qemu-ppc] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension(), (continued)
Re: [Qemu-ppc] [PATCH 3/3] ppc/kvm: check some capabilities with kvm_vm_check_extension(), David Gibson, 2017/09/15