From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1319C3DA78 for ; Tue, 17 Jan 2023 17:19:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AB826B0073; Tue, 17 Jan 2023 12:19:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 85C236B0074; Tue, 17 Jan 2023 12:19:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 723C06B0075; Tue, 17 Jan 2023 12:19:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 61B916B0073 for ; Tue, 17 Jan 2023 12:19:10 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 35C6A1A08B6 for ; Tue, 17 Jan 2023 17:19:10 +0000 (UTC) X-FDA: 80364951660.03.77E20FB Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf12.hostedemail.com (Postfix) with ESMTP id 716F940022 for ; Tue, 17 Jan 2023 17:19:08 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Zmn3vSdz; spf=pass (imf12.hostedemail.com: domain of seanjc@google.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673975948; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=M4+uVVLZLx9S3b5j+KW2LdAGdGkzXPxcqIXMG9Qphu4=; b=Pa3JzAMBRuygqYDn0U9A2uCbZYh6MmPESd+dwl2cCtMSE/JFTP2GaAEERU3p0kTigmN5ax F29rco6WUHBSWctRNkQWRXZabxor3h3QiVtUKMDZR92DiIdg0/lmhVxEV1Asy4M1N72icN /whuKouRwoYfiTN8VISHeqmZGWIDESo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Zmn3vSdz; spf=pass (imf12.hostedemail.com: domain of seanjc@google.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673975948; a=rsa-sha256; cv=none; b=fmODzl7q71+2zSe/HQbiW3vn54+HHceKVsl6nTG/NTZQoxRtK4f+nzQZ1CECMzuKCyIha1 poXuST0X7FrJW8ejcsj62Jwy8U/JlkD1IrKIrJ4p2uqdnH06P4BbKbO7aa36j9Dy/NkAmh iukS6CkE2bMUM49Cz6+Q7ZjeOA83ZdQ= Received: by mail-pj1-f48.google.com with SMTP id y3-20020a17090a390300b00229add7bb36so1724154pjb.4 for ; Tue, 17 Jan 2023 09:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=M4+uVVLZLx9S3b5j+KW2LdAGdGkzXPxcqIXMG9Qphu4=; b=Zmn3vSdzFkudY+uxAJeib6OqefKZoI53M+UVhVxk2WqR2FoAQbJhzqbFjoyLB3qXB9 lHMKsdUruoW6hzOcRIWmshuAOb9h8Y/4UBcZi1pttXgzlfscvTA9tjaah3KbnJGxxBLJ /3QDrtBjDmHfkOVpCl977w9bfXT5XyLiEzbDZ+kWPBRK6u1r9MNoJDdnMj7oT3XfBFtu dAdo+4aGgprK/zoYlyKrdcETQJ8ra6JbFEkwq7ciUPFGyAlZz6/v1YCzxsrjFeXPedhJ /6Dvo50B3sKEMIz7aE9c049Ta9U81C+hcjVUYchXseAfDiIxshTY43AbOe19k47/xzyT QDPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=M4+uVVLZLx9S3b5j+KW2LdAGdGkzXPxcqIXMG9Qphu4=; b=ihkA38PYhMRGJbKgn/GV4VQqBEzk6UKgGM/Pf0FXpe+m94GI4AgSnL0tc2bryas/Hz wqCNK2V4UC3lSkOI4pLHcfzh8AcU9scCUsHSQ+T3PpzogcER2s+S3YH51M4P4dECgSMJ oOHn+n378/wsi0qyJfEVZME0MOVzSpw61vkNgEM9nrwYMQQgEi87WLJNasol6wOP9toM wPdt9thwwFXK72GMkCPcZxovaUAGA2o+whqGwKXz8uLfdKIYsXaqlzpT3CY7m0sWlrO7 HmdsdqDSOKBAElEgc/CK2TwSe3OSatG+gnEuIed4bksOSZy9N021+cbCaxcPjU+YEPal gR1w== X-Gm-Message-State: AFqh2kqDqCMyTKbTwLY60Ah5JPeTW0c8scG1gJl+vgm4Bc8hgYl2GCKG pSrfxrLxu5yx0896LSVQvOxCTg== X-Google-Smtp-Source: AMrXdXuNA5Xq8t9IxmI5BkWk1YUjI2YY7hE8dkqUdf57/E+MmKpR4ttvP/Oqs+rhiKGbfUTmqtB5lQ== X-Received: by 2002:a05:6a20:93a4:b0:b8:e33c:f160 with SMTP id x36-20020a056a2093a400b000b8e33cf160mr89085pzh.0.1673975947148; Tue, 17 Jan 2023 09:19:07 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id im15-20020a170902bb0f00b001943d58268csm15120181plb.55.2023.01.17.09.19.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 09:19:06 -0800 (PST) Date: Tue, 17 Jan 2023 17:19:02 +0000 From: Sean Christopherson To: "Nikunj A. Dadhania" Cc: Borislav Petkov , 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, pbonzini@redhat.com, vkuznets@redhat.com, wanpengli@tencent.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, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com, jarkko@kernel.org, ashish.kalra@amd.com, harald@profian.com Subject: Re: [PATCH RFC v7 07/64] KVM: SEV: Handle KVM_HC_MAP_GPA_RANGE hypercall Message-ID: References: <20221214194056.161492-1-michael.roth@amd.com> <20221214194056.161492-8-michael.roth@amd.com> <460524f8-e52b-e195-3bd2-27e41f367f5d@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460524f8-e52b-e195-3bd2-27e41f367f5d@amd.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 716F940022 X-Rspam-User: X-Stat-Signature: pjg9bgjshgp3irn8tgwc49iiycqi5r5m X-HE-Tag: 1673975948-180293 X-HE-Meta: U2FsdGVkX1//JF7LevHMg9ekm7zlmvc6jYo/m2rnhTnHm2ElxZRDk1UwItoylEvpW/4HeazLWc8UaV+IDRLmfNH70d5v99i859ntu5CvMinWtMA9iniQlJwF4wI7DUZYJ7XxGO2fLIubvki16KxEApLgFKN9N5ZamMdW7gnwWQwcJNYpulopJGtooUfX3r32vRFfo0Ne6dy9hPnvii/CmNbznB8zgSsn/VzvAvpVOFM1lgq8U2FWSbm7MCEb3tTa8xinJNg4u34meYSHwuSGCRgOkPnq5Ba39rBoOSgij46i6ScnMnJaGggcPfbsDlIZwgO+I7J10vfIuWwQHnBGgSxUKTN+LhdB3X1Sz67bvFrVLUR7+Hm+MF7ewojdxOJ+iDMDtf+lkT1U+miyzV0x+LuCBfFWTOSffz4Qs5vKyoZp7LmtU52rOlNnPdRj6EFhuX7psv5pksZUKutnRhEhvPMkSY/AWX+U9VycmAIfBZX+uchVqfpUxt1oJCro9dKyS009utoTDEqwgz+LvJz8oRvPA0q3afvicNDbFCS5sXCUjmT2xK8zIxjfMeYFhna0PpHWYDkXNGroPafl3YMolCVnk3SHLflOMn8bYQfUGCSGo125D0JHkboyOSvVq17HF4U+yqCZ7QkEkm0snuz7CEDiOvqiAcaC1x9HFmpV/d7DDqtO8gnHxZzPd31XPwpaM6vPvkpE5gLC1Bpk6tE2QfjsokE6n9V6YuGGpjG6WpAG7i7Ay33Bw7Yk5hkV2K4WM0Ffqcdk+k8QSIaTmsHXCyyLg/kc/SLNm98EWUqwWch155XwM7fEf/oEdyWaNp13/LTrF8WGfg8SOK7eePrOTYi9BXK9G03pxXqcECpYFc9j37ckNSxEOLBVtRhtNWKP4zgKBNNFMFfbg2oWX2PaH9lA3UQstT4UWtccJPVPwZIu+FS6I5cRQLXy0jyLRmI11AqIvE5disslmtLbinl gJMjYnLh 7l+W5CqWOoUXKso1ssXXNpAnCn0RrKufXDYfxI6Z9o2tkmZOyl/j1zoNuYRWtAL6CPGyNgZDhpQmAknawferB3o3Q9uP94WQx5KWyLN6yqT+/XWHEm7904vbvaAGaCMrhRBi+JfPer7LIMHs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jan 16, 2023, Nikunj A. Dadhania wrote: > On 13/01/23 21:47, Sean Christopherson wrote: > > It's perfectly legal for userspace to create the private memslot in response > > to a guest request. > > Sean, did not understand this part, how could a memslot be created on a guest request? KVM_HC_MAP_GPA_RANGE gets routed to host userspace, at that point userspace can take any action it wants to satisfy the guest request. E.g. a userspace+guest setup could define memory as shared by default, and only create KVM_MEM_PRIVATE memslots for memory that the guest explicitly requests to be mapped private. I don't anticipate any real world use cases actually doing something like that, but I also don't see any value in going out of our way to disallow it. Normally I like to be conservative when it comes to KVM's uAPI, e.g. allow the minimum needed to support known use cases, but restricting KVM_HC_MAP_GPA_RANGE doesn't actually achieve anything and just makes things more complex for KVM. E.g. the behavior is non-deterministic from KVM's perspective if a userspace memslots update is in-progress.