From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.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 5FE8B3D0D1 for ; Mon, 12 Feb 2024 16:27:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707755246; cv=none; b=JI80PleFbrQFykGuPi+r7tT3cuGFrEDctx4yBjIpQ9XOshQjyn7u/QU5YJyHlrQrDeZe/O+VLLJ3OwoScAzIWJYJHJU49aMXTyN7CnpRNiyqoYp1DDUXcgpF/Q6KhaxD/YFcdOLi47Jdg67TAJgWT7quaGUEGKM+uT/BCXo6+m0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707755246; c=relaxed/simple; bh=Ldgz4EaDjAiFoWUe/b915SB6Or4QvlmL0gWc1JCpdjQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ewPIWB70QG0u8SMFvWLy8vWHNB2QqXesLGWlGBdYsPtx7glDs3MMaMqmInhOnoy2nD12yTI1ye0v1WJuV5FWkiJX8iyhrbqsZsnSnh46gk2cETaRyZ20aoG9J1R3DBjK268CMd34aow9cNd+z0bKY7PkxG8ohgPQr+nOOfosL9Q= 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=Gmmi2iWP; arc=none smtp.client-ip=209.85.219.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="Gmmi2iWP" Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-dc64e0fc7c8so4558153276.2 for ; Mon, 12 Feb 2024 08:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707755243; x=1708360043; 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=jEjTcKce0fZYlWVBDi232LEPLK7jT44Dgj/oRcn95IY=; b=Gmmi2iWP1GQsG4+h7FA62dbGSJ6AHUNaTv4tHNTZRkiTq8MyALG1FZQshXAbY8r29N iyJcQrThZUxrUSxsru16GQgAg9fy8NwecT514w8oGzPiSPd5ubzqehXODvO/cHzJ8iYJ 1KHtj0aZHNCLW4yuzwwP2yzJdBlDSMtX1MF06/gCPh58FLrHnt96MVCBLhpDwcQtAsNM OePuw1gspAfO4niOQ8mrTA2l+kJyaQl0tSd+nr7AmgbYfAHhOCbH7NjKJFJcDZNRW/+K kBuy1E97AhNJad6jpTT0qtIaErDmF/os4h7j9p11Z5wFkvIcePSs9SSr3fA3oC2GAT6t L6hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707755243; x=1708360043; 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=jEjTcKce0fZYlWVBDi232LEPLK7jT44Dgj/oRcn95IY=; b=j1LHWTy009GGOGHpqzhtKq30OsLwqQ+sm/nbjlCoLypU32e7MBXh5J/+C1D7kPjTmi 1rmWAEroM1Xq5Tnj4CSPyWzIcBNwT3LYZ7adBOYB52gRapUtYsQFnqlpFe0sLZTQib01 UcwN+Yyz07UpEUvv8fQ7USHXNmTb61P0L7dbp5mwW8N4gB5hoypdHyjiBkmwJ03E1cqh +n8cAJR9pye78kFRuXHItiOLygcRqMAvcdpYJtOp7EepWh8JTbr1UowkWh9bKmVg9Lot BOTC4vZUMfCd0vzSLkSaj5K35U+AfY0xa3VKxkOtGVdOD27IpYHHznDJioAjzHLgPHQs SK/A== X-Gm-Message-State: AOJu0Yz1FDRZ7mpv6YCGcZidXHzPlVh4qONYDxcCWHdHPniqqAi9nR/i xKmeNGhb23iCuPbCqFlY8C5xYubjgVx+mUfd6NSDnpB6rkd8Yx5ejdaMHlZN9Hem5gNn3NdYnWd 6pA== X-Google-Smtp-Source: AGHT+IEsXJBF4/bgLbVzuTLfn0V+5NyBJ3BEiCA1tlOmkNRLRYQ2dckzNx5kcO0b5SJRLl+MJVUD0K6FNQI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:1005:b0:dcb:c2c0:b319 with SMTP id w5-20020a056902100500b00dcbc2c0b319mr42995ybt.9.1707755243421; Mon, 12 Feb 2024 08:27:23 -0800 (PST) Date: Mon, 12 Feb 2024 08:27:21 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20231230172351.574091-1-michael.roth@amd.com> <20231230172351.574091-10-michael.roth@amd.com> Message-ID: Subject: Re: [PATCH v11 09/35] KVM: x86: Determine shared/private faults based on vm_type From: Sean Christopherson To: Paolo Bonzini Cc: Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, zhi.a.wang@intel.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 12, 2024, Paolo Bonzini wrote: > On Sat, Dec 30, 2023 at 6:24=E2=80=AFPM Michael Roth wrote: > > > > For KVM_X86_SNP_VM, only the PFERR_GUEST_ENC_MASK flag is needed to > > determine with an #NPF is due to a private/shared access by the guest. > > Implement that handling here. Also add handling needed to deal with > > SNP guests which in some cases will make MMIO accesses with the > > encryption bit. > > > > Signed-off-by: Michael Roth > > --- > > arch/x86/kvm/mmu/mmu.c | 12 ++++++++++-- > > arch/x86/kvm/mmu/mmu_internal.h | 20 +++++++++++++++++++- > > 2 files changed, 29 insertions(+), 3 deletions(-) > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > index d3fbfe0686a0..61213f6648a1 100644 > > --- a/arch/x86/kvm/mmu/mmu.c > > +++ b/arch/x86/kvm/mmu/mmu.c > > @@ -4331,6 +4331,7 @@ static int kvm_faultin_pfn_private(struct kvm_vcp= u *vcpu, > > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fa= ult *fault) > > { > > struct kvm_memory_slot *slot =3D fault->slot; > > + bool private_fault =3D fault->is_private; >=20 > I think it's nicer to just make the fault !is_private in > kvm_mmu_do_page_fault(). Yeah. I'm starting to recall more of this discussion. This is one of the = reasons I suggested/requested stuffing the error code to piggy-back the new SNP bit= ; doing so allows is_private to be computed from the get-go without needing any ven= dor specific hooks.