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 F1192C433EF for ; Wed, 8 Jun 2022 19:37:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64AB06B0072; Wed, 8 Jun 2022 15:37:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FA4E6B0073; Wed, 8 Jun 2022 15:37:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49B0C6B0074; Wed, 8 Jun 2022 15:37:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 36D586B0072 for ; Wed, 8 Jun 2022 15:37:32 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 141722083D for ; Wed, 8 Jun 2022 19:37:32 +0000 (UTC) X-FDA: 79556077944.15.CC2D30F Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf16.hostedemail.com (Postfix) with ESMTP id A274218001A for ; Wed, 8 Jun 2022 19:37:29 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id a10so19510480pju.3 for ; Wed, 08 Jun 2022 12:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wh6/XuxZPZUDwyzy5Eh7VeXfArKnNs6YeEjpbWE+j5g=; b=ZAG/K6D48l0KrmmRn1p2FTmiQngI/15yOkQ8MG3uOIp2K2v36XwQ2z8ZERlay6GUnj f6Sg6s8FFS/vw4GmKlcbDU92NrHn2K9bSARE4ICPUYhAVS3ymvr75ETolLgVKsl3A513 oscCyM1WP/DK5242tikPCpr2E/rKOv00sX5olq99qElwq471NkYsjKcAWArALuZx2UmC CgiqYG3dwPpKqe4lLXhreFySMsEDe8d4kPNvglQIKziVC1KrNkNXJk21EPdQMbqcRvJ6 v8IdnFTEPtFo6VDq8R+YkUgfipwAH1spS4CjC2hG/IiGlAv6nPBHFnuhil0CZaWyp+5b sSXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wh6/XuxZPZUDwyzy5Eh7VeXfArKnNs6YeEjpbWE+j5g=; b=JFfypRQYNTpNwDhv6v9U8cQZTqNQWN2EJ/IyZsKp2DOtQr/WPH60nbdEuKolpBovOj 0hYmk6mnK0ivGcV8zm3JVVqZ+jmMXJHZRv3V8venTrDmRMLkeJLdkk0IWZh3BhB0/gPH SBFe4+d5bQ5hRiWnu1UU+52N61PoThPwC5+sNR1iPA2AzJAxMeUP51O1suaLhwE/VrKA z/A947AVx8wLGAj183YIxIw3I+RthRM+LphO2Q2hpwk6BeVsKdAG7si4a/thCriRo6xq xw6OBPBIwiBVrpXRmA6zC3VVyI2HyCSGpUwbe/LQtSlUWTniCMAygk04Q2CJZXGqKU/3 /O2w== X-Gm-Message-State: AOAM530en3+ibADFxu2L2i1Up/h1FOyQDPYr1XKRjPma2bW7iJy/aH2R UyOmvmdlCdeKA+UZ6JeaeWcKE09WToKasOLojeMeTA== X-Google-Smtp-Source: ABdhPJyfhv1kDe3gJcgewOBnTs26+Uc6YFkqzaIMBY+Sas+MZKd5jC6EwNSmICRKaXBZxv4CUZaYAZlNhfXBPpTEGHU= X-Received: by 2002:a17:902:f710:b0:15f:165f:b50b with SMTP id h16-20020a170902f71000b0015f165fb50bmr36739481plo.158.1654717048302; Wed, 08 Jun 2022 12:37:28 -0700 (PDT) MIME-Version: 1.0 References: <20220519153713.819591-1-chao.p.peng@linux.intel.com> <20220607065749.GA1513445@chaop.bj.intel.com> <20220608021820.GA1548172@chaop.bj.intel.com> In-Reply-To: <20220608021820.GA1548172@chaop.bj.intel.com> From: Vishal Annapurve Date: Wed, 8 Jun 2022 12:37:17 -0700 Message-ID: Subject: Re: [PATCH v6 0/8] KVM: mm: fd-based approach for supporting KVM guest private memory To: Chao Peng Cc: Marc Orr , kvm list , LKML , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86 , "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Yu Zhang , "Kirill A . Shutemov" , Andy Lutomirski , Jun Nakajima , Dave Hansen , Andi Kleen , David Hildenbrand , aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654717049; 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=wh6/XuxZPZUDwyzy5Eh7VeXfArKnNs6YeEjpbWE+j5g=; b=yDICsXh/H4x4jHQ+UMb1LRCKHrKg1sLinE6qwhgtqGlqM2nV2eXpy0m1r2F7DNgNOCPPXM oU6W6p1E9vr/iRVGZi74rdoGQkXHQZzHfNnqejYvgZVkkAFppBbs2gVtfdzgJyHkxYWq8A aXPhTg2fo7JMXWsFVMts8+lt9xE9mYA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654717049; a=rsa-sha256; cv=none; b=7V4Tc1n6TbwhLQUAb124fCVLCqTeGmHpGpLpYA5mvFjNM03zn7UqwZiSF89F7Isv/1eSn/ 7T3RJc3o+GiU4tUTuXoizdzJhkUZ2TpRpOU01pwipaK8QPS9WkBAXPBgEDEn5GrfSiZb5k OBQnOjKE3qgmOyn5Qus13wgVwreRqns= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="ZAG/K6D4"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of vannapurve@google.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=vannapurve@google.com Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="ZAG/K6D4"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of vannapurve@google.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=vannapurve@google.com X-Rspamd-Server: rspam08 X-Rspam-User: X-Stat-Signature: qbny99n6whc3x59xkazirw587gby7yox X-Rspamd-Queue-Id: A274218001A X-HE-Tag: 1654717049-259243 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: ... > With this patch series, it's actually even not possible for userspace VMM > to allocate private page by a direct write, it's basically unmapped from > there. If it really wants to, it should so something special, by intention, > that's basically the conversion, which we should allow. > A VM can pass GPA backed by private pages to userspace VMM and when Userspace VMM accesses the backing hva there will be pages allocated to back the shared fd causing 2 sets of pages backing the same guest memory range. > Thanks for bringing this up. But in my mind I still think userspace VMM > can do and it's its responsibility to guarantee that, if that is hard > required. By design, userspace VMM is the decision-maker for page > conversion and has all the necessary information to know which page is > shared/private. It also has the necessary knobs to allocate/free the > physical pages for guest memory. Definitely, we should make userspace > VMM more robust. Making Userspace VMM more robust to avoid double allocation can get complex, it will have to keep track of all in-use (by Userspace VMM) shared fd memory to disallow conversion from shared to private and will have to ensure that all guest supplied addresses belong to shared GPA ranges. A coarser but simpler alternative could be to always allow shared to private conversion with unbacking the memory from shared fd and exit if the VMM runs in double allocation scenarios. In either cases, unbacking shared fd memory ideally should prevent memory allocation on subsequent write accesses to ensure double allocation scenarios are caught early. Regards, Vishal