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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44501C4708F for ; Wed, 2 Jun 2021 23:33:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B1039613E5 for ; Wed, 2 Jun 2021 23:33:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1039613E5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 213046B006C; Wed, 2 Jun 2021 19:33:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EA8E6B006E; Wed, 2 Jun 2021 19:33:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0651B6B0070; Wed, 2 Jun 2021 19:33:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id C82286B006C for ; Wed, 2 Jun 2021 19:33:45 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4FE4D180AD806 for ; Wed, 2 Jun 2021 23:33:45 +0000 (UTC) X-FDA: 78210388410.13.362C7E7 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf04.hostedemail.com (Postfix) with ESMTP id 8F9A23C3 for ; Wed, 2 Jun 2021 23:33:37 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id f12so4776592ljp.2 for ; Wed, 02 Jun 2021 16:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PTfQXWxpT7/vPk75BLaU1gGVmYZcPYEwaABzwTpX4X8=; b=xoIjz3sZWLuffKRVh0YALgXm6O8hnsf+f+WCDpt4AdwtSsGKBjFrDkpv6SHmOKfLvQ ag6Zz3+0PVbskBft46UU1iBPu+6JCm+XXaKgAsY1YTm7Ib3+vfaTARypU8kuS4DO8bU4 4erqAmfO60o4/Y1v3inpt4u+tjLPknSeFcCnLA9KJ6i+IHoPzKxtEqsTAYOUcyv0H/ip 1H2ACkRBA30VtVgxpEFXPfXt7aT1I0vO4gIY+bd0BjcOMeDMWrsQIC89RzVjDvUkQ6Me nUD6UbBJ4qa2eYALWuISCxy5eyq2hsGJQ20/+Fy776Zq2mDn6g5z5YbtJm0dl/EkdAIS D2lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=PTfQXWxpT7/vPk75BLaU1gGVmYZcPYEwaABzwTpX4X8=; b=SReUlxVFlrR0LWAOrxLG+urdYHOO88LyQMhu9tX+Uw6aSrm29upCzsR+pREjRcBgRI ZE15GpALoAXbBLOtk5YPIsCt+QcBXTrDqRNmh5PuZEmUeB2Fd8FeAcldBnaJwtwjDWl0 DS9J6gi26/MZgaRCLsT1RzoqQuDqkOLY1Ft20Iv9AzGltFoApAhZO+URMf5bQ7Uhnthi P4hxbbfuYEDG1xAtDa9ulZneXIh7cm/KPKrbaUWRSCgLIUbeuoqD6UPwbSmcxmgkMLOs 1OpsKZ4c5TMe7dAGS91DQ6o98DwvUK+KyA8BVA7O9VgQWFJ7lym6dVGEXHhRC/okNO4S anYg== X-Gm-Message-State: AOAM531jFm+r/s6IhUW/Edd0QuZJPk9B84rX6hcN0fmL8QIB0u4PcsmO IyBql7XDbgLOXUBXwdCHI7yOYw== X-Google-Smtp-Source: ABdhPJyxY2uHTU5pxb90Q61I0oFx+mfHXgdsajfEDRhtoMh/thfpDCvGB+RQADYTGQ5zaZ+IYKauew== X-Received: by 2002:a2e:a489:: with SMTP id h9mr27552130lji.21.1622676823199; Wed, 02 Jun 2021 16:33:43 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id p1sm132646lfr.78.2021.06.02.16.33.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Jun 2021 16:33:42 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 70984102781; Thu, 3 Jun 2021 02:33:53 +0300 (+03) Date: Thu, 3 Jun 2021 02:33:53 +0300 From: "Kirill A. Shutemov" To: Sean Christopherson Cc: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Jim Mattson , David Rientjes , "Edgecombe, Rick P" , "Kleen, Andi" , "Yamahata, Isaku" , Erdem Aktas , Steve Rutherford , Peter Gonda , David Hildenbrand , Chao Peng , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFCv2 13/13] KVM: unmap guest memory using poisoned pages Message-ID: <20210602233353.gxq35yxluhas5knp@box> References: <20210419164027.dqiptkebhdt5cfmy@box.shutemov.name> <20210419185354.v3rgandtrel7bzjj@box> <20210419225755.nsrtjfvfcqscyb6m@box.shutemov.name> <20210521123148.a3t4uh4iezm6ax47@box> <20210531200712.qjxghakcaj4s6ara@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8F9A23C3 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=xoIjz3sZ; spf=none (imf04.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.208.170) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-Rspamd-Server: rspam04 X-Stat-Signature: 1ufmmibf888qhqgktw7x8wyyue1tbn53 X-HE-Tag: 1622676817-2076 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, Jun 02, 2021 at 05:51:02PM +0000, Sean Christopherson wrote: > > Omitting FOLL_GUEST for shared memory doesn't look like a right approach. > > IIUC, it would require the kernel to track what memory is share and what > > private, which defeat the purpose of the rework. I would rather enforce > > !PageGuest() when share SEPT is populated in addition to enforcing > > PageGuest() fro private SEPT. > > Isn't that what omitting FOLL_GUEST would accomplish? For shared memory, > including mapping memory into the shared EPT, KVM will omit FOLL_GUEST and thus > require the memory to be readable/writable according to the guest access type. Ah. I guess I see what you're saying: we can pipe down the shared bit from GPA from direct_page_fault() (or whatever handles the fault) down to hva_to_pfn_slow() and omit FOLL_GUEST if the shared bit is set. Right? I guest it's doable, but codeshuffling going to be ugly. > By definition, that excludes PageGuest() because PageGuest() pages must always > be unmapped, e.g. PROTNONE. And for private EPT, because PageGuest() is always > PROTNONE or whatever, it will require FOLL_GUEST to retrieve the PTE/PMD/Pxx. > > On a semi-related topic, I don't think can_follow_write_pte() is the correct > place to hook PageGuest(). TDX's S-EPT has a quirk where all private guest > memory must be mapped writable, but that quirk doesn't hold true for non-TDX > guests. It should be legal to map private guest memory as read-only. Hm. The point of the change in can_follow_write_pte() is to only allow to write to a PageGuest() page if FOLL_GUEST is used and the mapping is writable. Without the change gup(FOLL_GUEST|FOLL_WRITE) would fail. It doesn't prevent using read-only guest mappings as read-only. But if you want to write to it it has to writable (in addtion to FOLL_GUEST). > And I believe the below snippet in follow_page_pte() will be problematic > too, since FOLL_NUMA is added unless FOLL_FORCE is set. I suspect the > correct approach is to handle FOLL_GUEST as an exception to > pte_protnone(), though that might require adjusting pte_protnone() to be > meaningful even when CONFIG_NUMA_BALANCING=n. > > if ((flags & FOLL_NUMA) && pte_protnone(pte)) > goto no_page; > if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) { > pte_unmap_unlock(ptep, ptl); > return NULL; > } Good catch. I'll look into how to untangle NUMA balancing and PageGuest(). It shouldn't be hard. PageGuest() pages should be subject for balancing. > > Do you see any problems with this? > > > > > Oh, and the other nicety is that I think it would avoid having to explicitly > > > handle PageGuest() memory that is being accessed from kernel/KVM, i.e. if all > > > memory exposed to KVM must be !PageGuest(), then it is also eligible for > > > copy_{to,from}_user(). > > > > copy_{to,from}_user() enforce by setting PTE entries to PROT_NONE. > > But KVM does _not_ want those PTEs PROT_NONE. If KVM is accessing memory that > is also accessible by the the guest, then it must be shared. And if it's shared, > it must also be accessible to host userspace, i.e. something other than PROT_NONE, > otherwise the memory isn't actually shared with anything. > > As above, any guest-accessible memory that is accessed by the host must be > shared, and so must be mapped with the required permissions. I don't see contradiction here: copy_{to,from}_user() would fail with -EFAULT on PROT_NONE PTE. By saying in initial posting that inserting PageGuest() into shared is fine, I didn't mean it's usefule, just allowed. -- Kirill A. Shutemov