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 58252ECAAD8 for ; Wed, 14 Sep 2022 11:02:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C134C6B0075; Wed, 14 Sep 2022 07:02:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC3AA8D0003; Wed, 14 Sep 2022 07:02:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3DE78D0002; Wed, 14 Sep 2022 07:02:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 92E6F6B0075 for ; Wed, 14 Sep 2022 07:02:36 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 60AE8140374 for ; Wed, 14 Sep 2022 11:02:36 +0000 (UTC) X-FDA: 79910402712.01.77A3802 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf29.hostedemail.com (Postfix) with ESMTP id 0AFB81200E4 for ; Wed, 14 Sep 2022 11:02:35 +0000 (UTC) Received: by mail-yb1-f177.google.com with SMTP id a67so22128991ybb.3 for ; Wed, 14 Sep 2022 04:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=/x00XsnVTU+kUzsYJrpklCSNRK/9eB/Ro0omNgHKcjw=; b=Ac+HILwHqFFR2pInEWD80qd2Hhz+KfnP4ARhZ3KyCXTpvJHHyDr5V77NYqhoryvKQF dJl70OsGI0lKszgDLTBOZms3/5pvkgfdBUsbSMNSOIBlxaFsdc7cgn5psSKITP8kpB8V xOzwhPJMSYAUctwdpFGlbaEV8SCKDjuEChL+pePwijO8xIoqVkrcYcsRV3btirYx+tku aJU0WUO414C/Wxp0Pun9MOzwXxccxG7OLsrzTyXTmPxK4MXbny48p17mxgOF8jpFZlSC vn7QRQpNrCPXxTAfiA2XvFNUXAO+i9LMxAgMQkBRd9WFAiYeZLTuesMC0akB+54eK5HU ub8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=/x00XsnVTU+kUzsYJrpklCSNRK/9eB/Ro0omNgHKcjw=; b=fKrXQ1OO3FzGJ6EgdMSOT4zIJqoYq6W3jNlJF+GtlWutdrViqa3k97g+TcZmQ5v+jD e9g5ODlzd+m54kTwsv7Dr9ECIuj8gDB5fc9horDSosWVNnrn4bzFS095jCnFo9jyqNkI NO6QLIPulvUtfjjIQ5VfKCgkYMIsJQCX/6oBoKgYDfdB0TMW9FnCgzAzLIv8EFd1kXEZ SB+JUgMmWf4HjPLhP5eB1E7NSjrMeAAg63xi3awgAunNsSYulKD65kAFcW2HN4y5xI5p cZpGEvrBOT5xID9QPcAUtD/lVd0j26n9fLwOi2j1egmOmr8W8ROsEafQPUV06frg9S2R nxHg== X-Gm-Message-State: ACrzQf2gLc+4W2CTTdD1IHvyvUSLXhOaXzIvZCf15RHARyBZJ2PDVhEu PZDZXfSIiNcb1xxkKIn1cWTBEldKmDujHUJD1B2Rlw== X-Google-Smtp-Source: AMsMyM6fR7f9+1MEXCI5QuGuGovnipYhYRAJTAwDI0qsEJj/bJnJPP8LwBKgS1imITQ25V5RZaRZfc6YC0GybpIkiZM= X-Received: by 2002:a25:720b:0:b0:6b0:4b3:c121 with SMTP id n11-20020a25720b000000b006b004b3c121mr1725545ybc.473.1663153355073; Wed, 14 Sep 2022 04:02:35 -0700 (PDT) MIME-Version: 1.0 References: <20210820155918.7518-1-brijesh.singh@amd.com> <20210820155918.7518-40-brijesh.singh@amd.com> <4e41dcff-7c7b-cf36-434a-c7732e7e8ff2@amd.com> <20220908212114.sqne7awimfwfztq7@amd.com> In-Reply-To: From: Marc Orr Date: Wed, 14 Sep 2022 12:02:24 +0100 Message-ID: Subject: Re: [PATCH Part2 v5 39/45] KVM: SVM: Introduce ops for the post gfn map and unmap To: Sean Christopherson Cc: Michael Roth , Brijesh Singh , x86 , LKML , kvm list , linux-coco@lists.linux.dev, Linux Memory Management List , Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Sathyanarayanan Kuppuswamy , jarkko@profian.com Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663153356; a=rsa-sha256; cv=none; b=VmKIhNL7zTbQ8ZayvYSKBZ4FFzjNQK8gxNrmHbSCMzPPsMGPi6OvmO3cFnsGNm/N8JKT+R l2cooDIk8YpvJKhGjCuHBO1eJV0ZW29u4T1RCCl7mvfV5vuJDqHwa14poX1FBF2hYo68JO XiqupHaSjs6xerP+BP1w17RubGmpn1g= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ac+HILwH; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of marcorr@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=marcorr@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663153356; 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=/x00XsnVTU+kUzsYJrpklCSNRK/9eB/Ro0omNgHKcjw=; b=436CEwgH4nvmh/ySM/ZzyGXtNSGnOPcv4Ok4UQlSibmnqrZDzEc7XYgVIl656plcXJswDm pI7wSptomAY01UB3cuFNs4IcRlgG8cirbKdYFZfaa9S9582dofvrkzCUVR5ikzZV9YHGpL OiceMT2RSY0888T+fw9Wr1wNOWU3YAE= Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ac+HILwH; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of marcorr@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=marcorr@google.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0AFB81200E4 X-Stat-Signature: t7wdwjwfm56576ndu5dxrdh64oznszf1 X-Rspam-User: X-HE-Tag: 1663153355-550020 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 Wed, Sep 14, 2022 at 9:05 AM Sean Christopherson wrote: > > On Thu, Sep 08, 2022, Michael Roth wrote: > > On Fri, Oct 15, 2021 at 05:16:28PM +0000, Sean Christopherson wrote: > > So in the context of this interim solution, we're trying to look for a > > solution that's simple enough that it can be used reliably, without > > introducing too much additional complexity into KVM. There is one > > approach that seems to fit that bill, that Brijesh attempted in an > > earlier version of this series (I'm not sure what exactly was the > > catalyst to changing the approach, as I wasn't really in the loop at > > the time, but AIUI there weren't any showstoppers there, but please > > correct me if I'm missing anything): > > > > - if the host is writing to a page that it thinks is supposed to be > > shared, and the guest switches it to private, we get an RMP fault > > (actually, we will get a !PRESENT fault, since as of v5 we now > > remove the mapping from the directmap as part of conversion) > > - in the host #PF handler, if we see that the page is marked private > > in the RMP table, simply switch it back to shared > > - if this was a bug on the part of the host, then the guest will see > > As discussed off-list, attempting to fix up RMP violations in the host #PF handler > is not a viable approach. There was also extensive discussion on-list a while back: > > https://lore.kernel.org/all/8a244d34-2b10-4cf8-894a-1bf12b59cf92@www.fastmail.com I mentioned this during Mike's talk at the micro-conference: For pages mapped in by the kernel can we disallow them to be converted to private? Note, userspace accesses are already handled by UPM. In pseudo-code, I'm thinking something like this: kmap_helper() { // And all other interfaces where the kernel can map a GPA // into the kernel page tables mapped_into_kernel_mem_set[hpa] = true; } kunmap_helper() { // And all other interfaces where the kernel can unmap a GPA // into the kernel page tables mapped_into_kernel_mem_set[hpa] = false; // Except it's not this simple because we probably need ref counting // for multiple mappings. Sigh. But you get the idea. } rmpupdate_helper() { if (conversion = SHARED_TO_PRIVATE && mapped_into_kernel_mem_set[hpa]) return -EINVAL; // Or whatever the appropriate error code here is. }