Messages in this thread Patch in this message | | | Subject | Re: [PATCH 1/4] KVM: x86: Tag APICv DISABLE inhibit, not ABSENT, if APICv is disabled | From | Maxim Levitsky <> | Date | Mon, 18 Apr 2022 11:37:48 +0300 |
| |
On Sat, 2022-04-16 at 03:42 +0000, Sean Christopherson wrote: > Set the DISABLE inhibit, not the ABSENT inhibit, if APICv is disabled via > module param. A recent refactoring to add a wrapper for setting/clearing > inhibits unintentionally changed the flag, probably due to a copy+paste > goof. > > Fixes: 4f4c4a3ee53c ("KVM: x86: Trace all APICv inhibit changes and capture overall status") > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/x86.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index ab336f7c82e4..753296902535 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -9159,7 +9159,7 @@ static void kvm_apicv_init(struct kvm *kvm) > > if (!enable_apicv) > set_or_clear_apicv_inhibit(inhibits, > - APICV_INHIBIT_REASON_ABSENT, true); > + APICV_INHIBIT_REASON_DISABLE, true); > } > > static void kvm_sched_yield(struct kvm_vcpu *vcpu, unsigned long dest_id)
So ABSENT means that userspace didn't enable, it and DISABLE means kernel module param disabled it. I didn't follow patches that touched those but it feels like we can use a single inhibit reason for both, or at least make better names for this. APICV_INHIBIT_REASON_ABSENT doesn't sound good to me.
Having said that, the patch is OK.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Best regards, Maxim Levitsky
| |