| Message ID | 20220613133922.2875594-11-vkuznets@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86: hyper-v: Fine-grained TLB flush + L2 TLB flush features | expand |
On 6/13/22 15:38, Vitaly Kuznetsov wrote: > Get rid of on-stack allocation of vcpu_mask and optimize kvm_hv_send_ipi() > for a smaller number of vCPUs in the request. When Hyper-V TLB flush > is in use, HvSendSyntheticClusterIpi{,Ex} calls are not commonly used to > send IPIs to a large number of vCPUs (and are rarely used in general). > > Introduce hv_is_vp_in_sparse_set() to directly check if the specified > VP_ID is present in sparse vCPU set. > > Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> > --- > arch/x86/kvm/hyperv.c | 37 ++++++++++++++++++++++++++----------- > 1 file changed, 26 insertions(+), 11 deletions(-) I'm a bit confused by this patch being in this series. Just to be clear, PV IPI does *not* support the VP_ID, right? And since patch 12 only affects the sparse banks, the patch does not have any other dependency. Is this correct? Paolo > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index f41153c71beb..269a5fcca31b 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -1747,6 +1747,25 @@ static void sparse_set_to_vcpu_mask(struct kvm *kvm, u64 *sparse_banks, > } > } > > +static bool hv_is_vp_in_sparse_set(u32 vp_id, u64 valid_bank_mask, u64 sparse_banks[]) > +{ > + int bank, sbank = 0; > + > + if (!test_bit(vp_id / HV_VCPUS_PER_SPARSE_BANK, > + (unsigned long *)&valid_bank_mask)) > + return false; > + > + for_each_set_bit(bank, (unsigned long *)&valid_bank_mask, > + KVM_HV_MAX_SPARSE_VCPU_SET_BITS) { > + if (bank == vp_id / HV_VCPUS_PER_SPARSE_BANK) > + break; > + sbank++; > + } > + > + return test_bit(vp_id % HV_VCPUS_PER_SPARSE_BANK, > + (unsigned long *)&sparse_banks[sbank]); > +} > + > struct kvm_hv_hcall { > u64 param; > u64 ingpa; > @@ -2029,8 +2048,8 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) > ((u64)hc->rep_cnt << HV_HYPERCALL_REP_COMP_OFFSET); > } > > -static void kvm_send_ipi_to_many(struct kvm *kvm, u32 vector, > - unsigned long *vcpu_bitmap) > +static void kvm_hv_send_ipi_to_many(struct kvm *kvm, u32 vector, > + u64 *sparse_banks, u64 valid_bank_mask) > { > struct kvm_lapic_irq irq = { > .delivery_mode = APIC_DM_FIXED, > @@ -2040,7 +2059,10 @@ static void kvm_send_ipi_to_many(struct kvm *kvm, u32 vector, > unsigned long i; > > kvm_for_each_vcpu(i, vcpu, kvm) { > - if (vcpu_bitmap && !test_bit(i, vcpu_bitmap)) > + if (sparse_banks && > + !hv_is_vp_in_sparse_set(kvm_hv_get_vpindex(vcpu), > + valid_bank_mask, > + sparse_banks)) > continue; > > /* We fail only when APIC is disabled */ > @@ -2053,7 +2075,6 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) > struct kvm *kvm = vcpu->kvm; > struct hv_send_ipi_ex send_ipi_ex; > struct hv_send_ipi send_ipi; > - DECLARE_BITMAP(vcpu_mask, KVM_MAX_VCPUS); > u64 valid_bank_mask; > u64 sparse_banks[KVM_HV_MAX_SPARSE_VCPU_SET_BITS]; > u32 vector; > @@ -2115,13 +2136,7 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) > if ((vector < HV_IPI_LOW_VECTOR) || (vector > HV_IPI_HIGH_VECTOR)) > return HV_STATUS_INVALID_HYPERCALL_INPUT; > > - if (all_cpus) { > - kvm_send_ipi_to_many(kvm, vector, NULL); > - } else { > - sparse_set_to_vcpu_mask(kvm, sparse_banks, valid_bank_mask, vcpu_mask); > - > - kvm_send_ipi_to_many(kvm, vector, vcpu_mask); > - } > + kvm_hv_send_ipi_to_many(kvm, vector, all_cpus ? NULL : sparse_banks, valid_bank_mask); > > ret_success: > return HV_STATUS_SUCCESS;
Paolo Bonzini <pbonzini@redhat.com> writes: > On 6/13/22 15:38, Vitaly Kuznetsov wrote: >> Get rid of on-stack allocation of vcpu_mask and optimize kvm_hv_send_ipi() >> for a smaller number of vCPUs in the request. When Hyper-V TLB flush >> is in use, HvSendSyntheticClusterIpi{,Ex} calls are not commonly used to >> send IPIs to a large number of vCPUs (and are rarely used in general). >> >> Introduce hv_is_vp_in_sparse_set() to directly check if the specified >> VP_ID is present in sparse vCPU set. >> >> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> >> --- >> arch/x86/kvm/hyperv.c | 37 ++++++++++++++++++++++++++----------- >> 1 file changed, 26 insertions(+), 11 deletions(-) > > I'm a bit confused by this patch being in this series. > > Just to be clear, PV IPI does *not* support the VP_ID, right? Hm, with Hyper-V PV IPI hypercall vCPUs are also addressed by their VP_IDs, not by their APIC ids so similar to Hyper-V PV TLB flush we need to convert the supplied set (either flat u64 bitmask of VP_IDs for non-EX hypercall or a sparse set for -EX). > And since patch 12 only affects the sparse banks, the patch does not > have any other dependency. Is this correct? > This patch introduces hv_is_vp_in_sparse_set() with its first user: kvm_hv_send_ipi_to_many(). Later in the series, hv_is_vp_in_sparse_set() gets a second user: kvm_hv_flush_tlb() for 'nested' case where we actually have to traverse all vCPUs checking *nested* VP_IDs (as KVM doesn't currently keep a convenient L2-VP_ID-to-kvm-vcpu-id mapping. > Paolo > >> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c >> index f41153c71beb..269a5fcca31b 100644 >> --- a/arch/x86/kvm/hyperv.c >> +++ b/arch/x86/kvm/hyperv.c >> @@ -1747,6 +1747,25 @@ static void sparse_set_to_vcpu_mask(struct kvm *kvm, u64 *sparse_banks, >> } >> } >> >> +static bool hv_is_vp_in_sparse_set(u32 vp_id, u64 valid_bank_mask, u64 sparse_banks[]) >> +{ >> + int bank, sbank = 0; >> + >> + if (!test_bit(vp_id / HV_VCPUS_PER_SPARSE_BANK, >> + (unsigned long *)&valid_bank_mask)) >> + return false; >> + >> + for_each_set_bit(bank, (unsigned long *)&valid_bank_mask, >> + KVM_HV_MAX_SPARSE_VCPU_SET_BITS) { >> + if (bank == vp_id / HV_VCPUS_PER_SPARSE_BANK) >> + break; >> + sbank++; >> + } >> + >> + return test_bit(vp_id % HV_VCPUS_PER_SPARSE_BANK, >> + (unsigned long *)&sparse_banks[sbank]); >> +} >> + >> struct kvm_hv_hcall { >> u64 param; >> u64 ingpa; >> @@ -2029,8 +2048,8 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) >> ((u64)hc->rep_cnt << HV_HYPERCALL_REP_COMP_OFFSET); >> } >> >> -static void kvm_send_ipi_to_many(struct kvm *kvm, u32 vector, >> - unsigned long *vcpu_bitmap) >> +static void kvm_hv_send_ipi_to_many(struct kvm *kvm, u32 vector, >> + u64 *sparse_banks, u64 valid_bank_mask) >> { >> struct kvm_lapic_irq irq = { >> .delivery_mode = APIC_DM_FIXED, >> @@ -2040,7 +2059,10 @@ static void kvm_send_ipi_to_many(struct kvm *kvm, u32 vector, >> unsigned long i; >> >> kvm_for_each_vcpu(i, vcpu, kvm) { >> - if (vcpu_bitmap && !test_bit(i, vcpu_bitmap)) >> + if (sparse_banks && >> + !hv_is_vp_in_sparse_set(kvm_hv_get_vpindex(vcpu), >> + valid_bank_mask, >> + sparse_banks)) >> continue; >> >> /* We fail only when APIC is disabled */ >> @@ -2053,7 +2075,6 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) >> struct kvm *kvm = vcpu->kvm; >> struct hv_send_ipi_ex send_ipi_ex; >> struct hv_send_ipi send_ipi; >> - DECLARE_BITMAP(vcpu_mask, KVM_MAX_VCPUS); >> u64 valid_bank_mask; >> u64 sparse_banks[KVM_HV_MAX_SPARSE_VCPU_SET_BITS]; >> u32 vector; >> @@ -2115,13 +2136,7 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) >> if ((vector < HV_IPI_LOW_VECTOR) || (vector > HV_IPI_HIGH_VECTOR)) >> return HV_STATUS_INVALID_HYPERCALL_INPUT; >> >> - if (all_cpus) { >> - kvm_send_ipi_to_many(kvm, vector, NULL); >> - } else { >> - sparse_set_to_vcpu_mask(kvm, sparse_banks, valid_bank_mask, vcpu_mask); >> - >> - kvm_send_ipi_to_many(kvm, vector, vcpu_mask); >> - } >> + kvm_hv_send_ipi_to_many(kvm, vector, all_cpus ? NULL : sparse_banks, valid_bank_mask); >> >> ret_success: >> return HV_STATUS_SUCCESS; >
On 6/21/22 15:17, Vitaly Kuznetsov wrote: >> >> Just to be clear, PV IPI does*not* support the VP_ID, right? > Hm, with Hyper-V PV IPI hypercall vCPUs are also addressed by their > VP_IDs, not by their APIC ids so similar to Hyper-V PV TLB flush we need > to convert the supplied set (either flat u64 bitmask of VP_IDs for > non-EX hypercall or a sparse set for -EX). > So this means the series needs a v8, right? Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > On 6/21/22 15:17, Vitaly Kuznetsov wrote: >>> >>> Just to be clear, PV IPI does*not* support the VP_ID, right? >> Hm, with Hyper-V PV IPI hypercall vCPUs are also addressed by their >> VP_IDs, not by their APIC ids so similar to Hyper-V PV TLB flush we need >> to convert the supplied set (either flat u64 bitmask of VP_IDs for >> non-EX hypercall or a sparse set for -EX). >> > > So this means the series needs a v8, right? > No, I was just trying to explaini what the patch is doing in the series, it looks good to me (but I'm biased, of course).
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index f41153c71beb..269a5fcca31b 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -1747,6 +1747,25 @@ static void sparse_set_to_vcpu_mask(struct kvm *kvm, u64 *sparse_banks, } } +static bool hv_is_vp_in_sparse_set(u32 vp_id, u64 valid_bank_mask, u64 sparse_banks[]) +{ + int bank, sbank = 0; + + if (!test_bit(vp_id / HV_VCPUS_PER_SPARSE_BANK, + (unsigned long *)&valid_bank_mask)) + return false; + + for_each_set_bit(bank, (unsigned long *)&valid_bank_mask, + KVM_HV_MAX_SPARSE_VCPU_SET_BITS) { + if (bank == vp_id / HV_VCPUS_PER_SPARSE_BANK) + break; + sbank++; + } + + return test_bit(vp_id % HV_VCPUS_PER_SPARSE_BANK, + (unsigned long *)&sparse_banks[sbank]); +} + struct kvm_hv_hcall { u64 param; u64 ingpa; @@ -2029,8 +2048,8 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) ((u64)hc->rep_cnt << HV_HYPERCALL_REP_COMP_OFFSET); } -static void kvm_send_ipi_to_many(struct kvm *kvm, u32 vector, - unsigned long *vcpu_bitmap) +static void kvm_hv_send_ipi_to_many(struct kvm *kvm, u32 vector, + u64 *sparse_banks, u64 valid_bank_mask) { struct kvm_lapic_irq irq = { .delivery_mode = APIC_DM_FIXED, @@ -2040,7 +2059,10 @@ static void kvm_send_ipi_to_many(struct kvm *kvm, u32 vector, unsigned long i; kvm_for_each_vcpu(i, vcpu, kvm) { - if (vcpu_bitmap && !test_bit(i, vcpu_bitmap)) + if (sparse_banks && + !hv_is_vp_in_sparse_set(kvm_hv_get_vpindex(vcpu), + valid_bank_mask, + sparse_banks)) continue; /* We fail only when APIC is disabled */ @@ -2053,7 +2075,6 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) struct kvm *kvm = vcpu->kvm; struct hv_send_ipi_ex send_ipi_ex; struct hv_send_ipi send_ipi; - DECLARE_BITMAP(vcpu_mask, KVM_MAX_VCPUS); u64 valid_bank_mask; u64 sparse_banks[KVM_HV_MAX_SPARSE_VCPU_SET_BITS]; u32 vector; @@ -2115,13 +2136,7 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc) if ((vector < HV_IPI_LOW_VECTOR) || (vector > HV_IPI_HIGH_VECTOR)) return HV_STATUS_INVALID_HYPERCALL_INPUT; - if (all_cpus) { - kvm_send_ipi_to_many(kvm, vector, NULL); - } else { - sparse_set_to_vcpu_mask(kvm, sparse_banks, valid_bank_mask, vcpu_mask); - - kvm_send_ipi_to_many(kvm, vector, vcpu_mask); - } + kvm_hv_send_ipi_to_many(kvm, vector, all_cpus ? NULL : sparse_banks, valid_bank_mask); ret_success: return HV_STATUS_SUCCESS;
Get rid of on-stack allocation of vcpu_mask and optimize kvm_hv_send_ipi() for a smaller number of vCPUs in the request. When Hyper-V TLB flush is in use, HvSendSyntheticClusterIpi{,Ex} calls are not commonly used to send IPIs to a large number of vCPUs (and are rarely used in general). Introduce hv_is_vp_in_sparse_set() to directly check if the specified VP_ID is present in sparse vCPU set. Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> --- arch/x86/kvm/hyperv.c | 37 ++++++++++++++++++++++++++----------- 1 file changed, 26 insertions(+), 11 deletions(-)