From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 9FBBD1A724C for ; Tue, 9 Dec 2025 20:01:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765310509; cv=none; b=te7TM0WZ5Oj0gZa+1925Rkvtdu4EkFhHT51tnmtu0m2jRfyILL86rd2cnlA3UCOjL0zb6ULQLGZuu4JH9joJ1sH7kuLFLO/1LuOpOp+z8WtegcjoQhqoOam96t227M1Wp740JRofPN8pw+qFr6mifRVQuyOSH5RggJqBwKUjJUo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765310509; c=relaxed/simple; bh=Qxi1j/RcHKxFAzWkNO39rmWa1j/5Kyprr7BXnY/6Tzg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=jHGkoulHgL6GpQkPawGlHVEnHfeb2q27yPAEPaVE92xjVBlgXyDV6MIcpnxnIn8+2mq0YVW8NJzZT+jYraY0U+obGhKRyJtkMXBSDIeoJoC4guq1NvyE27BqzjOJWc/j7Wwvj7qpXan+orAPE6saV8Rs2bl6rzQIezqLvxujMSU= 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=2pa3XLVr; arc=none smtp.client-ip=209.85.216.74 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="2pa3XLVr" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-349aadb8ab9so6644105a91.3 for ; Tue, 09 Dec 2025 12:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1765310506; x=1765915306; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=oAzgke8OztFL10s6gpyKViwU0Rh1AgMRSlbFbta1tHI=; b=2pa3XLVrSc4rvWJpk/uaf1/Ab8W5uMEPVfcUah8RECiVGEmZrgxUUpl9arwtAmv1oo Ocuw5BvGMCwFSEWMXbTtOGxCKlZlkczjJajPSpHFFQaUdfY9fNTx1CtP2w5+b482xLu2 9FAy8W3Wp1EyTzdqhLaXqMR7YcxqOcqSEHhxsuQ8rzpWcvUftPL1yqK9vchU1SvzY3G9 O1Mtp04Fkgxx4F9JfHITUnnIv3imyva5wZ7i882m88+8FlLcRQ7dcvN0rpXaMqoZUe+n /Gkgid8QdSZP0jnv5d7BXUBJHnYK9eyxXbBuW6QipjEvl6mxdzjbAAtKUcIsgjUGf89m et7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765310506; x=1765915306; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oAzgke8OztFL10s6gpyKViwU0Rh1AgMRSlbFbta1tHI=; b=s5fpuk929c+Ew+BuyOIfMpzLIwI0ld4zfS2Hk76ByeiUMfbwKUqacOqNIUUkMAsxu5 7kmsnY+2LcFkeuccrlVYafGGZ2IPta620I2I2NziO/fv6zbylTcHy1BLPmxMgsXz281l 8jGL8KDO6FT06TWbKbKGf/tEj/7dO2LjTfuoVx6oD8fKXndeQoZ+VkzIlINWbkhCjmWB 8WNts/8V2LUOzt0WqCFkA3ZLvVeFHdhAyFyulMPoM6iLh5Vf2ofPhqLn55725AUkg5ob asB1IfAuPpHmispdOJFbdkaNvuxN1CNJ1qdouvMBt1rGwLhs4URBQ/PAxsg7+54qk6oq /z8A== X-Forwarded-Encrypted: i=1; AJvYcCX/Qzh1zHo8Q0YkyN2303+Wvsixm3liNDKXpUCN8fyvE+9BbXRZ1o9jI/VQTsJOo6Ze49wr9/UWuNoiW4I=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6TAT1JOsOIx7qJmAqgZSN5wHjJ0pt2zGH2femPOtUGyI9YJW5 IQyQPG9pwod8YQanNboOPdgcVZAKLkHSxJay8EbZ6Nm1+B/bBaIJYfJkbTK+6YdwEhn1rPMO4HJ JUeOrxw== X-Google-Smtp-Source: AGHT+IHJ5+IunYdkLmIlmxzrML57BpWM+OKCGDR1imNOGZGgDjiyH1eeQy1f5I13znoJ9RsrIHFYxpfirkY= X-Received: from pjup12.prod.google.com ([2002:a17:90a:d30c:b0:349:a1a3:75f8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5905:b0:341:761c:3330 with SMTP id 98e67ed59e1d1-349a25bd8e0mr10531817a91.23.1765310505789; Tue, 09 Dec 2025 12:01:45 -0800 (PST) Date: Tue, 9 Dec 2025 12:01:44 -0800 In-Reply-To: <69352b2239a33_1b2e100d2@dwillia2-mobl4.notmuch> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251206011054.494190-1-seanjc@google.com> <20251206011054.494190-3-seanjc@google.com> <69352b2239a33_1b2e100d2@dwillia2-mobl4.notmuch> Message-ID: Subject: Re: [PATCH v2 2/7] KVM: x86: Extract VMXON and EFER.SVME enablement to kernel From: Sean Christopherson To: dan.j.williams@intel.com Cc: 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, Chao Gao Content-Type: text/plain; charset="us-ascii" On Sat, Dec 06, 2025, dan.j.williams@intel.com wrote: > Sean Christopherson wrote: > > @@ -694,9 +696,6 @@ static void drop_user_return_notifiers(void) > > kvm_on_user_return(&msrs->urn); > > } > > > > -__visible bool kvm_rebooting; > > -EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_rebooting); > > ...a short stay for this symbol in kvm/x86.c? It raises my curiosity why > patch1 is separate. Because it affects non-x86 architectures. It should be a complete nop, but I wanted to isolate what I could. > Patch1 looked like the start of a series of incremental conversions, patch2 > is a combo move. I am ok either way, just questioning consistency. I.e. if > combo move then patch1 folds in here, if incremental, perhaps split out other > combo conversions like emergency_disable_virtualization_cpu()? The aspect of > "this got moved twice in the same patchset" is what poked me. Yeah, I got lazy to a large extent. I'm not super optimistic that we won't end up with one big "move all this stuff" patch, but I agree it doesn't need to be _this_ big. > [..] > > diff --git a/arch/x86/virt/hw.c b/arch/x86/virt/hw.c > > new file mode 100644 > > index 000000000000..986e780cf438 > > --- /dev/null > > +++ b/arch/x86/virt/hw.c > > @@ -0,0 +1,340 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > + > > +static int x86_virt_feature __ro_after_init; > > + > > +__visible bool virt_rebooting; > > +EXPORT_SYMBOL_GPL(virt_rebooting); > > + > > +static DEFINE_PER_CPU(int, virtualization_nr_users); > > + > > +static cpu_emergency_virt_cb __rcu *kvm_emergency_callback; > > Hmm, why kvm_ and not virt_? I was trying to capture that this callback can _only_ be used by KVM, because KVM is the only in-tree hypervisor. That's also why the exports are only for KVM (and will use EXPORT_SYMBOL_FOR_KVM() when I post the next version). > [..] > > +#if IS_ENABLED(CONFIG_KVM_INTEL) > > +static DEFINE_PER_CPU(struct vmcs *, root_vmcs); > > Perhaps introduce a CONFIG_INTEL_VMX for this? For example, KVM need not > be enabled if all one wants to do is use TDX to setup PCIe Link > Encryption. ...or were you expecting? > > #if IS_ENABLED(CONFIG_KVM_INTEL) || IS_ENABLED(......) I don't think we need anything at this time. INTEL_TDX_HOST depends on KVM_INTEL, and so without a user that needs VMXON without KVM_INTEL, I think we're good as-is. config INTEL_TDX_HOST bool "Intel Trust Domain Extensions (TDX) host support" depends on CPU_SUP_INTEL depends on X86_64 depends on KVM_INTEL