From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (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 D5CC03C10BA for ; Tue, 23 Jun 2026 22:02:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782252152; cv=none; b=DMjflm90wz7AHgIczFslZfL2xd2N3P9b0goBu9BAmNTcXv6jD+nq7lr19bSYVMyyyuAlTZeZw1qXrtROnWyRO6we8GRh/hcHqXf7yWIpUOfT934Q7qchI5RHbJrFMDVJxkCxXtxqy1fSY/zmuEu8eooYG88nS4Wqp27IEmJj2+k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782252152; c=relaxed/simple; bh=EcSLeDAkf+NYYlNPbaQDgJqvXTeoGd4kGIS3C758yv8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=gb8nxv/9iRmH9U8EkMNovSfpQRxw6b4zEWwedIuTXYH1oWDQdaSaszPi+FS1xW2HzXVwFnoQL1ZVGiHQlzG0A3YLAxqqWJ+xqGeh7KTrFzyGbnJmPceiI1hHT2kRyHmQm0sg1HT2QOEF3KrV3u51h6hDVUegO1BYrgWa8aG6b4E= 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=kLR1GoJ/; arc=none smtp.client-ip=209.85.210.201 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="kLR1GoJ/" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-8423f424d5bso244672b3a.3 for ; Tue, 23 Jun 2026 15:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782252150; x=1782856950; darn=lists.linux.dev; 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=RRBVZcuKuww3Wq8UWokXWaW99P2Z0kQJ1V7bgh+4dKk=; b=kLR1GoJ/PT6rgLL2wlPJ3I1wFQ58KslkC35E2sw/Zt+SzTD5sLcUWRTT0qfztfjVMg ItsZLbILyHTOFZRcGwXpBsCHN7ctqmL9/nq7J4hM8qFEJY4vs5H5xfh7I6z60Gz7+dg6 KmpBUOhJzErIEVmc63JCaxo+wsTBiMBRWwYsoqkPUnoieCAeLDVbAgPsxx16ntpEtqUK RO2qBxjZoP/SJjkwQDubyAsLXtCW5fBqvs1CHED27pZazQobIvNYsFfzzkEId3DOcY4X Iem5BFWnZIJn3g1uI84lG8i0Efy8nB6O6La/oHYkGYfIibPpgVHMM7uHIWQuxH8CCssu RRrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782252150; x=1782856950; 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=RRBVZcuKuww3Wq8UWokXWaW99P2Z0kQJ1V7bgh+4dKk=; b=USqRhiqTPp8YbSRPnhrdqtzeuHMv3Enp8a4GBC9fMis8SJoOdCQ27AA2NqTcc9XtY8 Lyb5CyP1F0tXo4Exk4qOh4gZtQUUWso9FqoOq81kXd/HBHf2HghDSHdSYJWLVZQm1UoY DW1w5x1YcBUd8s8WHGujduAomw6y8r8Zy8fhRoDudsyV4JG4BXgmqsI4dmFLwXXKDlj3 dtfaWJk9nzeSuKl6MZpmpnIzwfNeMxdXh+r5OuYfSG00TkNK1z7YDj5W/+XmvlP774BH Kw0JofyDmO4EIA65dKYNyDU+8ld8UFiiF0tJXTytsSD2lpqZA/7vXK/+bbm4QyJcqG7F modg== X-Forwarded-Encrypted: i=1; AFNElJ+Cd2JQ2hy8mpBjEH6kvuwZRuxvFUjbd+sgRNjWGY6urhFY8uK8XOqu0CXEpNzYbdg/8UnWD8R6tWkJG8I=@lists.linux.dev X-Gm-Message-State: AOJu0Yyq7Jc50UyJtRwVtZ+A9gg3spnWaUfo2ejGe4xqXMweD2ScQ0Ye 1UoRriGmePtJvAyYaEzGDi8j+ixIKH6eyG0M4mnT0+IZR0bFm58Buq/rggm5fI2WYb4lQyBjQ7y AGEO6Jg== X-Received: from pfod4.prod.google.com ([2002:aa7:8684:0:b0:845:4210:eae4]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1886:b0:842:3d8d:bab5 with SMTP id d2e1a72fcca58-845a27b4293mr1064521b3a.37.1782252149754; Tue, 23 Jun 2026 15:02:29 -0700 (PDT) Date: Tue, 23 Jun 2026 15:02:29 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: coconut-svsm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <0657500d-a8bd-4dec-80a5-807e857a4306@fortanix.com> Message-ID: Subject: Re: [EXTERNAL] Re: [PATCH 4/4] kvm: svm: Support KVM_SEV_SNP_PAGE_TYPE_VMSA at SNP_LAUNCH_UPDATE From: Sean Christopherson To: Jethro Beekman Cc: Jon Lange , "=?utf-8?B?SsO2cmcgUsO2ZGVs?=" , Paolo Bonzini , "x86@kernel.org" , "thomas.lendacky" , Michael Roth , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "coconut-svsm@lists.linux.dev" , Joerg Roedel Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 23, 2026, Jethro Beekman wrote: > On 2026-06-23 23:43, Sean Christopherson wrote: > > On Tue, Jun 23, 2026, Jethro Beekman wrote: > >> On 2026-06-23 16:51, Jon Lange wrote: > >>> On Tuesday, June 23, 2026 6:40 AM, Sean Christopherson wrote: > >>>> On Wed, Jun 17, 2026, J=C3=B6rg R=C3=B6del wrote: > >>>>> On Wed, Jun 17, 2026 at 06:37:52AM -0700, Sean Christopherson wrote= : > >>>>>> Ok, so it took us a few times to learn our lesson. I still don't = see that as a > >>>>>> strong argument for new uAPI, especially not for VMSA pages. I am= very firmly > >>>>>> of the opinion that letting anything but the host kernel configure= the VMSA is > >>>>>> beyond stupid, but unfortunately we're stuck with AP_CREATION. Ex= panding that > >>>>>> surface has a very, very, VERY high bar to get over. > >>>>> > >>>>> The strongest argument in my view (and the main reason we are doing= this) is > >>>>> actually the predictable launch measurement. On SEV-SNP this is a r= equirement > >>>>> to use platform VM-identity features like the ID Block. > >>>> > >>>> And I'm saying that unless KVM *can't* provide a predictable launch = measurement, > >>>> which AIUI isn't the case, then the launch measurement *must* be sta= ble across > >>>> kernels because it's part of KVM's ABI. So as I see it, the issue i= sn't that > >>>> KVM is inherently unpredictable, it's that we lack tests to validate= a thorny, > >>>> subtle piece of KVM's ABI. > >>> > >>> Joerg is suggesting that we need a launch measurement that is stable = not > >>> just across multiple launches on the same system, but across multiple > >>> hypervisors. > >> > >> If this is now suddenly an acceptable argument, please also merge http= s://lkml.org/lkml/2021/4/12/625 > >=20 > > No, that's not how this works. Dave and Jarkko both have unanswered qu= estions > > regarding the use case. Answer their questions, and I'm confident you'= ll get > > traction. > >=20 > > : I don't believe we necessarily *WANT* or need Linux to support "all > > : possible ECREATE, EADD, EEXTEND, EINIT sequences". Yet, it's what i= s > > : being used to justify this series without any other justification. > > :=20 > > : It's going to be a different story if you bring me a real enclave th= at > > : *REALLY* wants to do this for good reasons. > >=20 > > and > >=20 > > : What specifically are you referring as the "rest of the world"? > > :=20 > > : That would be mean that there is reviewable workload "out there". > >=20 > > The start of that thread is *exactly* what's playing out here. The big= difference, > > and why this one's likely getting a different result, is that Jon provi= ded a very > > thorough explanation of exactly what use case Joerg and company want to= support. > > The only "assumed knowledge" is why it's desirable for the measurement = to be stable > > across hypervisors, but I'm comfortable stitching that together on my o= wn. > >=20 > > In other words, they aren't asking KVM to support every possible way/ti= me a VMSA > > could be associated with a vCPU, they're asking to extend KVM to suppor= t a concrete > > use case, with meaningful real world impact. In fact, I actually think= this series > > is *too* narrowly focused on their use case. > >=20 > > FWIW, KVM_TDX_INIT_MEM_REGION has almost the exact same ABI that SGX ha= s: pages > > contents are measured immediately after they're added. >=20 > Sorry, the argument from Jon/Joerg is no different than the one we made y= ears > ago for SGX. >=20 > It was previously made abundantly clear that it's the kernel maintainers'= s > stance that it's sufficient to offer a UAPI that allows the creation of a > Linux-specific subset of enclaves with a stable measurement encompassing > largely the enclave functionality available in the hardware. Or said anot= her > way: if you can take your enclave and modify it to work with Linux, albei= t > with a different measurement, that is acceptable. KVM-SNP is currently at > that state: it is currently completely possible to load VMs that were > designed with the current Linux VMSA in IGVM format. >=20 > A UAPI that allows creation of all architecturally-valid enclaves for > purposes of measurement portability was stated as an explicit non-goal. A= s > this is the only stated purpose of this patch set, it should also not be > accepted. No, the stated goals (thanks to the follow-up from Jon) are to (a) support = VMSA GPAs other than KVM's hardcoded, arbitrary 0xFFFFFFFFF000, and (b) to play = nice with multi-VMPL scenarios in the future. If that happens to let userspace = build every architecturally possible VM, then yay!, we got lucky and probably won= 't ever need to revisit this. But "support every possibility" is not the goal= . Side topic, if someone is going to propose changes for TDX measurements rel= ated to IGVM, now would be a good time to mention them :-)