From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (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 3D8D72FF675 for ; Tue, 27 Jan 2026 02:46:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769482006; cv=none; b=ePZ0CdvkaFOhgPz2Lgyi6nBAENGmD8G/rLMQRocvpuQeUvZmjYh/ciCRE6LLnNBmYQI4+B4eMT7bwikNH7U07UPLTSNY7Ev9+rsIUeTc6iToi6mYFkd0g8gizliuMhYBC0UtSxDXANt4/TnZfNG4rqQgl90VfrfTsWE/yxNEKm0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769482006; c=relaxed/simple; bh=Xzpbra9837QmDLbGjaczE5iqzi40M73MulfuqbJXidU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=a1tE+DLblbk52RemVIzWUzdOHVscAb9+VLxAxa9mRSBEC1jW/xUz1LaOQ9rLdc6FvABgzLWt5cc8rej5npZhHi4o+Nxq5+/2klIh6Bd8M7BgheRxtOwqRJYyGGNZtWk3m/9+fpfz1cGkKOFiuKDxAXrQLWrFEZDPhGFZYbnyr2k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=O6k41cIy; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="O6k41cIy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1769482005; x=1801018005; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Xzpbra9837QmDLbGjaczE5iqzi40M73MulfuqbJXidU=; b=O6k41cIyntRL3SCNroVKSdRyRQj7Zvdqoi5VVwkiTVikAC/z9nLp3ZTE EDe7wBBqAoZfGoVanSWSIP0M1cntDD8EkLdAm3pfILeVT5bjobSZuy+F6 dU2Z/snr2mbuR5QajD/lfwdDdzG6FVeGyRPywtRH0a/hLoIzz1j94xfWa l2b0bROQnIzZ13ZRwnU8uXyIpYoy4jL5fKrwlr/9KXJM9/grwRkUGHxR5 HbD+TJprj39oz78OeVhH/3kdKo9LUM4dm7YO3YgCMw2QCHoSPw3ytQ3xv Feg0cxDIxdPm9kQk85y+TBeypTQCqmHMYRUIN4ZkzjY0wd6oiN7AQRKJC g==; X-CSE-ConnectionGUID: ihyZ+46iQia4oCfap1uqiQ== X-CSE-MsgGUID: Z29phj0xTtOOVIKVCf5RTA== X-IronPort-AV: E=McAfee;i="6800,10657,11683"; a="70561980" X-IronPort-AV: E=Sophos;i="6.21,256,1763452800"; d="scan'208";a="70561980" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2026 18:46:36 -0800 X-CSE-ConnectionGUID: Hwd3ZEaTQOCwNLoyhHOMBg== X-CSE-MsgGUID: e69oU3gfRuGV/1sCtYyR7A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,256,1763452800"; d="scan'208";a="212393572" Received: from unknown (HELO [10.238.1.231]) ([10.238.1.231]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2026 18:46:33 -0800 Message-ID: Date: Tue, 27 Jan 2026 10:46:30 +0800 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/7] KVM: x86: Extract VMXON and EFER.SVME enablement to kernel To: Sean Christopherson , Xu Yilun Cc: Chao Gao , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Kiryl Shutsemau , Paolo Bonzini , linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Dan Williams References: <20251206011054.494190-1-seanjc@google.com> <20251206011054.494190-3-seanjc@google.com> Content-Language: en-US From: Binbin Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/19/2025 11:40 PM, Sean Christopherson wrote: > On Fri, Dec 19, 2025, Xu Yilun wrote: >> On Wed, Dec 17, 2025 at 11:01:59AM -0800, Sean Christopherson wrote: >>> On Wed, Dec 17, 2025, Xu Yilun wrote: >>>> Is it better we explicitly assert the preemption for x86_virt_get_cpu() >>>> rather than embed the check in __this_cpu_inc_return()? We are not just >>>> protecting the racing for the reference counter. We should ensure the >>>> "counter increase + x86_virt_call(get_cpu)" can't be preempted. >>> >>> I don't have a strong preference. Using __this_cpu_inc_return() without any >>> nearby preemption_{enable,disable}() calls makes it quite clears that preemption >>> is expected to be disabled by the caller. But I'm also ok being explicit. >> >> Looking into __this_cpu_inc_return(), it finally calls >> check_preemption_disabled() which doesn't strictly requires preemption. >> It only ensures the context doesn't switch to another CPU. If the caller >> is in cpuhp context, preemption is possible. > > Hmm, right, the cpuhp thread is is_percpu_thread(), and KVM's hooks aren't > considered atomic and so run with IRQs enabled. In practice, it's "fine", because > TDX also exclusively does x86_virt_get_cpu() from cpuhp, i.e. the two users are > mutually exclusive, but relying on that behavior is gross. > Side topic: Isn't the name of check_preemption_disabled() confusing and arguably misleading?