On Fri, May 30, 2025, Sairaj Kodilkar wrote:
> On 5/23/2025 6:29 AM, Sean Christopherson wrote:
> > Infer whether or not a vCPU should be marked running from the validity of
> > the pCPU on which it is running. amd_iommu_update_ga() already skips the
> > IRTE update if the pCPU is invalid, i.e. passing %true for is_run with an
> > invalid pCPU would be a blatant and egregrious KVM bug.
> >
> > Tested-by: Sairaj Kodilkar <sarunkod@xxxxxxx>
> > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> > ---
> > arch/x86/kvm/svm/avic.c | 11 +++++------
> > drivers/iommu/amd/iommu.c | 14 +++++++++-----
> > include/linux/amd-iommu.h | 6 ++----
> > 3 files changed, 16 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> > index 4747fb09aca4..c79648d96752 100644
> > --- a/arch/x86/kvm/svm/avic.c
> > +++ b/arch/x86/kvm/svm/avic.c
> > @@ -832,7 +832,7 @@ int avic_pi_update_irte(struct kvm_kernel_irqfd *irqfd, struct kvm *kvm,
> > entry = svm->avic_physical_id_entry;
> > if (entry & AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK)
> > amd_iommu_update_ga(entry & AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK,
> > - true, pi_data.ir_data);
> > + pi_data.ir_data);
> > irqfd->irq_bypass_data = pi_data.ir_data;
> > list_add(&irqfd->vcpu_list, &svm->ir_list);
> > @@ -841,8 +841,7 @@ int avic_pi_update_irte(struct kvm_kernel_irqfd *irqfd, struct kvm *kvm,
> > return irq_set_vcpu_affinity(host_irq, NULL);
> > }
> > -static inline int
> > -avic_update_iommu_vcpu_affinity(struct kvm_vcpu *vcpu, int cpu, bool r)
> > +static inline int avic_update_iommu_vcpu_affinity(struct kvm_vcpu *vcpu, int cpu)
> > {
>
> Hi sean
>
> What if define cpu as "unsigned int" instead of "int" and use nr_cpu_ids
> as invalid cpu id ? I see that it is common in the other subsystems to
> use nr_cpu_ids instead of -1.
My vote is for -1, as it makes the KVM side of things much more intuitive
E.g. this is pretty obviously saying "no associated CPU"
avic_update_iommu_vcpu_affinity(vcpu, -1);
whereas this honestly just looks a bit weird.
avic_update_iommu_vcpu_affinity(vcpu, nr_cpu_ids);
It also requires knowing what cpu numbers are strictly packed in the kernel, i.e.
that nr_cpu_ids is guaranteed to be greater than the cpu numbers themselves (e.g.
the the kernel can't have nr_cpu_ids=2 with CPU0 and CPU2 being the two CPUs).
I also don't love that nr_cpu_ids is __read_mostly, i.e. isn't const post-boot
(though at a glance, it looks like it could be __ro_after_init on x86 at least).
