From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 C28362264AA for ; Tue, 30 Dec 2025 22:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767135594; cv=none; b=nTVxiMaeNs+/W22nlfXovJuzc/lchr/raXOevLDo7Mne8yph6AogFZwDUygXknKh2g5DbOB0gkgUCpKbGqvz19aSWPjoW9cV3NuWwo26tGZggDdkVaf2kmcS/kW8f5jrgH6M/y/Hg7Yklobqa5Xq/1rBBuhBX/R87WkIXEDYFNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767135594; c=relaxed/simple; bh=yojfISBOIFSpXcr5+NNlskwwpGIiPkNElaXPFYmcfyY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Mu49PU12+k+gPooKHGb33gpSoZasdN3lkCO/ll46zK1kLinOwaBp+lU6oLbmY9EqzAPCMX9wwLJmYkFTuXxmx54uJA5GsDz+nmtdTtx5G+htzvRnqrl6Y+3s2yspKA+76pGmbJAlHd4t+Fli6G3zih51KvNdpOAf+is6XIuUR7Q= 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=CZPpEYXt; arc=none smtp.client-ip=209.85.214.202 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="CZPpEYXt" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2a0a8c465c1so70517945ad.1 for ; Tue, 30 Dec 2025 14:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1767135592; x=1767740392; 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=fBDadXmXw1V+5U8Oi2GEcCZPNX2euffTMHG2vLf3Jyo=; b=CZPpEYXtsSAbVkqKnkI93Vesh904zYR8pN4Z6Yg3Hz5vj+1j7Ucva+kg803cnpnwIr AiJRoW04GLOZaGIHFFsK1eqSskJlkYR3730eXEYOv/fOUd/nHHpS8Xi2XAgCgs6zlrj0 PKt/5iqTVG3HzoBd7ylf4Q6lyuLJwRrNKHovF4VAFUgrBNhi6cKOuxP9zsMv0KBrWC4n PPsjihUzTlBQNrj6iOpMbeG3cRp178f09hAzRpyEaLJ2sqjP3gfmfhGEjy/n3KkWW/dr IJKkO9+WNSk4QmMSjavgqDK1cHbG7Vh6ASIQestF4rGf0euS3DMNqeqjO/7HfE4n1AmF wnZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767135592; x=1767740392; 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=fBDadXmXw1V+5U8Oi2GEcCZPNX2euffTMHG2vLf3Jyo=; b=itm5HDluIAqawC0xxP5S6hAW2ZZYTEmt/CcN8uZJ+W0sSyMuTzqfuXX6RTUY8NQ2mT HkhXFGSH/1uyUOsc8txocnPwYI49vg601b8FXSn7E9Qg5+VntacXuMVLC0Lrr0bsRndJ FJPz0ahd/Y0lByfY83uXd1ksS/Flhe9e7Tac/R1cG1EfRSjZiYvqIpI4muTUTWFR9T8m rHfvUr4mw3ybM3uxazADWV70j5FDgWEey84Un56PZ59DTPLVYhI7hjqlv4zvMLvDPNuR A7KQum5l9tfauglksW/2KKJh8uH1PMqL7rI3BWxWgItCScKu4gal+E3JtZEL2SS3tUau TFNg== X-Forwarded-Encrypted: i=1; AJvYcCWjpV6zZhmxTmKYzEpnhwxI+4ZIbRbHVJmv5GkldUuDlqH+5cn96XxEs8vf/sAwGuvDRzL+0jpnxSvwl/Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yxmu1fPGlMmlNqEgoTpawB57xQFza8Y3yyzjDHaHXce0+/IG32k VslkfARXPjxAGRmlGVeAC3PV22Ydz3hanaYnzBuf2JJ1iHiGf5OG9pXkr0y0a1pT0SnWvL0bYqm W60nXvA== X-Google-Smtp-Source: AGHT+IFeD+h6n1YidrAbsE5HiAota6bVKAwW35UPDKlcY0mTqb6cSWAiLyOFKPv8tt+wNUg2L4+hFSIa5lY= X-Received: from pjzz4.prod.google.com ([2002:a17:90b:58e4:b0:34a:b8aa:69d8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:d48e:b0:29e:fc06:b8a5 with SMTP id d9443c01a7336-2a2cab16368mr405899135ad.18.1767135591960; Tue, 30 Dec 2025 14:59:51 -0800 (PST) Date: Tue, 30 Dec 2025 14:59:50 -0800 In-Reply-To: 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> <6939242dcfff1_20cb5100c3@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: Xu Yilun Cc: dan.j.williams@intel.com, 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 Wed, Dec 24, 2025, Xu Yilun wrote: > On Wed, Dec 10, 2025 at 06:20:17AM -0800, Sean Christopherson wrote: > > On Wed, Dec 10, 2025, dan.j.williams@intel.com wrote: > > > Sean Christopherson wrote: > > > > On Sat, Dec 06, 2025, dan.j.williams@intel.com wrote: > > > > 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 > > > > > > ...but INTEL_TDX_HOST, it turns out, does not have any functional > > > dependencies on KVM_INTEL. At least, not since I last checked. Yes, it > > > would be silly and result in dead code today to do a build with: > > > > > > CONFIG_INTEL_TDX_HOST=y > > > CONFIG_KVM_INTEL=n > > > > > > However, when the TDX Connect support arrives you could have: > > > > > > CONFIG_INTEL_TDX_HOST=y > > > CONFIG_KVM_INTEL=n > > > CONFIG_TDX_HOST_SERVICES=y > > > > > > Where "TDX Host Services" is a driver for PCIe Link Encryption and TDX > > > Module update. Whether such configuration freedom has any practical > > > value is a separate question. > > > > > > I am ok if the answer is, "wait until someone shows up who really wants > > > PCIe Link Encryption without KVM". > > > > Ya, that's my answer. At the very least, wait until TDX_HOST_SERVICES comes > > along. > > I've tested the PCIe Link Encryption without KVM, with the kernel > config: > > CONFIG_INTEL_TDX_HOST=y > CONFIG_KVM_INTEL=n > CONFIG_TDX_HOST_SERVICES=y > > and > > --- /dev/null > +++ b/drivers/virt/coco/tdx-host/Kconfig > @@ -0,0 +1,10 @@ > +config TDX_HOST_SERVICES > + tristate "TDX Host Services Driver" > + depends on INTEL_TDX_HOST > + default m > > Finally I enabled the combination successfully with a patch below, do we > need the change when TDX_HOST_SERVICES comes? Ya, we'll need something along those lines. What exactly we want the Kconfig soup to look like is TBD though, e.g. it may or may not make sense to have a common config that says "I want virtualization!"?