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 74D1CC61DA4 for ; Thu, 16 Feb 2023 09:42:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229633AbjBPJmt (ORCPT ); Thu, 16 Feb 2023 04:42:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229796AbjBPJme (ORCPT ); Thu, 16 Feb 2023 04:42:34 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FB0C22DC9 for ; Thu, 16 Feb 2023 01:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676540480; h=from:from: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; bh=Gmwi3nEDJwaAff3Fc8Gdw19GfxhLDRlC4Hp/kbYrQqc=; b=QUm924d1eQ4/YeSGNU+9zftH1vyBIPQ3uswRg69oerBJHX2NQCCPiVlHOfWfktArNep4JC 0IkDs6vNmWi5TeWt0o4YQsXQDJbBg/wwQJ8kw+ka8d3rmi39nhEH7DyaOkfT5TorvXMV3W BSsz6vzYEBygMTXdI5RX8BpQOwGD6gw= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-589-8_Eg0DbYOcO2n0Q-euKUHg-1; Thu, 16 Feb 2023 04:41:18 -0500 X-MC-Unique: 8_Eg0DbYOcO2n0Q-euKUHg-1 Received: by mail-wm1-f69.google.com with SMTP id j20-20020a05600c1c1400b003dc5dd44c0cso596253wms.8 for ; Thu, 16 Feb 2023 01:41:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Gmwi3nEDJwaAff3Fc8Gdw19GfxhLDRlC4Hp/kbYrQqc=; b=u8aSc0YJozzQaWNRl3n8teJB8dlqbbHrWX1NYDARXo9q5zF3wpKlo3wl54CE221fCn ykiWlS6BLq/+nZYm2Qs/N4fHgQ+d/t5hjEulCRvP/UxI4FJfGGG1cBmU85WCczMf75m6 UAVQtXUCrLl1aI9z9IxZJqnCdmNfjBKWBKklWhNplxrdUpjrQrGP+ARbWEYPuWOGWNve baHip2T6ZGBJH+/VgBpS8jLMI/U/FG8es0rOb3Nj+vB3pwKHgPz2c41Xfli6orQ/0yRf a7hqx4BdgxsyyX7KtFnow4PbbUCdiyZNuKzedWbM8c22m7kRbPFeb9vP65pM6Ty+6yn0 O/HA== X-Gm-Message-State: AO0yUKXnQJVfeFcO0Ih92fi341QCwEMbo66GqUkTuc1Wp/rFrXZKrZ4y yypxCr6gO5hn36ZU1ALvdOr76RMk6UF6+3dtT66ccMa/y9oVv6yrScwEuMHQjB/n9D05F5MB+f6 Bud4dAvxqk2fIvZ4kkkkKZA== X-Received: by 2002:a05:600c:43d2:b0:3e1:f8af:7942 with SMTP id f18-20020a05600c43d200b003e1f8af7942mr4417098wmn.22.1676540477730; Thu, 16 Feb 2023 01:41:17 -0800 (PST) X-Google-Smtp-Source: AK7set/oggqqqV4UfbebLA50a7kFC2t5aIQUzgDU4Y/+rLroQMqzr7b1jBFCFplQuftcMkUVk4L02g== X-Received: by 2002:a05:600c:43d2:b0:3e1:f8af:7942 with SMTP id f18-20020a05600c43d200b003e1f8af7942mr4417078wmn.22.1676540477379; Thu, 16 Feb 2023 01:41:17 -0800 (PST) Received: from ?IPV6:2003:cb:c708:bc00:2acb:9e46:1412:686a? (p200300cbc708bc002acb9e461412686a.dip0.t-ipconnect.de. [2003:cb:c708:bc00:2acb:9e46:1412:686a]) by smtp.gmail.com with ESMTPSA id j26-20020a05600c1c1a00b003df245cd853sm1211974wms.44.2023.02.16.01.41.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Feb 2023 01:41:16 -0800 (PST) Message-ID: <62c84fa8-d7c4-5163-fe1e-f2c7e5a2c7aa@redhat.com> Date: Thu, 16 Feb 2023 10:41:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM Content-Language: en-US To: Mike Rapoport , Chao Peng 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 , Sean Christopherson , 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 , 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, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, wei.w.wang@intel.com References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On 16.02.23 06:13, Mike Rapoport wrote: > Hi, > > On Fri, Dec 02, 2022 at 02:13:38PM +0800, 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. > > Sorry for jumping late. > > Unless I'm missing something, hibernation will also cause an machine check > when there is TDX-protected memory in the system. When the hibernation > creates memory snapshot it essentially walks all physical pages and saves > their contents, so for TDX memory this will trigger machine check, right? I recall bringing that up in the past (also memory access due to kdump, /prov/kcore) and was told that the main focus for now is preventing unprivileged users from crashing the system, that is, not mapping such memory into user space (e.g., QEMU). In the long run, we'll want to handle such pages also properly in the other events where the kernel might access them. -- Thanks, David / dhildenb