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 D8380C433F5 for ; Wed, 30 Mar 2022 16:18:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348760AbiC3QUN (ORCPT ); Wed, 30 Mar 2022 12:20:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348733AbiC3QUK (ORCPT ); Wed, 30 Mar 2022 12:20:10 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C190415A20 for ; Wed, 30 Mar 2022 09:18:20 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id y16so8346019pju.4 for ; Wed, 30 Mar 2022 09:18:20 -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=nLFu3lC46wywpXjsuIK0ZHIhaIdPVQVthjLJWcG1bqs=; b=ObdhiCZmnQ357m81FhFtTehR9aYW6P4+BOjn381CbSMHEsU1E7K3XcewtQe3sJCPWQ Csyxq34Lypg3+bYvidjj+H3qoa/rNI7SuZbTd3AoCwOk6Mqd2uRtxKjVcVzSJoZodMTf D/y6FT6RGJsMSbkAlI8a0sPYLgZwkMMWyNwRd4fxHKehurrHJxHet0aUP9LncDJtE3cQ UPOz+IFAmZ6u0RgCGDhAInm8qhjfecUTWrGa0uueQmXiVf0afirovk1cfrPKwTF9EAHS gOr/NoP4PJTR2EKpDT/fo37IVT+5E6uWqx4jWGTeL/5PLf3qFXEVzRH+FzhiYJwPOXLr Ejdw== 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=nLFu3lC46wywpXjsuIK0ZHIhaIdPVQVthjLJWcG1bqs=; b=NfMAMsMF9e6VevoHgI655rjUnlKXX58rRYHyKBmOno9cBc5uVpPKB4DDJZxteFZsqB WHr55/asIM91U9QU14h5WCkyYcxH9sFQf9ZfDutSD+dXwxeeRYopW7f7XGCjymsXEKF/ Fap9YuzGbYiy3hnDP5Dyx2KErjj03o9SnkbkkZOhxu/JzKKBEn6U2XMxCGUwhfoRzJd9 5Du1HystVY3/OrEIvxqVGkGIBQmJPth+2fyln5KUCGmgT/hBGIuXoNqzEnwSY0xA5lqk r+PpfNZKEiRrbOZGxD+51pClJlzDoXKr145cjTAbus2gVW0yRB5kuGP9oQzRgDPJZg5a npuQ== X-Gm-Message-State: AOAM533TVlMVAgaDXBDHfUxrmaoFw8xHHy3zhagBfZsqBTlzI7DoftsM Ie/zeVCXnjpljPfS/u1bUWhWYA== X-Google-Smtp-Source: ABdhPJzu0B5xizLOKCwUOp7QXz7jXFJn2pPNsklxdxdBWzWCsDjkD8HDdgo8h4C6dlF1WJ0c8QhdzA== X-Received: by 2002:a17:903:2305:b0:154:4aa2:e800 with SMTP id d5-20020a170903230500b001544aa2e800mr29560plh.167.1648657099936; Wed, 30 Mar 2022 09:18:19 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id b14-20020a056a000cce00b004fabc39519esm25365204pfv.5.2022.03.30.09.18.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 09:18:19 -0700 (PDT) Date: Wed, 30 Mar 2022 16:18:15 +0000 From: Sean Christopherson To: Steven Price Cc: Quentin Perret , Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "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" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, maz@kernel.org, will@kernel.org Subject: Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: References: <20220310140911.50924-1-chao.p.peng@linux.intel.com> <88620519-029e-342b-0a85-ce2a20eaf41b@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88620519-029e-342b-0a85-ce2a20eaf41b@arm.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, Mar 30, 2022, Steven Price wrote: > On 29/03/2022 18:01, Quentin Perret wrote: > > Is implicit sharing a thing? E.g., if a guest makes a memory access in > > the shared gpa range at an address that doesn't have a backing memslot, > > will KVM check whether there is a corresponding private memslot at the > > right offset with a hole punched and report a KVM_EXIT_MEMORY_ERROR? Or > > would that just generate an MMIO exit as usual? > > My understanding is that the guest needs some way of tagging whether a > page is expected to be shared or private. On the architectures I'm aware > of this is done by effectively stealing a bit from the IPA space and > pretending it's a flag bit. > > So when a guest access causes a fault, the flag bit (really part of the > intermediate physical address) is compared against whether the page is > present in the private fd. If they correspond (i.e. a private access and > the private fd has a page, or a shared access and there's a hole in the > private fd) then the appropriate page is mapped and the guest continues. > If there's a mismatch then a KVM_EXIT_MEMORY_ERROR exit is trigged and > the VMM is expected to fix up the situation (either convert the page or > kill the guest if this was unexpected). x86 architectures do steal a bit, but it's not strictly required. The guest can communicate its desired private vs. shared state via hypercall. I refer to the hypercall method as explicit conversion, and reacting to a page fault due to accessing the "wrong" PA variant as implicit conversion. I have dreams of supporting a software-only implementation on x86, a la pKVM, if only for testing and debug purposes. In that case, only explicit conversion is supported. I'd actually prefer TDX and SNP only allow explicit conversion, i.e. let the host treat accesses to the "wrong" PA as illegal, but sadly the guest/host ABIs for both TDX and SNP require the host to support implicit conversions. > >>>> The key point is that KVM never decides to convert between shared and private, it's > >>>> always a userspace decision. Like normal memslots, where userspace has full control > >>>> over what gfns are a valid, this gives userspace full control over whether a gfn is > >>>> shared or private at any given time. > >>> > >>> I'm understanding this as 'the VMM is allowed to punch holes in the > >>> private fd whenever it wants'. Is this correct? > >> > >> From the kernel's perspective, yes, the VMM can punch holes at any time. From a > >> "do I want to DoS my guest" perspective, the VMM must honor its contract with the > >> guest and not spuriously unmap private memory. > >> > >>> What happens if it does so for a page that a guest hasn't shared back? > >> > >> When the hole is punched, KVM will unmap the corresponding private SPTEs. If the > >> guest is still accessing the page as private, the next access will fault and KVM > >> will exit to userspace with KVM_EXIT_MEMORY_ERROR. Of course the guest is probably > >> hosed if the hole punch was truly spurious, as at least hardware-based protected VMs > >> effectively destroy data when a private page is unmapped from the guest private SPTEs. > >> > >> E.g. Linux guests for TDX and SNP will panic/terminate in such a scenario as they > >> will get a fault (injected by trusted hardware/firmware) saying that the guest is > >> trying to access an unaccepted/unvalidated page (TDX and SNP require the guest to > >> explicit accept all private pages that aren't part of the guest's initial pre-boot > >> image). > > > > I suppose this is necessary is to prevent the VMM from re-fallocating > > in a hole it previously punched and re-entering the guest without > > notifying it? > > I don't know specifically about TDX/SNP, but one thing we want to > prevent with CCA is the VMM deallocating/reallocating a private page > without the guest being aware (i.e. corrupting the guest's state).So > punching a hole will taint the address such that a future access by the > guest is fatal (unless the guest first jumps through the right hoops to > acknowledge that it was expecting such a thing). Yep, both TDX and SNP will trigger a fault in the guest if the host removes and reinserts a private page. The current plan for Linux guests is to track whether or not a given page has been accepted as private, and panic/die if a fault due to unaccepted private page occurs.