Message ID | 20240227232100.478238-11-pbonzini@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-84196-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp3024396dyb; Tue, 27 Feb 2024 15:27:24 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXUnWjj4DNTNHybFOZycg9TL9PX5pkdbJq7pTCQi8TU+zsRiOzzJ+qLa5oQ57lBAGA6VVJw9OFDFnTR8nruN1K1789YNg== X-Google-Smtp-Source: AGHT+IHNHBGl653DcY3r8CjCL245IyQQQcuDy2dWxnJL+ujjStJTWJ3PEI3YiFOoFt1m+xToYcUm X-Received: by 2002:a05:6402:6cd:b0:566:414d:d70a with SMTP id n13-20020a05640206cd00b00566414dd70amr2299196edy.23.1709076444061; Tue, 27 Feb 2024 15:27:24 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709076444; cv=pass; d=google.com; s=arc-20160816; b=Z7OXWKDcjG0CazwEXQS/D5A5RWU8b86MSHpMTnhNDtpqd+jgcgLxb/iqBcdK3VT7nk aA5YFf7p05b5V4gVQ5NvG5m7q4+Xw3GHSBYzQjDCEu+Dsb0E4UMaiuxcb23PErymvOws GAOwKxBMb/wKkdhi1BNJVoyeA3BhbOGFvGvABzudjsbH51P3kDKSkvHtE906oTj/MGqT VwDH8iriGU+IkRQyWWD6u92qG8UqE7O83cnW7zqEQjaRgSKsYJe8AsXp3fjcUvjwhdnj CvCsYHJAKCpjy/ED1VwxPWgIVuUj3toIsU1wvyZOPYT5r4hMn56LyUpTvsM7lJn6yt82 1V9Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=yP7FPgxDoOexDyh5Qexk3wyBa3Ras1Oco07sQANBHZ8=; fh=3q3ODN5S8qdKV1kx920KZQ8vu87BOqd5z6jBVQXuZu0=; b=uweHR+va11crddDUE+3Wyk4mOJdFX2M83IIEKyhSZdt6Wb64wDiZ+6nej7aq1RMfMV qD9CxCtyvJ4cjwrhGegv0yan+FSC4O7fK/ri1q/00yITKIN+hRlyfdOA3ajqap/wu3VB EuIKabZvLb37aq/gHMd2IJkuZIMcnoxicdlfd/0HcC3anbEp48xmtFgf/oP13G9wqBd5 NF6DJsg7nh/7dzwud/aKHZm1TUAQrH7muvfYI4KCa/CvbYEwLh3ncNOsYqdcYztUtT/k debiMVCcJjzD4MFlFnvLP6uBQ4RwUe55grj9Wf8yeYusVnPNOhhoOp0Y27TEgXkIWQoO OYMg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EI77K5qT; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-84196-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-84196-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id g18-20020a0564021ed200b005663e101632si926321edg.436.2024.02.27.15.27.23 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 15:27:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-84196-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EI77K5qT; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-84196-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-84196-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id A32821F22D00 for <ouuuleilei@gmail.com>; Tue, 27 Feb 2024 23:27:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 777A65EE84; Tue, 27 Feb 2024 23:21:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="EI77K5qT" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 4B0765730D for <linux-kernel@vger.kernel.org>; Tue, 27 Feb 2024 23:21:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709076070; cv=none; b=gfta8FVBU7BWHWjxClNQie0rBWpNPgT4BC1BlezUY3mJehb+5uXsMZVRNA0UjJKA4U0MUWX3Z5lrc+xz9L4D14Jd7YIxeChkEvNyUKUAhqqs4VbBBNt5es5dHk70K6fK7NFjKxcC0pYvCzW5MyPVMfLjy8YYZUKs6sAzJPSO+p0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709076070; c=relaxed/simple; bh=Xq5uW8rV6TjUmWfHQZGYhVIIKq7qjLsZpre/vZqpxPE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=SV0DInOIdw7J2hpFhOeVvBzSwepN84B0W9STw73jIP6AxiKfzsuFRhr8ngsYOm/dLZE/DV+hOZwsoWYs/feevXDpR1GpQiI4IvVZV5cGzHQhqDLTckArLwR9X6oUTzRWriQCRTZUkl2rw1Gwn7m22rSxXK0ZPGJNLMaP1R/zeJ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=EI77K5qT; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709076067; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yP7FPgxDoOexDyh5Qexk3wyBa3Ras1Oco07sQANBHZ8=; b=EI77K5qTX/gjlepU0gG1dXINjOycFYVLmDW7e+7nuEMZoQFnoR/RyYO48SnkP+6pTrCyKQ lKMaEA0B8NyZW/sB93aVJ1IbPLJHb3pRrupbi/l8QcfNXsTwi+KgF8exNYvY2u/PauxPYb k9sL4TEZoy7MVABOTiqQFzWEOFe3OEY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-622-Kcs_drJBNwKwcbEvDnCKLA-1; Tue, 27 Feb 2024 18:21:03 -0500 X-MC-Unique: Kcs_drJBNwKwcbEvDnCKLA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 50E2F185A783; Tue, 27 Feb 2024 23:21:03 +0000 (UTC) Received: from virtlab511.virt.lab.eng.bos.redhat.com (virtlab511.virt.lab.eng.bos.redhat.com [10.19.152.198]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1F102C040F7; Tue, 27 Feb 2024 23:21:03 +0000 (UTC) From: Paolo Bonzini <pbonzini@redhat.com> To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com, isaku.yamahata@intel.com, thomas.lendacky@amd.com, Ashish Kalra <ashish.kalra@amd.com> Subject: [PATCH 10/21] KVM: SEV: Use a VMSA physical address variable for populating VMCB Date: Tue, 27 Feb 2024 18:20:49 -0500 Message-Id: <20240227232100.478238-11-pbonzini@redhat.com> In-Reply-To: <20240227232100.478238-1-pbonzini@redhat.com> References: <20240227232100.478238-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792096541016087054 X-GMAIL-MSGID: 1792096541016087054 |
Series |
TDX/SNP part 1 of n, for 6.9
|
|
Commit Message
Paolo Bonzini
Feb. 27, 2024, 11:20 p.m. UTC
From: Tom Lendacky <thomas.lendacky@amd.com> In preparation to support SEV-SNP AP Creation, use a variable that holds the VMSA physical address rather than converting the virtual address. This will allow SEV-SNP AP Creation to set the new physical address that will be used should the vCPU reset path be taken. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Message-Id: <20231230172351.574091-26-michael.roth@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- arch/x86/kvm/svm/sev.c | 3 +-- arch/x86/kvm/svm/svm.c | 9 ++++++++- arch/x86/kvm/svm/svm.h | 1 + 3 files changed, 10 insertions(+), 3 deletions(-)
Comments
On Tue, Feb 27, 2024, Paolo Bonzini wrote: > From: Tom Lendacky <thomas.lendacky@amd.com> > > In preparation to support SEV-SNP AP Creation, use a variable that holds > the VMSA physical address rather than converting the virtual address. > This will allow SEV-SNP AP Creation to set the new physical address that > will be used should the vCPU reset path be taken. No, this patch belongs in the SNP series. The hanlding of vmsa_pa is broken (KVM leaks the page set by the guest; I need to follow-up in the SNP series). On top of that, I detest duplicat variables, and I don't like that KVM keeps its original VMSA (kernel allocation) after the guest creates its own. I can't possibly imagine why this needs to be pulled in early. There's no way TDX needs this, and while this patch is _small_, the functional change it leads to is not.
On Wed, Feb 28, 2024 at 3:00 AM Sean Christopherson <seanjc@google.com> wrote: > > On Tue, Feb 27, 2024, Paolo Bonzini wrote: > > From: Tom Lendacky <thomas.lendacky@amd.com> > > > > In preparation to support SEV-SNP AP Creation, use a variable that holds > > the VMSA physical address rather than converting the virtual address. > > This will allow SEV-SNP AP Creation to set the new physical address that > > will be used should the vCPU reset path be taken. > > No, this patch belongs in the SNP series. The hanlding of vmsa_pa is broken > (KVM leaks the page set by the guest; I need to follow-up in the SNP series). > On top of that, I detest duplicat variables, and I don't like that KVM keeps its > original VMSA (kernel allocation) after the guest creates its own. > > I can't possibly imagine why this needs to be pulled in early. There's no way > TDX needs this, and while this patch is _small_, the functional change it leads > to is not. Well, the point of this series (and there will be more if you agree) is exactly to ask "why not" in a way that is more manageable than through the huge TDX and SNP series. My reading of the above is that you believe this is small enough that it can even be merged with "KVM: SEV: Support SEV-SNP AP Creation NAE event" (with fixes), which I don't disagree with. Otherwise, if the approach was good there's no reason _not_ to get it in early. It's just a refactoring. Talking in general: I think I agree about keeping the gmem parts in a kvm-coco-queue branch (and in the meanwhile involving the mm people if mm/filemap.c changes are needed). #VE too, probably, but what I _really_ want to avoid is that these series (the plural is not a typo) become a new bottleneck for everybody. Basically these are meant to be a "these seem good to go to me, please confirm or deny" between comaintainers more than a real patch posting; having an extra branch is extra protection against screwups but we should be mindful that force pushes are painful for everyone. If you think I'm misguided, please do speak out or feel free to ask me to talk on voice. Paolo
On Wed, Feb 28, 2024, Paolo Bonzini wrote: > On Wed, Feb 28, 2024 at 3:00 AM Sean Christopherson <seanjc@google.com> wrote: > > > > On Tue, Feb 27, 2024, Paolo Bonzini wrote: > > > From: Tom Lendacky <thomas.lendacky@amd.com> > > > > > > In preparation to support SEV-SNP AP Creation, use a variable that holds > > > the VMSA physical address rather than converting the virtual address. > > > This will allow SEV-SNP AP Creation to set the new physical address that > > > will be used should the vCPU reset path be taken. > > > > No, this patch belongs in the SNP series. The hanlding of vmsa_pa is broken > > (KVM leaks the page set by the guest; I need to follow-up in the SNP series). > > On top of that, I detest duplicat variables, and I don't like that KVM keeps its > > original VMSA (kernel allocation) after the guest creates its own. > > > > I can't possibly imagine why this needs to be pulled in early. There's no way > > TDX needs this, and while this patch is _small_, the functional change it leads > > to is not. > > Well, the point of this series (and there will be more if you agree) > is exactly to ask "why not" in a way that is more manageable than > through the huge TDX and SNP series. My reading of the above is that > you believe this is small enough that it can even be merged with "KVM: > SEV: Support SEV-SNP AP Creation NAE event" (with fixes), which I > don't disagree with. Maybe? That wasn't my point. > Otherwise, if the approach was good there's no reason _not_ to get it > in early. It's just a refactoring. It's not really a refactoring though, that's why I'm objecting. If this patch stored _just_ the physical adddress of the VMSA, then I would consider it a refactoring and would have no problem applying it earlier. But this patch adds a second, 100% duplicate field (as of now), and the reason it does so is to allow "svm->sev_es.vmsa" to become disconnected from the "real" VMSA that is used by hardware, which is all kinds of messed up. That's what I meant by "the functional change it leads to is not (small)". > Talking in general: I think I agree about keeping the gmem parts in a > kvm-coco-queue branch (and in the meanwhile involving the mm people if > mm/filemap.c changes are needed). #VE too, probably, but what I > _really_ want to avoid is that these series (the plural is not a typo) > become a new bottleneck for everybody. Basically these are meant to be > a "these seem good to go to me, please confirm or deny" between > comaintainers more than a real patch posting; having an extra branch > is extra protection against screwups but we should be mindful that > force pushes are painful for everyone. Yes, which is largely why I suggested we separate the gmem. I suspect we'll need to force push to fixup gmem things, whereas I'm confident the other prep work won't need to be tweaked once it's fully reviewed. For the other stuff, specifically to avoid creating another bottleneck, my preference is to follow the "normal" rules for posting patches, with slightly relaxed bundling rules. I.e. post multiple, independent series so that they can be reviewed, iterated upon, and applied like any other series. E.g. my objection to this VMSA tracking patch shouldn't get in the way of the MMU changes, the #VE patch shoudln't interfere with the vmx/main.c patch, etc. In other words, throwing everything into a kitchen sink "TDX/SNP prep work" series just creates another (smaller) bottleneck. I am 100% in favor of applying prep patches in advance of the larger SNP and TDX series. That's actually partly why I ended up posting my series that includes the PFERR_PRIVATE_ACCESS patch; I was trying to pull in using PFERR_GUEST_ENC_MASK and some of the other "simple" patches, and the darn thing failed on me.
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index a9e2fcf494a2..2bde1ad6bcfd 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3094,8 +3094,7 @@ static void sev_es_init_vmcb(struct vcpu_svm *svm) * the VMSA will be NULL if this vCPU is the destination for intrahost * migration, and will be copied later. */ - if (svm->sev_es.vmsa) - svm->vmcb->control.vmsa_pa = __pa(svm->sev_es.vmsa); + svm->vmcb->control.vmsa_pa = svm->sev_es.vmsa_pa; /* Can't intercept CR register access, HV can't modify CR registers */ svm_clr_intercept(svm, INTERCEPT_CR0_READ); diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index f4a750426b24..8893975826f1 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -1459,9 +1459,16 @@ static int svm_vcpu_create(struct kvm_vcpu *vcpu) svm->vmcb01.pa = __sme_set(page_to_pfn(vmcb01_page) << PAGE_SHIFT); svm_switch_vmcb(svm, &svm->vmcb01); - if (vmsa_page) + if (vmsa_page) { svm->sev_es.vmsa = page_address(vmsa_page); + /* + * Do not include the encryption mask on the VMSA physical + * address since hardware will access it using the guest key. + */ + svm->sev_es.vmsa_pa = __pa(svm->sev_es.vmsa); + } + svm->guest_state_loaded = false; return 0; diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index 7a921acc534f..1812fd61ea56 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -198,6 +198,7 @@ struct vcpu_sev_es_state { struct ghcb *ghcb; u8 valid_bitmap[16]; struct kvm_host_map ghcb_map; + hpa_t vmsa_pa; bool received_first_sipi; /* SEV-ES scratch area support */