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 049B5EB64DD for ; Fri, 23 Jun 2023 14:43:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7669E8D0002; Fri, 23 Jun 2023 10:43:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 716268D0001; Fri, 23 Jun 2023 10:43:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5910A8D0002; Fri, 23 Jun 2023 10:43:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 480158D0001 for ; Fri, 23 Jun 2023 10:43:21 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EE542140292 for ; Fri, 23 Jun 2023 14:43:20 +0000 (UTC) X-FDA: 80934280560.25.B784F6A Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf08.hostedemail.com (Postfix) with ESMTP id 079FE160023 for ; Fri, 23 Jun 2023 14:43:18 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=jcyqyMG1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of isaku.yamahata@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=isaku.yamahata@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687531399; 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=YCmF5COxqcBz+bGliJVhA6+1kR4LAcgvJJb20tO8jM8=; b=5dcNE739khh9j2ZyJzYnwwulDRn+Wb6QsCTcAVPX+ZswDTu9GZXuqwpLqIgvENdKUjYLbP bU1eAwj5JRdGTjC3fCn4jdzzF04wQdc/5AgWH3+02p1V8aswI4aulfRJ0SGPDS2BWj+4NN vbDFx8/c/ZctO89ng2FURjlspfgX1r0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=jcyqyMG1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of isaku.yamahata@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=isaku.yamahata@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687531399; a=rsa-sha256; cv=none; b=KfejN4NA162PIruaWZ/c5XbVE3WG1wntPLdH9p6li1Bl+tWw+JGQK/M3EEid7dD3tta5cZ hAi+O++cUDV9Ric0brXMkKnD5gZj48lK8Z5hV1rOzGkwvu3QP9qTpTUbv5qGqtOtCFif9V uXQpHq+HXx54P1edvxKKEvOWlCs5+pA= Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1b512309c86so5615645ad.1 for ; Fri, 23 Jun 2023 07:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687531397; x=1690123397; 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=YCmF5COxqcBz+bGliJVhA6+1kR4LAcgvJJb20tO8jM8=; b=jcyqyMG1wIs6GJGoo7I3pPCED9Krx2Vaj0waG5amzO4Ns1tqpiLZ9M/qlewBCF4gwz UGpn5RATeeCn54m9iuWWnOHqdwVJohXON9PmlJ5ZSBkCAxiEo5W1nYwc8E0r3gVT5cFK A11zigd3kveLCiwk56rR87HO1BHKWrmp/nBeKbgwvxwQ/SMYbeDMNaLjMQ9vuWeMDeFm IkWJdGZbRiUjPYr1YGV7ik7GXEH+/CcnBLL01ZXHG69uzW+C4jGZrqx8M3tx3j+wo4a1 RubQq84ZpE9WmTCW4EnIXYVre4n9nXZAk4i1zxrd4tN/zFy/HbHXC0hMpXspLbZyr3Ye skwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687531397; x=1690123397; 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=YCmF5COxqcBz+bGliJVhA6+1kR4LAcgvJJb20tO8jM8=; b=ll9orMSSRhfPDDuASTjuLP/DF+gLqFmFOci6xfnHEY3zfVS2kpmQZM0Wrvm0/2OLPM AwLKEMMXW6kUwnwVuq7/sn1a4MM3SIoBz88gMr/zhffg7xDA36AHgPEaJnGQYo+LKl56 OvfjyqqEi4V9lC/mBuiTS/2f35BhUzW4gOKLle8JnGh8bxiSk3DjoAG/LB8/kkCyQMpO UtfvwyDTWkc9hZ3x2O4/K7C1byFl1VI1nyzm87EHS4/dPBe5ZUpLJp8s7b88+ks/GXbR Iedv1Y7S6I8Lp4YuwPktCpRc6Tljdo1FTO0Ys1lTYAEWRA+rEc/ZmYkWnh4BAtfjQcPJ ljqQ== X-Gm-Message-State: AC+VfDzSBeOSMVMS5+CyPdZfiaXxDOw4PfyKkxxh7v6BiQpJ6iron8Bo w1XPUH69G0D35D5MJCb/VRI= X-Google-Smtp-Source: ACHHUZ7ua2+VdjpIoG2bin7SPKhD7svUhBDP+s0RbDt8MG94CNs7CI3NKjv+L7lHnuAnF8fpRsO3Zg== X-Received: by 2002:a17:902:d4c9:b0:1b6:6dc8:edeb with SMTP id o9-20020a170902d4c900b001b66dc8edebmr19631665plg.21.1687531397261; Fri, 23 Jun 2023 07:43:17 -0700 (PDT) Received: from localhost ([192.55.54.50]) by smtp.gmail.com with ESMTPSA id jn9-20020a170903050900b001b19d14a3d5sm7309227plb.68.2023.06.23.07.43.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jun 2023 07:43:16 -0700 (PDT) Date: Fri, 23 Jun 2023 07:43:15 -0700 From: Isaku Yamahata To: "Huang, Kai" Cc: "isaku.yamahata@gmail.com" , "tglx@linutronix.de" , "liam.merwick@oracle.com" , "tobin@ibm.com" , "alpergun@google.com" , "Luck, Tony" , "jmattson@google.com" , "Lutomirski, Andy" , "ak@linux.intel.com" , "pbonzini@redhat.com" , "kvm@vger.kernel.org" , "srinivas.pandruvada@linux.intel.com" , "slp@redhat.com" , "dovmurik@linux.ibm.com" , "michael.roth@amd.com" , "peterz@infradead.org" , "linux-kernel@vger.kernel.org" , "pgonda@google.com" , "thomas.lendacky@amd.com" , "rientjes@google.com" , "Wang, Zhi A" , "x86@kernel.org" , "bp@alien8.de" , "Annapurve, Vishal" , "dgilbert@redhat.com" , "Christopherson,, Sean" , "vkuznets@redhat.com" , "marcorr@google.com" , "vbabka@suse.cz" , "ashish.kalra@amd.com" , "linux-coco@lists.linux.dev" , "nikunj.dadhania@amd.com" , "Rodel, Jorg" , "mingo@redhat.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "hpa@zytor.com" , "kirill@shutemov.name" , "jarkko@kernel.org" , "ardb@kernel.org" , "linux-crypto@vger.kernel.org" , "linux-mm@kvack.org" , "dave.hansen@linux.intel.com" Subject: Re: [PATCH RFC v9 04/51] KVM: x86: Determine shared/private faults using a configurable mask Message-ID: <20230623144315.GC3436214@ls.amr.corp.intel.com> References: <20230612042559.375660-5-michael.roth@amd.com> <20230614164709.GT2244082@ls.amr.corp.intel.com> <20230620202841.7qizls3u3kcck45g@amd.com> <20230620211845.GV2244082@ls.amr.corp.intel.com> <20230621230031.37hdnymbjzwjgbo2@amd.com> <20230622153229.vjkrzi6rgiolstns@amd.com> <25037dfe969698dd109daee8c6dbe0d08a874a08.camel@intel.com> <20230622233906.GA3436214@ls.amr.corp.intel.com> <5ec0664fe81df54019ef5934f2dc6dfadf1d649c.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5ec0664fe81df54019ef5934f2dc6dfadf1d649c.camel@intel.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 079FE160023 X-Stat-Signature: 5rawju1qq9yfg56ffdrzwonumik9j6xm X-Rspam-User: X-HE-Tag: 1687531398-282288 X-HE-Meta: U2FsdGVkX19GkMohXHsGfLSuMDk1clVXol5IUJ8uQbMMKk/h1uD25BU9KxHjCBlkuWlGtO/s9a64KPws1aUZa0iCcW+ms4FNVQ2jSPgqnQu6PP9Qjh8Ls25XaVUsEqXXIY7BcPv0NgzRi1NkxVPQkbhA7/7fjRLKRKPaUSBJff3PW63d95urZD6+bkYzRgWmUmMhFtNNbyn3I9tGaAH+wW4pCkx2e8m9TnPCJb2zvmYu3jQ97V5mwF7LMnog45g7qaO3vl0FF2OUPkH2O66k/Z54UR0/CIPHKMct42P3KqQqk0CYEOBT6/lD0RK7c0ud5WBe5dUfvh0QHgwfS59MHkOeWSjBntlJHXpajJrQB+D6XzYEXdfrECQ3iJJxz7B5kkxR3Dl+oEE+7GySeETAC6kJAQ6VK0sNFLorkVRn8CCkIVfjL4zABXamF0KLL/Q8sAO04jQd7GMLw1/nq02O7hpYPNXKo0oRElDXwGXBMog9S6f9z6tQRlcfdJylATah8Q2/FN+z8c37b7QW3oRse7J7etLr0tdSpNTYY20uwMMI7i0JwrImqYzOxveHgMJ1cFgZkajycEC5ENxTkrfZ0sWClTxZPUXonACQcO+oWXugoposcyMhEonI5itvQwti4BND6QP/lMCwcknBVsZuVzzqxwpk7schSuRaxSz+TsRo1y2CRoGlk2vqIeT6UHPMLoHkrCCHcNupVTR9YpDNX1XE5TuDJVtb0BxRibl+PfubrBULErKAOUUWTnW2RhB66B/ZbzLv58n0PQSpEwUJ6x2edoDevjf+T47pTlQnd5BKHP6ON2QJVGjwQnB/f0BGrmCWF+3eYs5lPWMFQxUYDisTuKzpEwMVNZhAyQFDyz1pGYS5u/l9JyQgKoSetUqBtTJaZ6jljoW3bLOx5/yL3sQF0yju/WCH1qo7dWxWnwpFnorS8BOvo3AGQsblMPbYf8+9C0vMpYSmiYG6MsB FaiTKonq FILfCxRiLoWcL2Z81F58cOdDbo0jX7yfU0RzfYC1x/oT7I4EXCGOrNRQIT/5EJ+7E63Ua725UKnHJEB7IT8Y2TmJxicoNgedE7plbdAbzuOIxMPL/Cx1lRSyraW8nz51ITaspyDM9VopSiyQwcAKD4uhgoQV34C6iCVXvyXUTXRnrxvcVhST5BLg5NgdXwrR7lePUkrlMxNWx6ot1emoKumtnEqyYxc56zo0uUCht43VJxYMNB+6Z8JxegktITpLcw9/EFQH6LpSV1WpkITJiRdLNr9xijoFx3yKblVtdAsuwZGM8wB47PeXxx7OHf8vP9EoKN0g1W3lAMqkhbfEKd7yJt7dx05HrZ6A1MV9ITlAgeFzS3k9pQnt+a5TYiVTZi6GpBtfDapfivzeycWI8aDpK/jF+XPIo21tfAxl+NZkOe0PuixqeapvHFahKZ1nt+n37vx2q7v36u2OR1I6QkpzSmeY2j2/7W1MUcxCAvcZTzEDUPMD3av1p1/iT6WE6Gq59MaUlNTz9l2YOrapiOBH9l3Sl46KeRFUUBO8HwUM5m32EvkLNn2/jpnKxA4j8sa/OX9EYruTvIZs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000045, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jun 22, 2023 at 11:52:56PM +0000, "Huang, Kai" wrote: > On Thu, 2023-06-22 at 16:39 -0700, Isaku Yamahata wrote: > > On Thu, Jun 22, 2023 at 10:31:08PM +0000, > > "Huang, Kai" wrote: > > > > > > If there are better ways to handle *how* > > > > that's done I don't have any complaints there, but moving/adding bits > > > > to GPA/error_flags after fault time just seems unecessary to me when > > > > fault->is_private field can serve that purpose just as well. > > > > > > Perhaps you missed my point. My point is arch.mmu_private_fault_mask and > > > arch.gfn_shared_mask seem redundant because the logic around them are exactly > > > the same. I do believe we should have fault->is_private passing to the common > > > MMU code. > > > > > > In fact, now I am wondering why we need to have "mmu_private_fault_mask" and > > > "gfn_shared_mask" in _common_ KVM MMU code. We already have enough mechanism in > > > KVM common code: > > > > > > 1) fault->is_private > > > 2) kvm_mmu_page_role.private > > > 3) an Xarray to tell whether a GFN is private or shared > > > > > > I am not convinced that we need to have "mmu_private_fault_mask" and > > > "gfn_shared_mask" in common KVM MMU code. Instead, they can be in AMD and > > > Intel's vendor code. > > > > > > Maybe it makes sense to have "gfn_shared_mask" in the KVM common code so that > > > the fault handler can just strip away the "shared bit" at the very beginning (at > > > least for TDX), but for the rest of the time I think we should already have > > > enough infrastructure to handle private/shared mapping. > > > > > > Btw, one minor issue is, if I recall correctly, for TDX the shared bit must be > > > applied to the GFN for shared mapping in normal EPT. I guess AMD doesn't need > > > that for shared mapping. So "gfn_shared_mask" maybe useful in this case, but > > > w/o it I believe we can also achieve in another way via vendor callback. > > > > > > "2) kvm_mmu_page_role.private" above has different meaning. > > > > a). The fault is private or not. > > b). page table the fault handler is walking is private or conventional. > > > > a.) is common for SNP, TDX and PROTECTED_VM. It makes sense in > > kvm_mmu_do_page_fault() and __kvm_faultin_pfn(). After kvm_faultin_pfn(), the > > fault handler can mostly forget it for SNP and PROTECTED_VM. (large page > > adjustment needs it, though.) This is what we're discussing in this thread. > > > > b.) is specific to TDX. TDX KVM MMU introduces one more page table. > > > > > > I don't buy the last sentence. Even it's not necessarily for AMD from > hardware's perspective, but the concept remains true for AMD too. So why cannot > we use it for AMD? We can use it for AMD. Let me rephrase it. TDX only uses it now. SEV-SNP may or may not use it at their option. -- Isaku Yamahata