From nobody Wed Nov 27 19:37:57 2024 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2226A1C2DDC; Tue, 8 Oct 2024 10:45:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728384332; cv=none; b=LZ6KmeON3dUQyP15NsPDDJt0JxYz3dXLbO3qua7GqAzYlMB5A2CkS6VRXCg0mq4TR9SUuHU85l6flhrLi4oiJ4jLGVFIMc5i1v517ez4/yyVpRHcF12LF0UCYwvkiobU+GBIMPQ0FSMJa4SmMNYSq+WG75UF8Fs+gXASi8ufBjg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728384332; c=relaxed/simple; bh=BlSdS3ccmmWiiU5sC/zLNueLcx7CKTtj0OJ929lDtac=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RPf/4b/gf8mMwVlRcpwOzIdT5QaEAQY8WVHkRYcpe1oQJEfi0SYb5ErYIWt6AIQzHnwRRh7hvxuqP65nVRocHxOPkAMlR/nfuzpgiGdTrfm8CBKk6snNGHEx/9VQXbiCRSnj1NBXlkkhxfvFL+nWQxAqn07rW7HLnMqgc3fhSFw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=WjXMRPCw; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="WjXMRPCw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728384331; x=1759920331; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=BlSdS3ccmmWiiU5sC/zLNueLcx7CKTtj0OJ929lDtac=; b=WjXMRPCwPwhBaVRx6tl+cWjYFTu/sinPicYpq1nmsZXv8yDGJmu8pE6X CQw9Mlf8jO8LeMfPJ87OmnQVO+6f+ENkjmib81UO7225tFqL8A4llKA9D C8DgoRcueRcy32PJ5L48E050Nd1Weo3rlKhcCoYafvbljFPcbglGLQmsT OjwCtEoglMhKSw7Wmc1WK28sXwUwGW37XXL3KzPywe9M7xq3OA4kv7M4O LI46pIyzYr67ITJKAV/6pZrgTwQCT8aYLmqX2hUaujxcbOxXof2zKWKO9 1foc56ZblfwF1PrLMqcPP6QOdPm9+Z8h2Xq+94JF44RBGoq56i5G9ztqw w==; X-CSE-ConnectionGUID: hVszYtOzQC+AdtpeGhkzcg== X-CSE-MsgGUID: iJlxImQJRSOfg9fDBygpPg== X-IronPort-AV: E=McAfee;i="6700,10204,11218"; a="45033836" X-IronPort-AV: E=Sophos;i="6.11,186,1725346800"; d="scan'208";a="45033836" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 03:45:29 -0700 X-CSE-ConnectionGUID: JC79l8BkR1a94kzUNvc83g== X-CSE-MsgGUID: C9LCV7qnRpOkRrRbkkgZ1g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,186,1725346800"; d="scan'208";a="76166915" Received: from sramkris-mobl1.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.124.222.88]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 03:45:28 -0700 From: Kai Huang To: pbonzini@redhat.com, seanjc@google.com, kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Kai Huang Subject: [PATCH 1/2] KVM: x86: Fix a comment inside kvm_vcpu_update_apicv() Date: Tue, 8 Oct 2024 23:45:13 +1300 Message-ID: <666e991edf81e1fccfba9466f3fe65965fcba897.1728383775.git.kai.huang@intel.com> X-Mailer: git-send-email 2.46.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The sentence "... so that KVM can the AVIC doorbell to ..." doesn't have a verb. Fix it. After adding the verb 'use', that line exceeds 80 characters. Thus wrap the 'to' to the next line. Signed-off-by: Kai Huang --- arch/x86/kvm/x86.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 83fe0a78146f..afd70c274692 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10576,8 +10576,8 @@ static void kvm_vcpu_update_apicv(struct kvm_vcpu *= vcpu) * deleted if any vCPU has xAPIC virtualization and x2APIC enabled, but * and hardware doesn't support x2APIC virtualization. E.g. some AMD * CPUs support AVIC but not x2APIC. KVM still allows enabling AVIC in - * this case so that KVM can the AVIC doorbell to inject interrupts to - * running vCPUs, but KVM must not create SPTEs for the APIC base as + * this case so that KVM can use the AVIC doorbell to inject interrupts + * to running vCPUs, but KVM must not create SPTEs for the APIC base as * the vCPU would incorrectly be able to access the vAPIC page via MMIO * despite being in x2APIC mode. For simplicity, inhibiting the APIC * access page is sticky. --=20 2.46.0 From nobody Wed Nov 27 19:37:57 2024 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83A741D0496; Tue, 8 Oct 2024 10:45:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728384335; cv=none; b=Gebc35VuXm3JfCo2zueicki0DhYMxUIAVNYTwX6Eqt5u76p1WfHacUfRcilXTs4XpOXGiKzJACpQeJ2ZMusM5e5yQCHFcdS3GfeFN0PsbweJ8CTIRWFNLH1z1Q0FtXR9mnfKZO1RnzDgIn7gXuaP1N2Yz666ncsKPH95WWXzhqw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728384335; c=relaxed/simple; bh=/Wy3bEmK+Z2Csvv6DBysE2rgjF97bye9ch+Y+NPQ9vw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mzD0U6XyT+aDrrs44BWn/4hQ5X6ZG01rS5VE+1qvSGneM33CuwDfmScKfDXCJmUSsvtwulKd35Mx+RCIgAMV7r48iv02yDtDpZVYtHCzEoXHn7W+h/gviKe/4Bntt+vPzD2AUp5B7wlv99gw0BxpHggCN0faPDdQM+Ik5ynn0co= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Jhxig615; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Jhxig615" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728384333; x=1759920333; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/Wy3bEmK+Z2Csvv6DBysE2rgjF97bye9ch+Y+NPQ9vw=; b=Jhxig6155VgLoVHiV3ffcYVcb/b0Hidf0r3dHRkeNA/WGQynCbG2Y/Et 8GM+MA5CYdFCwhKBEiEnjbScY99VtGilO9+D2c3Jvi6d9JmVHmGRtSFs0 fx7ZyrK2GZPlVsJgQHziXrxNd2yeLaDvLV493zLlOFWur2ewtcOf6No08 v+bCDQc2is+lwy6b1zoARgUY/gYXCBl6Rej3OH2OAGXmhuu7lr8Z5FomH pOaVEjCCR1/FL0jyld4O6CIvB0mQH2V3dDgXqMrVgrclucNoCQCnmCwyu iJ8VCTIlyBMIqy+mRIo9WTRQHXc4Kkbq9qJ/RUCaezK5R/RA9l3apHyws Q==; X-CSE-ConnectionGUID: //8ed1ffRfyYemUtHGDcXw== X-CSE-MsgGUID: S7ooEgGTTuK/J5/CRAtZYg== X-IronPort-AV: E=McAfee;i="6700,10204,11218"; a="45033839" X-IronPort-AV: E=Sophos;i="6.11,186,1725346800"; d="scan'208";a="45033839" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 03:45:31 -0700 X-CSE-ConnectionGUID: h4kYvybrTwmALhhG/u1m0A== X-CSE-MsgGUID: jIdiX7nLSFCzVuXbVVVpjA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,186,1725346800"; d="scan'208";a="76166929" Received: from sramkris-mobl1.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.124.222.88]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 03:45:30 -0700 From: Kai Huang To: pbonzini@redhat.com, seanjc@google.com, kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Kai Huang Subject: [PATCH 2/2] KVM: x86: Fix a comment inside __kvm_set_or_clear_apicv_inhibit() Date: Tue, 8 Oct 2024 23:45:14 +1300 Message-ID: X-Mailer: git-send-email 2.46.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Change svm_vcpu_run() to vcpu_enter_guest() in the comment of __kvm_set_or_clear_apicv_inhibit() to make it reflect the fact. When one thread updates VM's APICv state due to updating the APICv inhibit reasons, it kicks off all vCPUs and makes them wait until the new reason has been updated and can be seen by all vCPUs. There was one WARN() to make sure VM's APICv state is consistent with vCPU's APICv state in the svm_vcpu_run(). Commit ee49a8932971 ("KVM: x86: Move SVM's APICv sanity check to common x86") moved that WARN() to x86 common code vcpu_enter_guest() due to the logic is not unique to SVM, and added comments to both __kvm_set_or_clear_apicv_inhibit() and vcpu_enter_guest() to explain this. However, although the comment in __kvm_set_or_clear_apicv_inhibit() mentioned the WARN(), it seems forgot to reflect that the WARN() had been moved to x86 common, i.e., it still mentioned the svm_vcpu_run() but not vcpu_enter_guest(). Fix it. Note after the change the first line that contains vcpu_enter_guest() exceeds 80 characters, but leave it as is to make the diff clean. Fixes: ee49a8932971 ("KVM: x86: Move SVM's APICv sanity check to common x86= ") Signed-off-by: Kai Huang --- arch/x86/kvm/x86.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index afd70c274692..7b347e564d10 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10606,11 +10606,11 @@ void __kvm_set_or_clear_apicv_inhibit(struct kvm = *kvm, if (!!old !=3D !!new) { /* * Kick all vCPUs before setting apicv_inhibit_reasons to avoid - * false positives in the sanity check WARN in svm_vcpu_run(). + * false positives in the sanity check WARN in vcpu_enter_guest(). * This task will wait for all vCPUs to ack the kick IRQ before * updating apicv_inhibit_reasons, and all other vCPUs will * block on acquiring apicv_update_lock so that vCPUs can't - * redo svm_vcpu_run() without seeing the new inhibit state. + * redo vcpu_enter_guest() without seeing the new inhibit state. * * Note, holding apicv_update_lock and taking it in the read * side (handling the request) also prevents other vCPUs from --=20 2.46.0