Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp4804476rwb; Tue, 17 Jan 2023 05:50:58 -0800 (PST) X-Google-Smtp-Source: AMrXdXul6Kdc3OkITN7sXjUPt2nSzNibyUCUFiKvVzkOrWEfVT3V2mTr/t7PRd4A13ReSWOuj+Ls X-Received: by 2002:a17:90a:8591:b0:227:203a:e649 with SMTP id m17-20020a17090a859100b00227203ae649mr3547679pjn.16.1673963458730; Tue, 17 Jan 2023 05:50:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673963458; cv=none; d=google.com; s=arc-20160816; b=dz+l6oJbxWy6tmUsawqQOKk/0Xnv2N5Mglza8rsiy8YN9UPtX4quyG+DDh8AUPsUs/ uzT+uJAIIL2DxENZXqFGYZUeca4PFcI8JSgLBbXVVRTEdWaZFRQ9MQHwY7vAsindyqDY OBI22exlYcJiziUNM3n2zSIAnr+Nerfn0EIXbS5SMcNLTVjyhz3dzFthaUZtnHzau9Vx Je6nSC/UZbi1KzQnygrsLbiNgkLze3LG2yD7UYKKpxx8xXPErDJWdC4XjsEtQx3tfsa7 Pqe0iZ/XpGc53EQTEV4cxDFZ9Pk6nTt8NO9DoL5hf1WVtd49GoJIkto2IVNEOg/XX6ar s5Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=uO6Hl9Q1M/Q348P8FnxA7jBYA0T+TYYW0ZM59Q1/+sI=; b=tRYgG72wN03KFra55KNZz/fq6UXSyV2Ac/8viintcvG2GtTDnZfbzBg43o4/5/DmSj CV/t9lrKZiryQja0yQysITt1HxIBGfeTu93oPf5tJix5qFXZX+l0plkCbC+jBmAJrLeY KhJx1pHIM1YmVMrE9dJUZuo+3Ib0/z4WkFkkqiBoZwu11So6JXEGH8ujOPwq8Ieg9H/B sWxt/6aQcP6DqncfVW5dIrZCnqeHvF/XZ+K2ci7OfbawcMvhj5lfhAtNUIzXu8KdF3zC C/o19nRND0JgPApMtODuQt/06UedQ0zzxH4QrzPjfdx3r/R1BeJfA32M9Tl+m8NcqR06 py2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FZZ67c5f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oe1-20020a17090b394100b002271ef21dafsi23784887pjb.15.2023.01.17.05.50.52; Tue, 17 Jan 2023 05:50:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FZZ67c5f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236066AbjAQN1k (ORCPT + 48 others); Tue, 17 Jan 2023 08:27:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236347AbjAQN1h (ORCPT ); Tue, 17 Jan 2023 08:27:37 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A086534C01; Tue, 17 Jan 2023 05:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673962056; x=1705498056; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=OkxN9qHIfugzlGcYWrmJzkTgsJkFyQ0089rnB9xhbso=; b=FZZ67c5fd67JbVwO7XsESIoD/yIBVevp/EuOVI6JMN/vb1e3rb5QghW+ xW3WzHxkFezkA6H5M4B6PIQJ3ocXJTrcMXDx5fQ9xJMDqY/xkz/jv0Jxe MMOgo00Ut1cnuyScd1obC/JgTIRJnFmToGuk9PihgCkMNRSM7foyg8qYi ra/Ft3lQlZDbxzvLY6Euo4xschTv6pYVZYZ03GkwqUPAlE0HatBGOGQfh Hpfyg9+JmneyxbNuWHTviVrDajfWKtEeaQbJNuh1yDiir40oi53WfpQWi QEIEVeaUsIILnxfhQ45K1GoDvVPrVmFPrhzf4q4ZowOpOQovTBkWXzEjA A==; X-IronPort-AV: E=McAfee;i="6500,9779,10592"; a="410930540" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="410930540" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2023 05:27:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10592"; a="722655367" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="722655367" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.105]) by fmsmga008.fm.intel.com with ESMTP; 17 Jan 2023 05:27:25 -0800 Date: Tue, 17 Jan 2023 21:19:37 +0800 From: Chao Peng To: Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@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 , Arnd Bergmann , Naoya Horiguchi , Miaohe Lin , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "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, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, wei.w.wang@intel.com Subject: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM Message-ID: <20230117131937.GD273037@chaop.bj.intel.com> Reply-To: Chao Peng References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 14, 2023 at 12:37:59AM +0000, Sean Christopherson wrote: > On Fri, Dec 02, 2022, Chao Peng wrote: > > This patch series implements KVM guest private memory for confidential > > computing scenarios like Intel TDX[1]. If a TDX host accesses > > TDX-protected guest memory, machine check can happen which can further > > crash the running host system, this is terrible for multi-tenant > > configurations. The host accesses include those from KVM userspace like > > QEMU. This series addresses KVM userspace induced crash by introducing > > new mm and KVM interfaces so KVM userspace can still manage guest memory > > via a fd-based approach, but it can never access the guest memory > > content. > > > > The patch series touches both core mm and KVM code. I appreciate > > Andrew/Hugh and Paolo/Sean can review and pick these patches. Any other > > reviews are always welcome. > > - 01: mm change, target for mm tree > > - 02-09: KVM change, target for KVM tree > > A version with all of my feedback, plus reworked versions of Vishal's selftest, > is available here: > > git@github.com:sean-jc/linux.git x86/upm_base_support > > It compiles and passes the selftest, but it's otherwise barely tested. There are > a few todos (2 I think?) and many of the commits need changelogs, i.e. it's still > a WIP. Thanks very much for doing this. Almost all of your comments are well received, except for two cases that need more discussions which have replied individually. > > As for next steps, can you (handwaving all of the TDX folks) take a look at what > I pushed and see if there's anything horrifically broken, and that it still works > for TDX? I have integrated this into my local TDX repo, with some changes (as I replied individually), the new code basically still works with TDX. I have also asked other TDX folks to take a look. > > Fuad (and pKVM folks) same ask for you with respect to pKVM. Absolutely no rush > (and I mean that). > > On my side, the two things on my mind are (a) tests and (b) downstream dependencies > (SEV and TDX). For tests, I want to build a lists of tests that are required for > merging so that the criteria for merging are clear, and so that if the list is large > (haven't thought much yet), the work of writing and running tests can be distributed. > > Regarding downstream dependencies, before this lands, I want to pull in all the > TDX and SNP series and see how everything fits together. Specifically, I want to > make sure that we don't end up with a uAPI that necessitates ugly code, and that we > don't miss an opportunity to make things simpler. The patches in the SNP series to > add "legacy" SEV support for UPM in particular made me slightly rethink some minor > details. Nothing remotely major, but something that needs attention since it'll > be uAPI. > > I'm off Monday, so it'll be at least Tuesday before I make any more progress on > my side. Appreciate your effort. As for the next steps, if you see something we can do parallel, feel free to let me know. Thanks, Chao