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 13341C63797 for ; Tue, 17 Jan 2023 14:33:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230405AbjAQOdF (ORCPT ); Tue, 17 Jan 2023 09:33:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231955AbjAQOdA (ORCPT ); Tue, 17 Jan 2023 09:33:00 -0500 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BD8D3C2B3 for ; Tue, 17 Jan 2023 06:32:58 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id m6so47347557lfj.11 for ; Tue, 17 Jan 2023 06:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7yhLGsprr4iGbKzba+JN1VXXF3TeC3cedN8+F9epKwY=; b=BWKfON0ONcZ0E/73kUupX7eOFbsTtnf5zb0RLvmJL0YAhZl6oEvSZL3c/NoN0rNReU TIh5gjrwA6Bj/3YkDzJiL+Gls11L2i8ze76yowGZvwzeuvcwTzbo+PdTF5RRopZcOu67 rqK/5DXAz0Cu8iK48baqurCP3Q8SHLQ3+La3MGi7OSiOLM50rap2pv9+NepuA7fvXVkZ JbAIYTYmlyf3SaXzCtregYhzAezlqMgzZgLa7aRWrX3Ls8Vi1NxO2mSedec1z7gAhtZm CjRS/N1ff7V0fQ/RSJMzu/O50kqFBmQcx8Ep1MMWXZfAdBITG7gqeNKqSuVwb7ryK8UD 4kmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7yhLGsprr4iGbKzba+JN1VXXF3TeC3cedN8+F9epKwY=; b=sUZj9BU3x/XOyGz0+Sb6ExlDW3yXvTEhUdfO7tZbMiSKcREW/lfjHCxjaAmC2JwIBq rVcyzxZjXU8Dx4Gd0g+5hVyZ6sbdOiQxs4p2xF6hVdwDGMzt7Q5T9KHtNofIHmfl6s6+ yt+hP6O5CJ9N2kJyhwT79fVAJ6elT9oJE47s2I0jzHPwcqqZcTjSqa3u618lHFQZxJnM qmUafCoN28jN1pCuK80BcoauRD8NCRYoAm57cXBlNifEi+VVAB/b3oz5N8hhIfRtddxb yjStGNRTugUwqEtR9/D4EyR5qO7Vc7pM4/9a93M/2cRaJnuDULx0BrdXLVXyMbERm20c ANqA== X-Gm-Message-State: AFqh2kqH4koTv9+Z13h5GM9Pb55E7payHmOGzuDTEoZWhS2dzSKgPJVp tNwNb57OCq5/AKgL7M3exSun7y42PRgOPggbKKZfYg== X-Google-Smtp-Source: AMrXdXsPS/EHa9ll4sjoGtdooNfVuEuQvNaydQDhDfaDKMnyvvZ6mWGGNpzl0ThBONl2d+/I1rYOtZu/xqsiIx9Cz3Y= X-Received: by 2002:a05:6512:3b9b:b0:4d5:850a:8330 with SMTP id g27-20020a0565123b9b00b004d5850a8330mr128086lfv.665.1673965976657; Tue, 17 Jan 2023 06:32:56 -0800 (PST) MIME-Version: 1.0 References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> In-Reply-To: From: Fuad Tabba Date: Tue, 17 Jan 2023 14:32:19 +0000 Message-ID: Subject: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM To: Sean Christopherson Cc: Chao Peng , 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 , Michael Roth , mhocko@suse.com, wei.w.wang@intel.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org Hi Sean, On Sat, Jan 14, 2023 at 12:38 AM 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. > > 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? > > Fuad (and pKVM folks) same ask for you with respect to pKVM. Absolutely no rush > (and I mean that). Thanks for sharing this. I've had a look at the patches, and have ported them to work with pKVM. At a high level, the new interface seems fine and it works with the arm64/pKVM port. I have a couple of comments regarding some of the details, but they can wait until v11 is posted. Cheers, /fuad > 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. > > Thanks!