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 87530C433F5 for ; Fri, 1 Apr 2022 17:14:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F22E88D0001; Fri, 1 Apr 2022 13:14:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAB556B0072; Fri, 1 Apr 2022 13:14:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D24A68D0001; Fri, 1 Apr 2022 13:14:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id BF0AB6B0071 for ; Fri, 1 Apr 2022 13:14:37 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 62F941831AD7D for ; Fri, 1 Apr 2022 17:14:27 +0000 (UTC) X-FDA: 79308958974.29.815A3EA Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf27.hostedemail.com (Postfix) with ESMTP id E240F40020 for ; Fri, 1 Apr 2022 17:14:26 +0000 (UTC) Received: by mail-pl1-f169.google.com with SMTP id p17so2969199plo.9 for ; Fri, 01 Apr 2022 10:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=TmJlBi2lOKilVyCE4rEH1RU4SqqxsckJUfBoRuoJ5iA=; b=XswIK2+VM16bs1EyCAixrX89EKH93ezG3dB1CWqPGTee1snfa+If/AZijfKqsxCqtT czAJM7L+aUj6khEGJ6GV9s++PLrO8RH4lZkcJg2KUogkm/dx0FOh6Bdu3+L9kSytbNEF XG0woWBUkeuEHiLxkjZVlGyLcAV8wCqkBCs5NYAogpMbDENpW1paD3SiXOo3FOHbC/BE WYgluaeEO6OycFsdtzk13mJ436B8Tm+WeKW9KRWPo6GkYNWY936IsCliUkUrYOsiKniH rexTSPppoR//hQcB3ze8glrIZD0dmsOyJ/XHIq6k4cBlE7q4ChILUSTyVJwIVcd9BGxN YFAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=TmJlBi2lOKilVyCE4rEH1RU4SqqxsckJUfBoRuoJ5iA=; b=793709AOTuTgq1CPoQV74KKIRL6I7rQFM4IlGk6vLzF+1YCOys9/ywtyyqd4z1YToe MeGKwQ4DJf/tE+wSUmRNW6VvkzWzRwHY0VakLnzi9m3T/EgozKuWzT1QmrpXGuIx++NZ PfZYXOrkXte5DPLhJ1Vj9f+4WN+/A2sPtV+43tK2urTGR2d32SMlpQmflMS06N5yHVfo qNCOmbfpR0WqUdfC5BnJrK39z5pUmOTQfcOWGFZ3gak81fYEcG5b3SvkBL3K4sKGKySL tA3bWQZmYA2KysI+Nyoa5aihflQSSK/Jh74oSDUckon5FZ3ONGoPhEKEqQv75slFqYa8 qqLA== X-Gm-Message-State: AOAM533a8TZhaUkjSGcpcriAsEUrMwN6K1bc8qOGjRK/dAFuFfJNp/8C II2x+xucUf+JFybfvuIZJShEjw== X-Google-Smtp-Source: ABdhPJz12AHLKCpitPA4TCd4Qr7wvOzdMzS4bQmVFvgCp7soE2Mp/gjwDqcr67uNH6+9bYjsC7+Dhg== X-Received: by 2002:a17:902:ec8c:b0:154:2e86:dd51 with SMTP id x12-20020a170902ec8c00b001542e86dd51mr11082426plg.99.1648833265465; Fri, 01 Apr 2022 10:14:25 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id z5-20020a056a00240500b004e15d39f15fsm3669103pfh.83.2022.04.01.10.14.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Apr 2022 10:14:24 -0700 (PDT) Date: Fri, 1 Apr 2022 17:14:21 +0000 From: Sean Christopherson To: Quentin Perret Cc: Andy Lutomirski , Steven Price , Chao Peng , kvm list , Linux Kernel Mailing List , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Linux API , qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , the arch/x86 maintainers , "H. Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Mike Rapoport , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A. Shutemov" , "Nakajima, Jun" , Dave Hansen , Andi Kleen , David Hildenbrand , Marc Zyngier , Will Deacon Subject: Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: References: <88620519-029e-342b-0a85-ce2a20eaf41b@arm.com> <80aad2f9-9612-4e87-a27a-755d3fa97c92@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XswIK2+V; spf=pass (imf27.hostedemail.com: domain of seanjc@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E240F40020 X-Stat-Signature: 74kj63i7y9heuut9kkst5ftmkgdgtsx1 X-HE-Tag: 1648833266-967725 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 Fri, Apr 01, 2022, Quentin Perret wrote: > The typical flow is as follows: > > - the host asks the hypervisor to run a guest; > > - the hypervisor does the context switch, which includes switching > stage-2 page-tables; > > - initially the guest has an empty stage-2 (we don't require > pre-faulting everything), which means it'll immediately fault; > > - the hypervisor switches back to host context to handle the guest > fault; > > - the host handler finds the corresponding memslot and does the > ipa->hva conversion. In our current implementation it uses a longterm > GUP pin on the corresponding page; > > - once it has a page, the host handler issues a hypercall to donate the > page to the guest; > > - the hypervisor does a bunch of checks to make sure the host owns the > page, and if all is fine it will unmap it from the host stage-2 and > map it in the guest stage-2, and do some bookkeeping as it needs to > track page ownership, etc; > > - the guest can then proceed to run, and possibly faults in many more > pages; > > - when it wants to, the guest can then issue a hypercall to share a > page back with the host; > > - the hypervisor checks the request, maps the page back in the host > stage-2, does more bookkeeping and returns back to the host to notify > it of the share; > > - the host kernel at that point can exit back to userspace to relay > that information to the VMM; > > - rinse and repeat. I assume there is a scenario where a page can be converted from shared=>private? If so, is there a use case where that happens post-boot _and_ the contents of the page are preserved? > We currently don't allow the host punching holes in the guest IPA space. The hole doesn't get punched in guest IPA space, it gets punched in the private backing store, which is host PA space. > Once it has donated a page to a guest, it can't have it back until the > guest has been entirely torn down (at which point all of memory is > poisoned by the hypervisor obviously). The guest doesn't have to know that it was handed back a different page. It will require defining the semantics to state that the trusted hypervisor will clear that page on conversion, but IMO the trusted hypervisor should be doing that anyways. IMO, forcing on the guest to correctly zero pages on conversion is unnecessarily risky because converting private=>shared and preserving the contents should be a very, very rare scenario, i.e. it's just one more thing for the guest to get wrong. If there is a use case where the page contents need to be preserved, then that can and should be an explicit request from the guest, and can be handled through export/import style functions. Export/import would be slow-ish due to memcpy(), which is why I asked if there's a need to do this specific action frequently (or at all).