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 80A0DC433EF for ; Fri, 10 Jun 2022 19:18:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9464A8D00CB; Fri, 10 Jun 2022 15:18:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CF356B00B1; Fri, 10 Jun 2022 15:18:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 748468D00CB; Fri, 10 Jun 2022 15:18:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 60A056B00B0 for ; Fri, 10 Jun 2022 15:18:45 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 2E878603E7 for ; Fri, 10 Jun 2022 19:18:45 +0000 (UTC) X-FDA: 79563288210.08.31DB889 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf19.hostedemail.com (Postfix) with ESMTP id 827CD1A0075 for ; Fri, 10 Jun 2022 19:18:44 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8D33DB8372E for ; Fri, 10 Jun 2022 19:18:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2073FC341C6 for ; Fri, 10 Jun 2022 19:18:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654888720; bh=hM5nW1VA3yu5jpO3mlOUoDJaWYFKk3W0xm89jLGspjI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HhH/LtWGsBwB06n1CnPo9lhK0VtlQ6R1OeUxR4n65mwZeBEFV6sMuVM/FQ4mWjKfC U0buD2yynVGlZgaWK2yhy6sCYPwzRpoLMXXRNC35AXp8WPmbjWScn8eeu+b4znMsyo SBLsipBoAgnNOKj9AmZY2W5Wf3H0Kmmm5b4EHejPbftkHKC+R73iWdRMndn/qU7LdN mi8mlFucHHdXR3vU1iUTLqfm10BRj29AjwGU2+vcfzCq9fPpj35CHw9WzOEvI4Yn5B f5qeWPoNNahJsN/WYeZcsckWm0SeiIae32rB0ZzDFftWrWFELWEKh7GyQQVeErl1tH OVUa6I1o1xhTA== Received: by mail-ej1-f53.google.com with SMTP id me5so54698200ejb.2 for ; Fri, 10 Jun 2022 12:18:40 -0700 (PDT) X-Gm-Message-State: AOAM531HPCFlYr2XWhEaku2OChG/yHKl6/5x+CxBs4o+3Np/dk2Ubh1E ABnvIMnK/OCdyemCzkoHb5M1+2GjKfvmTcei+NsPsg== X-Google-Smtp-Source: ABdhPJwexJxeTadU2a/HS+Q0PaTCtU7UH0lxqqpyQzdJR6JkeVtaY0mkRVT4jHiiW5JTPVMgfQPUbTO0E50JluvSE3Y= X-Received: by 2002:a17:906:25d8:b0:6fe:9f11:3906 with SMTP id n24-20020a17090625d800b006fe9f113906mr40977072ejb.538.1654888718314; Fri, 10 Jun 2022 12:18:38 -0700 (PDT) MIME-Version: 1.0 References: <83fd55f8-cd42-4588-9bf6-199cbce70f33@www.fastmail.com> <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> In-Reply-To: From: Andy Lutomirski Date: Fri, 10 Jun 2022 12:18:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory To: Sean Christopherson Cc: Andy Lutomirski , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654888724; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tFG1sQ8DTufv4O+hsuo6BXQgfzLdg3PPSrVuFnke8fs=; b=7vIBQKDgmWOpIDFgNjjOuOa2Z2QI31ayDuI+j7m0YcAZxvYBb3w99uXxQ90LOtv2nw+4XG 3oZWFWDJoTaAXKcG56DxXLi93+34zfjVOFEhNKQVIAMghbpv0miEYc0b4t8De2d+k/EDYy i+H4MnKBfQbsAJlXVGKKwxBAWJFUlTY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654888724; a=rsa-sha256; cv=none; b=Tes/Hnm9G3FuwIlef8y42e5yJvB5n+Lw411MbubMbc/8sEa28rOztlGsEW2OitJCpoH8uk YUp8lVu2E/o5zYzvrTAL4SfC356kEtRqpgrYbXbGOUUjdxFiTt5jw5Ax54OzAy0IAeF8GB j8dq4SMuW8ObSAOzxBcKKiHzkaSv1R8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="HhH/LtWG"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="HhH/LtWG"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org X-Stat-Signature: j3yiwhzyhpfke11poby9kcbn8yt65rpq X-Rspamd-Queue-Id: 827CD1A0075 X-HE-Tag: 1654888724-370736 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 Mon, Apr 25, 2022 at 1:31 PM Sean Christopherson wro= te: > > 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 i= t's in > > >> the initial state appropriate for that VM. > > >> > > >> For TDX, this completely bypasses the cases where the data is prepop= ulated > > >> and TDX can't handle it cleanly. > > I believe TDX can handle this cleanly, TDH.MEM.PAGE.ADD doesn't require t= hat the > source and destination have different HPAs. There's just no pressing nee= d to > support such behavior because userspace is highly motivated to keep the i= nitial > 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=C2=AE 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-td= x-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. --Andy