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 5CDA0C433EF for ; Fri, 10 Jun 2022 19:27:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350281AbiFJT1o (ORCPT ); Fri, 10 Jun 2022 15:27:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237516AbiFJT1m (ORCPT ); Fri, 10 Jun 2022 15:27:42 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9D491455A6 for ; Fri, 10 Jun 2022 12:27:39 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id f9so83927plg.0 for ; Fri, 10 Jun 2022 12:27:39 -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:content-transfer-encoding:in-reply-to; bh=PkrZb935FOMK/VTbtX8totq42RNXT0VkqR/O4EKP5jw=; b=kmpQnW9pQgc6jCgIv4PLRkvKW49ZsJ+smOOvRhdRKVJdJ9Zkgk/YtNmm2SoA/O56aA yjFKkHRfbiMSOg+r0ZuEHtWF+14lgCCm5q+DXC3bejs09+0NaISJZNgBhtVPM9hZrici 3midqgBOk1EJAH+oLhfyYrDiwbBDxS42gWbD3T1HxBtTqZj5rJQ1Vj5t+t/6Y/yDFzkR TRp+d8eLox2jVwYtlenr13zA6kmJWThb1Qn1BG5USAR/NIbWIM5rxoKgalwJT2rnYHA0 Li6tjfWy3x6EaebIJ1bWYlnHEdXiiKan7s8y/yDhYNyNGVMe9Qq5RglipqFtGNp66N0C fy8g== 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:content-transfer-encoding :in-reply-to; bh=PkrZb935FOMK/VTbtX8totq42RNXT0VkqR/O4EKP5jw=; b=wHZDj8n0WPvvSRPuwpmYta7KL2Ow251fuCSbz7Zava/wt5IhN3Fg2tdD++InR70R4k X5NctaN34vYmeqeb33BhYkuahensRP1atMoi75fdLmXM5jF0Ekf2ptfa5yUIBMPWgVVv n34z74fZG3NUj6YyqzC1epiAbiOgKma+uETAE/6S553xrJ0E/gQ/xXrVIPXc+sKTfAj5 seFNb8kNs2uQXexRE7FM5N9qQlfFyf/BS1K1b6YIBY49VgpYNVZ0/wg+q3FIAnOAexXy nDALX3lYd84tsJ0Smee5LfFtJCA2dGJHaDsZV0JpZ+WEQqYy0hv1jxaAlR/IhFnjMdE6 L//g== X-Gm-Message-State: AOAM530rZM8XBM2kfAY0gc9UwdlN9O0qUAUt5VB6FfIxZdrzVMDpcXT0 CiGRLuFEztirwwhmz366hjWpeg== X-Google-Smtp-Source: ABdhPJzu4+uiwCvV1vrvW1wojSNf5k+tJhEK5603Gry9wHXsc+/ZSsj5mtg+D4HxhdsWZ9rjzRno9w== X-Received: by 2002:a17:902:be12:b0:167:6cbd:f113 with SMTP id r18-20020a170902be1200b001676cbdf113mr32389883pls.69.1654889259182; Fri, 10 Jun 2022 12:27:39 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id 187-20020a6215c4000000b0051b32c2a5a7sm19853799pfv.138.2022.06.10.12.27.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 12:27:38 -0700 (PDT) Date: Fri, 10 Jun 2022 19:27:35 +0000 From: Sean Christopherson To: Andy Lutomirski Cc: Chao Peng , Quentin Perret , Steven Price , 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: <20220422105612.GB61987@chaop.bj.intel.com> <3b99f157-0f30-4b30-8399-dd659250ab8d@www.fastmail.com> <20220425134051.GA175928@chaop.bj.intel.com> <27616b2f-1eff-42ff-91e0-047f531639ea@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Jun 10, 2022, Andy Lutomirski wrote: > On Mon, Apr 25, 2022 at 1:31 PM Sean Christopherson wrote: > > > > On Mon, Apr 25, 2022, Andy Lutomirski wrote: > > > > > > > > > On Mon, Apr 25, 2022, at 6:40 AM, Chao Peng wrote: > > > > On Sun, Apr 24, 2022 at 09:59:37AM -0700, Andy Lutomirski wrote: > > > >> > > > > > > >> > > > >> 2. Bind the memfile to a VM (or at least to a VM technology). Now it's in > > > >> the initial state appropriate for that VM. > > > >> > > > >> For TDX, this completely bypasses the cases where the data is prepopulated > > > >> and TDX can't handle it cleanly. > > > > I believe TDX can handle this cleanly, TDH.MEM.PAGE.ADD doesn't require that the > > source and destination have different HPAs. There's just no pressing need to > > support such behavior because userspace is highly motivated to keep the initial > > image small for performance reasons, i.e. burning a few extra pages while building > > the guest is a non-issue. > > Following up on this, rather belatedly. After re-reading the docs, > TDX can populate guest memory using TDH.MEM.PAGE.ADD, but see Intel® > TDX Module Base Spec v1.5, section 2.3, step D.4 substeps 1 and 2 > here: > > https://www.intel.com/content/dam/develop/external/us/en/documents/intel-tdx-module-1.5-base-spec-348549001.pdf > > For each TD page: > > 1. The host VMM specifies a TDR as a parameter and calls the > TDH.MEM.PAGE.ADD function. It copies the contents from the TD > image page into the target TD page which is encrypted with the TD > ephemeral key. TDH.MEM.PAGE.ADD also extends the TD > measurement with the page GPA. > > 2. The host VMM extends the TD measurement with the contents of > the new page by calling the TDH.MR.EXTEND function on each 256- > byte chunk of the new TD page. > > So this is a bit like SGX. There is a specific series of operations > that have to be done in precisely the right order to reproduce the > intended TD measurement. Otherwise the guest will boot and run until > it tries to get a report and then it will have a hard time getting > anyone to believe its report. > > So I don't think the host kernel can get away with host userspace just > providing pre-populated memory. Userspace needs to tell the host > kernel exactly what sequence of adds, extends, etc to perform and in > what order, and the host kernel needs to do precisely what userspace > asks it to do. "Here's the contents of memory" doesn't cut it unless > the tooling that builds the guest image matches the exact semantics > that the host kernel provides. For TDX, yes, a KVM ioctl() is mandatory for all intents and purposes since adding non-zero memory into the guest requires a SEAMCALL. My "idea", which I'm not sure would actually work, is more than a bit contrived, and which I don't think is remotely critical to support, is to let userspace fill the guest private memory directly and then use the private page for both the source and the target to TDH.MEM.PAGE.ADD. That would avoid having to double allocate memory for the initial guest image. But like I said, contrived and low priority.