From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 27CAA2C3268 for ; Wed, 11 Jun 2025 22:47:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749682043; cv=none; b=BCKGfBCXLRdQ7YY0qKNdF4oA0SM+w9FxAO7k4cBakCe5habD9qdvh6lQKIDHpbq/s+ZtELtG8GuQvmPmBnLwdrPf35+hGre5b4WnQUaJxOhF2AF/rWP6FGijUKGYKXPAUoRSPOwadxNgzzeXpvDoveU4R3BbmbW68rqTIWP5o1A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749682043; c=relaxed/simple; bh=+WCgHtdp2H3zFROg/kXRAOiJNVGT+bH93q9WZnv07eE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=VsI/Dq9x9mVeE2jIw1a8LaLZdfbP1EFAqtdeuCR7Md5OfjbLuM1wDXZRd/+jOOPzWN20E0DcV5vWUN2JKOCjSxAj8QXxWKk/Bjn8Rpg/1CwlcihicD3euTGScpZXy8p74pPuOr10UDBQip30rR0j2IP/Ntk9GXYupWcD+cEYugs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ggdwm+5J; arc=none smtp.client-ip=209.85.210.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ggdwm+5J" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-74880a02689so83647b3a.0 for ; Wed, 11 Jun 2025 15:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1749682039; x=1750286839; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=oUvsQ8mDIzQb0qFFdXVmPhQyIfkBQRy6OI+aTTyokEg=; b=ggdwm+5J4hhSNi8iHXU+UdPjBHMKb82uImhnHfRLBJZ8t/TWZUefS8m78tLZDCYgCk Mm/QjHdGDv3wBT9Aid20o5iO+sl06d0xboUZzEIyq/svTMxOzSdmtAixsmnJr3uUaEXO NBzRABf3ix6u84IykZXK8HBDMkfzkzcyGq0bU/Gay25jk7zCjMrRsFoPhBYpNQSZi/7U 8SvmZXK8NHRlAhQezAFEyTAaUwlIrh9S0KhpEUKZ6pKlSOGHsn3F0CA516RY1mJha2qz gkoILs5ITBaFLW9sEyhKvKG65DdV+z5X7qoYfAH7xU3NFuYYVKb37uXpgHzsI8NlsTrk Jp/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749682039; x=1750286839; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oUvsQ8mDIzQb0qFFdXVmPhQyIfkBQRy6OI+aTTyokEg=; b=t7Hi27uagU+7L6lfBxYrNRPwTfOmLczsBDODELppYBhRqna+8aokzHM1U/lEcJ5akF yUUJdDdIJjDBDhJyopKSG3QyQ2EpphE2zjjY9+rcdRr/kpymcXoFU6fvln/Ixldpgnu/ hC4S55IclhUyVG3waa7ck1JQdTD4K78LPHfgMd85q1BkqqmlzcE+wCTPaY9eImeBpUHt 46xeATmoSdb/nOuc59tc4KSAEVJozawr+emvnOaOfaHodR2mG/1IAJxWM4Hu4J63IGdd fM/6QvmVhGv5eq+yRs5DP9TylyYTzk4oPoqRy97YeOqObb+Q2MdEzdJSFJ3hN0MavYk3 8STw== X-Forwarded-Encrypted: i=1; AJvYcCVFnv5HEAuajg0dmX8HFAvrUfVQhtQ2aVFOVTyAqKDKaxCIK6+SIg3bYd4+fX2NrKN+O4w=@vger.kernel.org X-Gm-Message-State: AOJu0YycL8wL7x4Jjap2FP0TL3suo64CVfJ6gXFFwoyw0T6Gn4bwm9V+ fjNo6hD0hszAza9fQpNTZbaGBenSc0Qnlignz3mIuXmM1Fq8TebyS8ZhvCTS9iQXT79Na6GzfSI CkzY0aQ== X-Google-Smtp-Source: AGHT+IEfPx6THB86jTUP6dJfz6pw9nwRImiQrl8t3HHDUWJ7TfKep9MrKXl6SwXip961tO69ZHuJKVDD+j4= X-Received: from pfbfn21.prod.google.com ([2002:a05:6a00:2fd5:b0:746:270f:79c0]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:17a4:b0:748:31ed:ba8a with SMTP id d2e1a72fcca58-7486cbbf515mr6176704b3a.15.1749682038641; Wed, 11 Jun 2025 15:47:18 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 11 Jun 2025 15:45:16 -0700 In-Reply-To: <20250611224604.313496-2-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250611224604.313496-2-seanjc@google.com> X-Mailer: git-send-email 2.50.0.rc1.591.g9c95f17f64-goog Message-ID: <20250611224604.313496-15-seanjc@google.com> Subject: [PATCH v3 13/62] KVM: SVM: Drop redundant check in AVIC code on ID during vCPU creation From: Sean Christopherson To: Marc Zyngier , Oliver Upton , Sean Christopherson , Paolo Bonzini , Joerg Roedel , David Woodhouse , Lu Baolu Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Sairaj Kodilkar , Vasant Hegde , Maxim Levitsky , Joao Martins , Francesco Lavra , David Matlack Content-Type: text/plain; charset="UTF-8" Drop avic_get_physical_id_entry()'s compatibility check on the incoming ID, as its sole caller, avic_init_backing_page(), performs the exact same check. Drop avic_get_physical_id_entry() entirely as the only remaining functionality is getting the address of the Physical ID table, and accessing the array without an immediate bounds check is kludgy. Opportunistically add a compile-time assertion to ensure the vcpu_id can't result in a bounds overflow, e.g. if KVM (really) messed up a maximum physical ID #define, as well as run-time assertions so that a NULL pointer dereference is morphed into a safer WARN(). No functional change intended. Tested-by: Sairaj Kodilkar Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/avic.c | 37 +++++++++++++++---------------------- 1 file changed, 15 insertions(+), 22 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index f0a74b102c57..948bab48083b 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -256,26 +256,12 @@ void avic_init_vmcb(struct vcpu_svm *svm, struct vmcb *vmcb) avic_deactivate_vmcb(svm); } -static u64 *avic_get_physical_id_entry(struct kvm_vcpu *vcpu, - unsigned int index) -{ - u64 *avic_physical_id_table; - struct kvm_svm *kvm_svm = to_kvm_svm(vcpu->kvm); - - if ((!x2avic_enabled && index > AVIC_MAX_PHYSICAL_ID) || - (index > X2AVIC_MAX_PHYSICAL_ID)) - return NULL; - - avic_physical_id_table = page_address(kvm_svm->avic_physical_id_table_page); - - return &avic_physical_id_table[index]; -} - static int avic_init_backing_page(struct kvm_vcpu *vcpu) { - u64 *entry, new_entry; - int id = vcpu->vcpu_id; + struct kvm_svm *kvm_svm = to_kvm_svm(vcpu->kvm); struct vcpu_svm *svm = to_svm(vcpu); + u32 id = vcpu->vcpu_id; + u64 *table, new_entry; /* * Inhibit AVIC if the vCPU ID is bigger than what is supported by AVIC @@ -291,6 +277,9 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu) return 0; } + BUILD_BUG_ON((AVIC_MAX_PHYSICAL_ID + 1) * sizeof(*table) > PAGE_SIZE || + (X2AVIC_MAX_PHYSICAL_ID + 1) * sizeof(*table) > PAGE_SIZE); + if (WARN_ON_ONCE(!vcpu->arch.apic->regs)) return -EINVAL; @@ -309,9 +298,7 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu) } /* Setting AVIC backing page address in the phy APIC ID table */ - entry = avic_get_physical_id_entry(vcpu, id); - if (!entry) - return -EINVAL; + table = page_address(kvm_svm->avic_physical_id_table_page); /* Note, fls64() returns the bit position, +1. */ BUILD_BUG_ON(__PHYSICAL_MASK_SHIFT > @@ -319,9 +306,9 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu) new_entry = avic_get_backing_page_address(svm) | AVIC_PHYSICAL_ID_ENTRY_VALID_MASK; - WRITE_ONCE(*entry, new_entry); + WRITE_ONCE(table[id], new_entry); - svm->avic_physical_id_cache = entry; + svm->avic_physical_id_cache = &table[id]; return 0; } @@ -1004,6 +991,9 @@ void avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu) if (WARN_ON(h_physical_id & ~AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK)) return; + if (WARN_ON_ONCE(!svm->avic_physical_id_cache)) + return; + /* * No need to update anything if the vCPU is blocking, i.e. if the vCPU * is being scheduled in after being preempted. The CPU entries in the @@ -1044,6 +1034,9 @@ void avic_vcpu_put(struct kvm_vcpu *vcpu) lockdep_assert_preemption_disabled(); + if (WARN_ON_ONCE(!svm->avic_physical_id_cache)) + return; + /* * Note, reading the Physical ID entry outside of ir_list_lock is safe * as only the pCPU that has loaded (or is loading) the vCPU is allowed -- 2.50.0.rc1.591.g9c95f17f64-goog