From: Sean Christopherson <seanjc@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, llvm@lists.linux.dev,
linux-kernel@vger.kernel.org, Ajay Garg <ajaygargnsit@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] KVM: x86: Shove vp_bitmap handling down into sparse_set_to_vcpu_mask()
Date: Fri, 29 Oct 2021 14:32:26 +0000 [thread overview]
Message-ID: <YXwF+jSnDq9ONTQJ@google.com> (raw)
In-Reply-To: <87pmrokn16.fsf@vitty.brq.redhat.com>
On Fri, Oct 29, 2021, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@google.com> writes:
> > There's a smoke test for this in selftests, but it's not really all that
> > interesting. It took me over an hour and a half just to get a Linux guest
> > to hit the relevant flows. Most of that was due to QEMU 5.1 bugs (doesn't
> > advertise HYPERCALL MSR by default)
>
> This should be fixed already, right?
Yeah, it's fixed in more recent versions. That added to the confusion; the local
copy of QEMU source I was reading didn't match the binary I was using. Doh.
> > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> > index 4f15c0165c05..80018cfab5c7 100644
> > --- a/arch/x86/kvm/hyperv.c
> > +++ b/arch/x86/kvm/hyperv.c
> > @@ -1710,31 +1710,36 @@ int kvm_hv_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata, bool host)
> > return kvm_hv_get_msr(vcpu, msr, pdata, host);
> > }
> >
> > -static __always_inline unsigned long *sparse_set_to_vcpu_mask(
> > - struct kvm *kvm, u64 *sparse_banks, u64 valid_bank_mask,
> > - u64 *vp_bitmap, unsigned long *vcpu_bitmap)
> > +static void sparse_set_to_vcpu_mask(struct kvm *kvm, u64 *sparse_banks,
> > + u64 valid_bank_mask, unsigned long *vcpu_mask)
> > {
> > struct kvm_hv *hv = to_kvm_hv(kvm);
> > + bool has_mismatch = atomic_read(&hv->num_mismatched_vp_indexes);
> > + u64 vp_bitmap[KVM_HV_MAX_SPARSE_VCPU_SET_BITS];
> > struct kvm_vcpu *vcpu;
> > int i, bank, sbank = 0;
> > + u64 *bitmap;
> >
> > - memset(vp_bitmap, 0,
> > - KVM_HV_MAX_SPARSE_VCPU_SET_BITS * sizeof(*vp_bitmap));
> > + BUILD_BUG_ON(sizeof(vp_bitmap) >
> > + sizeof(*vcpu_mask) * BITS_TO_LONGS(KVM_MAX_VCPUS));
> > +
> > + /* If vp_index == vcpu_idx for all vCPUs, fill vcpu_mask directly. */
> > + if (likely(!has_mismatch))
> > + bitmap = (u64 *)vcpu_mask;
> > +
> > + memset(bitmap, 0, sizeof(vp_bitmap));
>
> ... but in the unlikely case has_mismatch == true 'bitmap' is still
> uninitialized here, right? How doesn't it crash?
I'm sure it does crash. I'll hack the guest to actually test this. More below.
> > for_each_set_bit(bank, (unsigned long *)&valid_bank_mask,
> > KVM_HV_MAX_SPARSE_VCPU_SET_BITS)
> > - vp_bitmap[bank] = sparse_banks[sbank++];
> > + bitmap[bank] = sparse_banks[sbank++];
> >
> > - if (likely(!atomic_read(&hv->num_mismatched_vp_indexes))) {
> > - /* for all vcpus vp_index == vcpu_idx */
> > - return (unsigned long *)vp_bitmap;
> > - }
> > + if (likely(!has_mismatch))
> > + return;
> >
> > - bitmap_zero(vcpu_bitmap, KVM_MAX_VCPUS);
> > + bitmap_zero(vcpu_mask, KVM_MAX_VCPUS);
> > kvm_for_each_vcpu(i, vcpu, kvm) {
> > if (test_bit(kvm_hv_get_vpindex(vcpu), (unsigned long *)vp_bitmap))
>
> 'vp_bitmap' also doesn't seem to be assigned to anything, I'm really
> confused :-(
>
> Didn't you accidentally mix up 'vp_bitmap' and 'bitmap'?
No, bitmap was supposed to be initialized as:
if (likely(!has_mismatch))
bitmap = (u64 *)vcpu_mask;
else
bitmap = vp_bitmap;
The idea being that the !mismatch case sets vcpu_mask directly, and the mismatch
case sets vp_bitmap and then uses that to fill vcpu_mask.
next prev parent reply other threads:[~2021-10-29 14:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-28 21:34 [PATCH] KVM: x86: Shove vp_bitmap handling down into sparse_set_to_vcpu_mask() Sean Christopherson
2021-10-29 12:56 ` Vitaly Kuznetsov
2021-10-29 14:32 ` Sean Christopherson [this message]
2021-10-29 19:06 ` Sean Christopherson
2021-10-29 19:26 ` Sean Christopherson
2021-10-29 19:42 ` Sean Christopherson
2021-10-31 19:05 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YXwF+jSnDq9ONTQJ@google.com \
--to=seanjc@google.com \
--cc=ajaygargnsit@gmail.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox