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 98161C433FE for ; Tue, 8 Nov 2022 00:41:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA3146B0071; Mon, 7 Nov 2022 19:41:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D2C6E8E0002; Mon, 7 Nov 2022 19:41:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BCDCE8E0001; Mon, 7 Nov 2022 19:41:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AC9E76B0071 for ; Mon, 7 Nov 2022 19:41:45 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8226FA45FF for ; Tue, 8 Nov 2022 00:41:45 +0000 (UTC) X-FDA: 80108422170.03.FA0B7E7 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf15.hostedemail.com (Postfix) with ESMTP id 2CD21A0007 for ; Tue, 8 Nov 2022 00:41:44 +0000 (UTC) Received: by mail-pj1-f54.google.com with SMTP id m6-20020a17090a5a4600b00212f8dffec9so11985666pji.0 for ; Mon, 07 Nov 2022 16:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=f4mzRLoeQ48oTB+HkMbcCJtw/jiM85vqqZbEZxBfoPw=; b=jNkxWtUCmfG2zrTTxPn7pXbOfg8WgaPlJ/TmU5ho83sUA7wRBlAIcBc7kM55RSxQfz O9KfA73Mo41SgYIU/6ztTbPkU74vvXbXhLfeG7if5q08aJsers9rlUH+IcWmJCieuLMB gbuRsARLxBA75WAmVf89DtRjcvxlhjWPeHEm1phJr7YMFgREvRfd7mjbZlBzS7taId+K Z7st3hqeZybjF8yrj+ldtMVMB0xM9NnHcs5o8YhIkyHPPFq825EvPYOoBldCw5yPpP7F HggWHyUW5wTNWT3I1EIWRCFsjLeBu0Rg8w3vv3t1/ntNPIXw9J4HHOSpeRyqwRkQq+gR i+bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=f4mzRLoeQ48oTB+HkMbcCJtw/jiM85vqqZbEZxBfoPw=; b=LMlloHwPMge7XDRdCUDjdkrLnFg7DhhhzEKTjy50O2r5UGLC1PWgfNiymRutEF+2wA 5DGf/rT8UnQp9FvGKe/ZaKZYkuc36hab+bFxsNuosalRDedVPXub7Lsl/bmXwijxrTKi Rrvi7mLCjH8ZwTBbOXyHrKJyvOzyM3ID/Tz2E+H9J+qT2msGeSbYd2EvsWGwqyzOIr6o zVMGEuLe2cEY/85nPgkaWLH2dU94ma8F0S1Z2AzZRRW5eQXyIPr3oIuPWVODyzPVW6Sk wz4/iBVI52DNsUilHTnmgY7MjFgegrazCAeyUXu+tXXYi4F0jvB26lMI0rdXcJ5quCtL GGtw== X-Gm-Message-State: ACrzQf2fu51BVbiLmSLsgnoZivlUa/hMPeLX8ah4gxjxvLqeB3871DKY gkrXByYre+M7Rdjs0OCk2y4= X-Google-Smtp-Source: AMsMyM5LfnPnZCR4C8YhXTlekjNtWQ4eT83Y8KqrHrr59s3tox+2We3eFncHxrM2kJlqZycKqKXg3A== X-Received: by 2002:a17:903:1109:b0:179:d220:1f55 with SMTP id n9-20020a170903110900b00179d2201f55mr36061753plh.42.1667868104037; Mon, 07 Nov 2022 16:41:44 -0800 (PST) Received: from localhost ([192.55.54.55]) by smtp.gmail.com with ESMTPSA id s4-20020a170902ea0400b001837463f654sm5535395plg.251.2022.11.07.16.41.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Nov 2022 16:41:43 -0800 (PST) Date: Mon, 7 Nov 2022 16:41:41 -0800 From: Isaku Yamahata To: Vishal Annapurve 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 , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , 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 , 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, Muchun Song , wei.w.wang@intel.com, isaku.yamahata@gmail.com Subject: Re: [PATCH v9 0/8] KVM: mm: fd-based approach for supporting KVM Message-ID: <20221108004141.GF1063309@ls.amr.corp.intel.com> References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667868105; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=f4mzRLoeQ48oTB+HkMbcCJtw/jiM85vqqZbEZxBfoPw=; b=r9XBIcIm+DgVFRNMxGWXwA7lkuDim2fVA5QuHFBCeOkhp5XhOBVAy4gW+tX1zXEb5PROUE NOLDm4u3xJ3cVMaNVxeClwDGw6M8HdnBOvMtS/V6I64vbXqboYSKi7wv8jjdAAVXIOHtd6 WO4VL78XW700AJRtXJt/rrALBHWt5ts= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jNkxWtUC; spf=pass (imf15.hostedemail.com: domain of isaku.yamahata@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=isaku.yamahata@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667868105; a=rsa-sha256; cv=none; b=OoyXcZ3YiS/8OFOK6dNA9RDfXnovwujtNYNMh6eC4uDarnFFeE3LgwJGFxtGA4FCgx1C0V O9tqJNckljzRmM2mLEfGEQ8WWK37F87RvKjGdgR42RyM12FNCexlhw33jzy73CmyXzR8yY MSxE7IYYnoayJKSkSmqmdvHK6liH31E= Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jNkxWtUC; spf=pass (imf15.hostedemail.com: domain of isaku.yamahata@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=isaku.yamahata@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2CD21A0007 X-Stat-Signature: 1tpyopd8ngpm7d9o7dkpnp4uwzxseq7d X-HE-Tag: 1667868104-596886 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 Thu, Nov 03, 2022 at 05:43:52PM +0530, Vishal Annapurve wrote: > On Tue, Oct 25, 2022 at 8:48 PM 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-08: KVM change, target for KVM tree > > > > Given KVM is the only current user for the mm part, I have chatted with > > Paolo and he is OK to merge the mm change through KVM tree, but > > reviewed-by/acked-by is still expected from the mm people. > > > > The patches have been verified in Intel TDX environment, but Vishal has > > done an excellent work on the selftests[4] which are dedicated for this > > series, making it possible to test this series without innovative > > hardware and fancy steps of building a VM environment. See Test section > > below for more info. > > > > > > Introduction > > ============ > > KVM userspace being able to crash the host is horrible. Under current > > KVM architecture, all guest memory is inherently accessible from KVM > > userspace and is exposed to the mentioned crash issue. The goal of this > > series is to provide a solution to align mm and KVM, on a userspace > > inaccessible approach of exposing guest memory. > > > > Normally, KVM populates secondary page table (e.g. EPT) by using a host > > virtual address (hva) from core mm page table (e.g. x86 userspace page > > table). This requires guest memory being mmaped into KVM userspace, but > > this is also the source where the mentioned crash issue can happen. In > > theory, apart from those 'shared' memory for device emulation etc, guest > > memory doesn't have to be mmaped into KVM userspace. > > > > This series introduces fd-based guest memory which will not be mmaped > > into KVM userspace. KVM populates secondary page table by using a > > With no mappings in place for userspace VMM, IIUC, looks like the host > kernel will not be able to find the culprit userspace process in case > of Machine check error on guest private memory. As implemented in > hwpoison_user_mappings, host kernel tries to look at the processes > which have mapped the pfns with hardware error. > > Is there a modification needed in mce handling logic of the host > kernel to immediately send a signal to the vcpu thread accessing > faulting pfn backing guest private memory? mce_register_decode_chain() can be used. MCE physical address(p->mce_addr) includes host key id in addition to real physical address. By searching used hkid by KVM, we can determine if the page is assigned to guest TD or not. If yes, send SIGBUS. kvm_machine_check() can be enhanced for KVM specific use. This is before memory_failure() is called, though. any other ideas? -- Isaku Yamahata