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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EDF88C77B7D for ; Wed, 10 May 2023 20:24:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230035AbjEJUYL (ORCPT ); Wed, 10 May 2023 16:24:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229490AbjEJUYI (ORCPT ); Wed, 10 May 2023 16:24:08 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 966164C12 for ; Wed, 10 May 2023 13:24:06 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-9661a1ff1e9so819940466b.1 for ; Wed, 10 May 2023 13:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683750245; x=1686342245; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=e9tsDGYXv+bEoxWcAObPjFgV7/FfCrcTsVECGRiJ1t0=; b=AL2r2UGoudGyCqFXk6I5lQAfnNT7p0RV0gE0GRm9cnCWHsR+/38A9Lv7Gu9Vw5DRER Zh27WSmnEr8cs09vPvgOfkVdmHn7DdaxvYYaFaxFNW20enEEZvGvUhrRFuH7pdUwknih PW0HZdgZziZjPCCkUb5Gm6maFS1Qd3pqCosq9D/P5jjUKzRuHi+tLM7GwCL5Hro7GF9Y R7Ib5ie69pVs+fNwCIrJBK0mJAM8iAfNWt1C0twqR/jJMU5sLiRaUl3qwEtXNRf6behR WhVHf7Pwyp3LS+II30xWKZs5ZDAW7iMyjdf2ZB9SI5Y+rgh9SPDn3DlIvqvrcRDMhinK QEvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683750245; x=1686342245; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=e9tsDGYXv+bEoxWcAObPjFgV7/FfCrcTsVECGRiJ1t0=; b=O05kXlxFVJa4AVSJZN0P5SLxXvE1jdQGIjeCSVs/VSxoPESL5iVtt17ovdoZAtR0Cg R48+LkBotH1HBJSS+JiReqHh2JJnzYSpk849wYt4fdZD9pfBvY/08Iw7ilzeSa+z9t8O ZDsKgJnp7Hy52RCgzqjjNFB4yq3O/SJtIT+JOmGSE48hHfWB/hZpuCLdd9G0qyGd8y// LHINXBaN+GeC8kK8qrLIs96Y/H8Q9dl2xo/bjq7Y7dL+zEC88djtBNYXIBpWXbmqfggb DRLokvHqMc4lQ+BwmKKQK1XjHsiX0yBUFOuTcWSB8Zr2zcVd81huBe5fP3S+CZyiII08 yuMQ== X-Gm-Message-State: AC+VfDwT535LGIE0TrvmVRL5RhPnjfKiNRMThgO4YAZCVVp7KZ92G1Nr 21gFpprF7FsVUKq9209upbSNF3ID1RPbLRm1O7rs3g== X-Google-Smtp-Source: ACHHUZ5W0ZwEAWGEeIx+PgUo5yUgC9JzyXmdtX2yCRiaP5fyrb23haIMEGI1FbsZeyTbWNWF3iC0JIvucvZS/Xtl7TE= X-Received: by 2002:a17:907:a40d:b0:969:83c7:7357 with SMTP id sg13-20020a170907a40d00b0096983c77357mr9344482ejc.6.1683750244850; Wed, 10 May 2023 13:24:04 -0700 (PDT) MIME-Version: 1.0 References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <658018f9-581c-7786-795a-85227c712be0@redhat.com> <1ed06a62-05a1-ebe6-7ac4-5b35ba272d13@redhat.com> <9efef45f-e9f4-18d1-0120-f0fc0961761c@redhat.com> <5869f50f-0858-ab0c-9049-4345abcf5641@redhat.com> In-Reply-To: From: Vishal Annapurve Date: Wed, 10 May 2023 13:23:53 -0700 Message-ID: Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM) To: Sean Christopherson Cc: David Hildenbrand , Chao Peng , Paolo Bonzini , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , "Maciej S . Szmigiero" , Vlastimil Babka , Yu Zhang , "Kirill A . Shutemov" , dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , wei.w.wang@intel.com, Mike Rapoport , Liam Merwick , Isaku Yamahata , Jarkko Sakkinen , Ackerley Tng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Hugh Dickins , Christian Brauner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 10, 2023 at 10:26=E2=80=AFAM Vishal Annapurve wrote: > > On Fri, Apr 21, 2023 at 6:33=E2=80=AFPM Sean Christopherson wrote: > > > > ... > > cold. I poked around a bit to see how we could avoid reinventing all o= f that > > infrastructure for fd-only memory, and the best idea I could come up wi= th is > > basically a rehash of Kirill's very original "KVM protected memory" RFC= [3], i.e. > > allow "mapping" fd-only memory, but ensure that memory is never actuall= y present > > from hardware's perspective. > > > > I am most likely missing a lot of context here and possibly venturing > into an infeasible/already shot down direction here. But I would still > like to get this discussed here before we move on. > > I am wondering if it would make sense to implement > restricted_mem/guest_mem file to expose both private and shared memory > regions, inline with Kirill's original proposal now that the file > implementation is controlled by KVM. > > Thinking from userspace perspective: > 1) Userspace creates guest mem files and is able to mmap them but all > accesses to these files result into faults as no memory is allowed to > be mapped into userspace VMM pagetables. > 2) Userspace registers mmaped HVA ranges with KVM with additional > KVM_MEM_PRIVATE flag > 3) Userspace converts memory attributes and this memory conversion > allows userspace to access shared ranges of the file because those are > allowed to be faulted in from guest_mem. Shared to private conversion > unmaps the file ranges from userspace VMM pagetables. > 4) Granularity of userspace pagetable mappings for shared ranges will > have to be dictated by KVM guest_mem file implementation. > > Caveat here is that once private pages are mapped into userspace view. > > Benefits here: > 1) Userspace view remains consistent while still being able to use HVA ra= nges > 2) It would be possible to use HVA based APIs from userspace to do > things like binding. > 3) Double allocation wouldn't be a concern since hva ranges and gpa > ranges possibly map to the same HPA ranges. > I realize now that VFIO IOMMU mappings are not associated with userspace MMU in any way. So this approach does leave the gap of not being able to handle modifications of IOMMU mappings when HVA mappings are modified in userspace page tables. I guess this could be a good enough reason to give up on this option. > > > > Code is available here if folks want to take a look before any kind of = formal > > posting: > > > > https://github.com/sean-jc/linux.git x86/kvm_gmem_solo > > > > [1] https://lore.kernel.org/all/ff5c5b97-acdf-9745-ebe5-c6609dd6322e@go= ogle.com > > [2] https://lore.kernel.org/all/20230418-anfallen-irdisch-6993a61be10b@= brauner > > [3] https://lore.kernel.org/linux-mm/20200522125214.31348-1-kirill.shut= emov@linux.intel.com