From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.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 7E8B21C9B6F for ; Thu, 31 Oct 2024 20:22:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730406161; cv=none; b=Hu02t28p91zVNxtsfp7UzNZINdwgWKd+9r/8+Zs+G+uirLy0LkChA5701WNG5lb6to8Pfd+Bat6AeAJa1gkEKsRLj1+S0vVDOu04LPlArjSHohiax0rriEzEXT8pyBKODJY5cdbl1Nx9lLAF6Y3wCA3dvBLPRQNPrtlj2+pceEw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730406161; c=relaxed/simple; bh=0m0Sx0hef3cQHUhmb323kP1v6my3krL3Tt1ub0MAh6k=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=CxdMN3P32bRoMigwG4fVDInYzDyCP7auZH9w1ouljKoDa7heAL75DaI2LcaaraHvvOv8bBM+ZPFk92zgyEjpmW5ASAqZo9xD6Sj2svtHg62q2GWCiTiw7LMac9oLKeVPbpzqQDTv5SDLm7EKftVAF+H4CzGKg4n0kWH33RJjEKY= 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=YCuAAVdH; arc=none smtp.client-ip=209.85.128.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="YCuAAVdH" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-6e7e0093018so26429167b3.3 for ; Thu, 31 Oct 2024 13:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1730406158; x=1731010958; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=/SodepQoLygHqd2aIldey6b/axW8k35n8oLJSW1lWCE=; b=YCuAAVdHLCquoG9tYFMy4eQgR38kRF5icus3fJdo47jZbcoG1bsLGJmkOmaSU0Ae/+ fmHKJ1GqefQJFrNuhR/9GAuf/e3Sq9V3sTSBvnbgkU5Lrk0p3phCryArIAdXQQAYywRT ry0bb+qECq7Z62gW4sP9NtK8JFYCOTHviimR8xu/HNaYIkeQcdkgmpMR2YJs6uPbnl7U UPWrHH7GFvhtLPLtGzgFI3TnlbnT8D/1seORNXsW9jYQQTOgTC3DjKcfa7Ep7uKA0GZY Ul4FD/lUUmc/z8fk3/7TVefIgXQvz2hvM5O64eUzZlHZE1TS6PhXkZ7gd+uMlhOaHbKT S5UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730406158; x=1731010958; h=content-transfer-encoding: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=/SodepQoLygHqd2aIldey6b/axW8k35n8oLJSW1lWCE=; b=vr8hFvTLWw4YYUNxZRdTV4KtOJwnbdRKzEq5ypNGeVJdxO8riPbD/e5IL+CIRVhROQ 6qCnC6ZIXvcVztM6/6zE8jnr6IZ8G4amkJWivsTdHFCKRx/duf+yKEmJYYdCowgWQPLu DwufLLWqLY6fHEFUZsvhOPc3lk45JiJRajY5GG81yAw9zA59Z8bXwfSUS0BnKVnU7FyM WvJDEJGB1cyAyq9IqCQuJ68QVb0xYoy+s9rNoZfs4alZB5aaLA7m0QtRK/z3A7qYzjmI BC81iaH0vlxBzQ98LA1QP/sXTxLpZ8o/FqNO7osJa8B4Qr6MkXjauNzmEFpXz88leF+S EAbA== X-Forwarded-Encrypted: i=1; AJvYcCXHOSWTXpW/S7le8wmbIt3UxEPcs97bWZ9nYBHP2gHwX4PT/NzEb12ipyhnClgBrRlUJM0=@vger.kernel.org X-Gm-Message-State: AOJu0YxyQnKIgK5cqxMPfW1bAxCvnm88KYFmm5D6860/ChZO8zCnOMVe R78NRND+ZUwTX3ksi1H6nMbuAHkqnvol5qnqAPZ7+i6q9YPBgwdPqYksa6rM6rWpmWd6rJ2H9EO 6Fw== X-Google-Smtp-Source: AGHT+IGagymATZ1f8HFi1REGMYbBEYlBwt4gqBQox/2m1F48NnAk7T3TDIO03eVpTTcrSv+78KNe61QhODc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a25:3611:0:b0:e30:d518:30f2 with SMTP id 3f1490d57ef6-e30e5a04ademr2512276.1.1730406157307; Thu, 31 Oct 2024 13:22:37 -0700 (PDT) Date: Thu, 31 Oct 2024 13:22:35 -0700 In-Reply-To: <46ea74bcd8eebe241a143e9280c65ca33cb8dcce.camel@intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <46ea74bcd8eebe241a143e9280c65ca33cb8dcce.camel@intel.com> Message-ID: Subject: Re: [PATCH 3/3] KVM: VMX: Initialize TDX during KVM module load From: Sean Christopherson To: Kai Huang Cc: Dan J Williams , Dave Hansen , Tony Lindgren , Rick P Edgecombe , "binbin.wu@linux.intel.com" , Reinette Chatre , Xiaoyao Li , Yan Y Zhao , Adrian Hunter , "kvm@vger.kernel.org" , "pbonzini@redhat.com" , Isaku Yamahata , "linux-kernel@vger.kernel.org" , "kristen@linux.intel.com" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 31, 2024, Kai Huang wrote: > On Wed, 2024-10-30 at 08:19 -0700, Sean Christopherson wrote: > > > +void __init tdx_bringup(void) > > > +{ > > > + enable_tdx =3D enable_tdx && !__tdx_bringup(); > >=20 > > Ah. I don't love this approach because it mixes "failure" due to an un= supported > > configuration, with failure due to unexpected issues. E.g. if enabling= virtualization > > fails, loading KVM-the-module absolutely should fail too, not simply di= sable TDX. >=20 > Thanks for the comments. >=20 > I see your point. However for "enabling virtualization failure" kvm_init= () will > also try to do (default behaviour), so if it fails it will result in modu= le > loading failure eventually. =C2=A0So while I guess it would be slightly b= etter to > make module loading fail if "enabling virtualization fails" in TDX, it is= a nit > issue to me. >=20 > I think "enabling virtualization failure" is the only "unexpected issue" = that > should result in module loading failure. For any other TDX-specific > initialization failure (e.g., any memory allocation in future patches) it= 's > better to only disable TDX. I disagree. The platform owner wants TDX to be enabled, KVM shouldn't sile= ntly disable TDX because of a transient, unrelated failure. If TDX _can't_ be supported, e.g. because EPT or MMIO SPTE caching was expl= icitly disable, then that's different. And that's the general pattern throughout = KVM. If a requested feature isn't supported, then KVM continues on updates the m= odule param accordingly. But if something outright fails during setup, KVM abort= s the entire sequence. > So I can change to "make loading KVM-the-module fail if enabling virtuali= zation > fails in TDX", but I want to confirm this is what you want? I would prefer the logic to be: reject loading kvm-intel.ko if an operation= that would normally succeed, fails.