From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.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 38B2469E0E for ; Fri, 9 Feb 2024 14:34:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707489267; cv=none; b=f7SoVE/PAJgb5J9rBzd77bcBCW+DASkbisuY7k6wPUr4258sPLeryFMqFZAGg6fL8l4MD+zgHPoYZgh0BA39nQCF/gfbiURc1byyaiBiu3UfUvgZHzmjzwwg8laW/e9hJ4ELndbR/7PT71s/LxQTSw7bXDzbG9I0RD0SXY09ySE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707489267; c=relaxed/simple; bh=uDVju7ixAiwjpj/e3kzUH3e/2RTTarHMD2S0WTFI0dk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=upRGJpJFrRIOhhE89RtloOLz+jz4w1azB0KZn1+ozwkOPFmnf62+7UEOan+SB8KUzXZJA37bVX1A8gcnS252R/ETv+LYWzjog24v4FjqSLLeB+n3pwUD3QNVS++oAG0rvPeDEK89AhZAfPHwAF74Ko6nMrzfdDrHaiPdwgGHt+k= 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=QZCOzq65; arc=none smtp.client-ip=209.85.219.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="QZCOzq65" Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-dc74800c869so1494941276.2 for ; Fri, 09 Feb 2024 06:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707489265; x=1708094065; 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=ogb4ATBnN2iysVy3kYWYrQJMQNa+6CsJIghREb4Ixj8=; b=QZCOzq65d7/uGinnedezQUDXJJl1AzkbYk3ED5IK26fXDXZZ+HfXPpV6gYM8VdoYzS yRX+asMYTt9pZSOgOR/5vDIkfDnDQ8feUyAdhnP2DkwaFE7W6OC5UDQd4KO9jjwL54Y6 zGcERCZgRG8cpkZMw6aR1MXQoGOchmiCyCcuFlYoH416jCosaXdScnozQUYhv+6PqaJp +yAGhPR6/psevcO4BE8ItwpbBLlsqiweQ7/marJlXycC7Pg229QgcFJ2USy2itRziZ7H X0+0Gz7GD/5rl8rQS8nhlvoaXqNwqm4Buax7yrO1KMnrpf/brMEYpArzrl8HaMCPB8JZ +sjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707489265; x=1708094065; 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=ogb4ATBnN2iysVy3kYWYrQJMQNa+6CsJIghREb4Ixj8=; b=aD+vsTjCxdmBdmH0remX4hkptKYDZxsWB8CkI/8OcyQFRmVIwDeQ/98w3maoAqsS/o f1CtnchCaIWS+H7PEMvT887jdtiTbAHBSEXRqkQgZ6h7bEhxaFV9DdOmRVwSDCDiGcz5 jkbxZ5D5eN64uL1+dlQW/Rq8WRSk/JJPbRV5QzhbzbyXjxcwLDErdXpxjhB7lIEQN4V6 j+nU+BWEpYdgG1l74dfQoiPTS1370t4LypQWaQCElsZGxNh+bf0zzZ/q9CyPdpwz28Ce p2FZo4L5gO/0MMkmua5OqkPywGb7ofdu/ku0Ux/hqYhV3aIuyRc9N9B+TR69Qy5Yb9cQ +IYA== X-Gm-Message-State: AOJu0Yx0bJ4p+0akIQY1es7GOmNlDLbEZy7W0gS90bJyrVnCbH5g3wQy gFnRpX3fTFIHKRtqXhvlYBQnzn/msfzY/vhKqVG8oW5G2TvM2zQVi5I25gAEul3qgzsBPLsFqWn Uig== X-Google-Smtp-Source: AGHT+IH+PMy8iQLYvFKMIvPM5koUGV9QPuYOtUDT8Wfa8+0a+Da1NQZskJ0yqIIdQ/Pd2OKS2Vpp+q0w+PI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:a1e5:0:b0:dc6:e823:9edc with SMTP id a92-20020a25a1e5000000b00dc6e8239edcmr354524ybi.8.1707489265182; Fri, 09 Feb 2024 06:34:25 -0800 (PST) Date: Fri, 9 Feb 2024 06:34:23 -0800 In-Reply-To: <20240209015205.xv66udh6hqz7a6t7@amd.com> 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-19-michael.roth@amd.com> <20240116041457.wver7acnwthjaflr@amd.com> <20240209015205.xv66udh6hqz7a6t7@amd.com> Message-ID: Subject: Re: [PATCH v11 18/35] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command From: Sean Christopherson To: Michael Roth Cc: Paolo Bonzini , 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, Brijesh Singh Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 08, 2024, Michael Roth wrote: > On Wed, Feb 07, 2024 at 12:43:02AM +0100, Paolo Bonzini wrote: > > On Fri, Feb 2, 2024 at 11:55=E2=80=AFPM Sean Christopherson wrote: > > What sanity is being checked for, in other words why are they useful? > > If all you get for breaking the promise is a KVM_BUG_ON, for example, > > that's par for the course. If instead you get an oops, then we have a > > problem. > >=20 > > I may be a bit less draconian than Sean, but the assumptions need to > > be documented and explained because they _are_ going to go away. >=20 > Maybe in this case sanity-check isn't the right word, but for instance > the occurance Sean objected to: >=20 > kvaddr =3D pfn_to_kaddr(pfns[i]); > if (!virt_addr_valid(kvaddr)) { > ... > ret =3D -EINVAL; >=20 > where there are pfn_valid() checks underneath the covers that provide > some assurance this is normal struct-page-backed/kernel-tracked memory > that has a mapping in the directmap we can use here. Dropping that > assumption means we need to create temporary mappings to access the PFN, No, you don't. kvm_vcpu_map() does all of the lifting for you, with the sm= all caveat that it obviously needs a vCPU. But that's trivial to solve with a = minor refactoring, *if* we need to solve that problem (it's not clear to me wheth= er or not the APIs for copying data into guest_memfd will be VM-scoped or vCPU-sc= oped).