From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Upton Date: Mon, 12 Dec 2022 18:17:36 +0000 Subject: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role In-Reply-To: References: <20221208193857.4090582-1-dmatlack@google.com> <20221208193857.4090582-2-dmatlack@google.com> <22fe2332-497e-fe30-0155-e026b0eded97@intel.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Dec 12, 2022 at 05:39:38PM +0000, Sean Christopherson wrote: > On Fri, Dec 09, 2022, David Matlack wrote: > > On Fri, Dec 9, 2022 at 9:25 AM Oliver Upton wrote: > > > > > > On Fri, Dec 09, 2022 at 10:37:47AM +0800, Yang, Weijiang wrote: > > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > > > > index 4d188f056933..f375b719f565 100644 > > > > > --- a/arch/x86/kvm/mmu/mmu.c > > > > > +++ b/arch/x86/kvm/mmu/mmu.c > > > > > @@ -5056,7 +5056,7 @@ kvm_calc_cpu_role(struct kvm_vcpu *vcpu, const struct kvm_mmu_role_regs *regs) > > > > > union kvm_cpu_role role = {0}; > > > > > role.base.access = ACC_ALL; > > > > > - role.base.smm = is_smm(vcpu); > > > > > + role.base.as_id = is_smm(vcpu); > > > > > > > > I'm not familiar with other architectures, is there similar conception as > > > > x86 smm mode? > > > > The notion of address spaces is already existing architecture-neutral > > concept in KVM (e.g. see uses of KVM_ADDRESS_SPACE_NUM in > > virt/kvm/kvm_main.c), although SMM is the only use-case I'm aware of. > > Yes, SMM is currently the only use-case. > > > Architectures that do not use multiple address spaces will just leave > > as_id is as always 0. > > My preference would be to leave .smm in x86's page role. IMO, defining multiple > address spaces to support SMM emulation was a mistake that should be contained to > SMM, i.e. should never be used for any other feature. And with CONFIG_KVM_SMM, > even x86 can opt out. +1 I don't think something is architecture-neutral by virtue of it existing in virt/kvm/*. > Emulating something like TrustZone or EL3 would be quite similar. /me shudders I know it is for the sake of discussion, but for posterity: please no! -- Best, Oliver 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1BF7C4332F for ; Mon, 12 Dec 2022 18:17:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0ECBD4B97F; Mon, 12 Dec 2022 13:17:52 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@linux.dev Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oajV0pFRTBnj; Mon, 12 Dec 2022 13:17:50 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9339E4B947; Mon, 12 Dec 2022 13:17:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 841204B943 for ; Mon, 12 Dec 2022 13:17:49 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcKeldxpncat for ; Mon, 12 Dec 2022 13:17:48 -0500 (EST) Received: from out-142.mta0.migadu.com (out-142.mta0.migadu.com [91.218.175.142]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 2E6424B93F for ; Mon, 12 Dec 2022 13:17:48 -0500 (EST) Date: Mon, 12 Dec 2022 18:17:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1670869065; 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: in-reply-to:in-reply-to:references:references; bh=a9Id/GViUZAo9zRK46q4+Dpl7Meohnepciy9W7jEdXE=; b=fE9WRJWJ8x2O7m5Gd09O9tkOQ7F6YcPGusN7I2RL/OS2Rivtpch9NFEYCzf1v/E4NtmVv2 FLeZtByUzGij7gtzYD2aTQDXJlv0CdgVRUMS8Aas8M3DkxaG3WKtYQ+564OB8J8mbI1PHJ LneF0SsRvU08OUrrniHIKR30jQw8fVg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Subject: Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role Message-ID: References: <20221208193857.4090582-1-dmatlack@google.com> <20221208193857.4090582-2-dmatlack@google.com> <22fe2332-497e-fe30-0155-e026b0eded97@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT Cc: Anshuman Khandual , Hugh Dickins , Paul Walmsley , "Yang, Weijiang" , "Amit, Nadav" , Ben Gardon , "linux-riscv@lists.infradead.org" , "kvmarm@lists.cs.columbia.edu" , Yu Zhao , Marc Zyngier , Huacai Chen , "Matthew Wilcox \(Oracle\)" , Aleksandar Markovic , Krish Sadhukhan , Palmer Dabbelt , Mingwei Zhang , Albert Ou , xu xin , Arnd Bergmann , "Liam R. Howlett" , "kvm@vger.kernel.org" , Atish Patra , David Matlack , Suren Baghdasaryan , Vlastimil Babka , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "linux-mips@vger.kernel.org" , Colin Cross , "kvm-riscv@lists.infradead.org" , Paolo Bonzini , Andrew Morton X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Mon, Dec 12, 2022 at 05:39:38PM +0000, Sean Christopherson wrote: > On Fri, Dec 09, 2022, David Matlack wrote: > > On Fri, Dec 9, 2022 at 9:25 AM Oliver Upton wrote: > > > > > > On Fri, Dec 09, 2022 at 10:37:47AM +0800, Yang, Weijiang wrote: > > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > > > > index 4d188f056933..f375b719f565 100644 > > > > > --- a/arch/x86/kvm/mmu/mmu.c > > > > > +++ b/arch/x86/kvm/mmu/mmu.c > > > > > @@ -5056,7 +5056,7 @@ kvm_calc_cpu_role(struct kvm_vcpu *vcpu, const struct kvm_mmu_role_regs *regs) > > > > > union kvm_cpu_role role = {0}; > > > > > role.base.access = ACC_ALL; > > > > > - role.base.smm = is_smm(vcpu); > > > > > + role.base.as_id = is_smm(vcpu); > > > > > > > > I'm not familiar with other architectures, is there similar conception as > > > > x86 smm mode? > > > > The notion of address spaces is already existing architecture-neutral > > concept in KVM (e.g. see uses of KVM_ADDRESS_SPACE_NUM in > > virt/kvm/kvm_main.c), although SMM is the only use-case I'm aware of. > > Yes, SMM is currently the only use-case. > > > Architectures that do not use multiple address spaces will just leave > > as_id is as always 0. > > My preference would be to leave .smm in x86's page role. IMO, defining multiple > address spaces to support SMM emulation was a mistake that should be contained to > SMM, i.e. should never be used for any other feature. And with CONFIG_KVM_SMM, > even x86 can opt out. +1 I don't think something is architecture-neutral by virtue of it existing in virt/kvm/*. > Emulating something like TrustZone or EL3 would be quite similar. /me shudders I know it is for the sake of discussion, but for posterity: please no! -- Best, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-222.mta0.migadu.com (out-222.mta0.migadu.com [91.218.175.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5982753B9 for ; Mon, 12 Dec 2022 19:34:24 +0000 (UTC) Date: Mon, 12 Dec 2022 18:17:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1670869065; 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: in-reply-to:in-reply-to:references:references; bh=a9Id/GViUZAo9zRK46q4+Dpl7Meohnepciy9W7jEdXE=; b=fE9WRJWJ8x2O7m5Gd09O9tkOQ7F6YcPGusN7I2RL/OS2Rivtpch9NFEYCzf1v/E4NtmVv2 FLeZtByUzGij7gtzYD2aTQDXJlv0CdgVRUMS8Aas8M3DkxaG3WKtYQ+564OB8J8mbI1PHJ LneF0SsRvU08OUrrniHIKR30jQw8fVg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Cc: David Matlack , "Yang, Weijiang" , Paolo Bonzini , Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , Paul Walmsley , Palmer Dabbelt , Albert Ou , Andrew Morton , Anshuman Khandual , "Amit, Nadav" , "Matthew Wilcox (Oracle)" , Vlastimil Babka , "Liam R. Howlett" , Suren Baghdasaryan , Peter Xu , xu xin , Arnd Bergmann , Yu Zhao , Colin Cross , Hugh Dickins , Ben Gardon , Mingwei Zhang , Krish Sadhukhan , Ricardo Koller , Jing Zhang , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "kvmarm@lists.cs.columbia.edu" , "linux-mips@vger.kernel.org" , "kvm@vger.kernel.org" , "kvm-riscv@lists.infradead.org" , "linux-riscv@lists.infradead.org" Subject: Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role Message-ID: References: <20221208193857.4090582-1-dmatlack@google.com> <20221208193857.4090582-2-dmatlack@google.com> <22fe2332-497e-fe30-0155-e026b0eded97@intel.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT Message-ID: <20221212181736.5CcFvH_t_U16cHbJXO2Qy06OAGtKvpZ5DV44svEvHdw@z> On Mon, Dec 12, 2022 at 05:39:38PM +0000, Sean Christopherson wrote: > On Fri, Dec 09, 2022, David Matlack wrote: > > On Fri, Dec 9, 2022 at 9:25 AM Oliver Upton wrote: > > > > > > On Fri, Dec 09, 2022 at 10:37:47AM +0800, Yang, Weijiang wrote: > > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > > > > index 4d188f056933..f375b719f565 100644 > > > > > --- a/arch/x86/kvm/mmu/mmu.c > > > > > +++ b/arch/x86/kvm/mmu/mmu.c > > > > > @@ -5056,7 +5056,7 @@ kvm_calc_cpu_role(struct kvm_vcpu *vcpu, const struct kvm_mmu_role_regs *regs) > > > > > union kvm_cpu_role role = {0}; > > > > > role.base.access = ACC_ALL; > > > > > - role.base.smm = is_smm(vcpu); > > > > > + role.base.as_id = is_smm(vcpu); > > > > > > > > I'm not familiar with other architectures, is there similar conception as > > > > x86 smm mode? > > > > The notion of address spaces is already existing architecture-neutral > > concept in KVM (e.g. see uses of KVM_ADDRESS_SPACE_NUM in > > virt/kvm/kvm_main.c), although SMM is the only use-case I'm aware of. > > Yes, SMM is currently the only use-case. > > > Architectures that do not use multiple address spaces will just leave > > as_id is as always 0. > > My preference would be to leave .smm in x86's page role. IMO, defining multiple > address spaces to support SMM emulation was a mistake that should be contained to > SMM, i.e. should never be used for any other feature. And with CONFIG_KVM_SMM, > even x86 can opt out. +1 I don't think something is architecture-neutral by virtue of it existing in virt/kvm/*. > Emulating something like TrustZone or EL3 would be quite similar. /me shudders I know it is for the sake of discussion, but for posterity: please no! -- Best, Oliver 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 164EAC4332F for ; Mon, 12 Dec 2022 18:18:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2orXoET37mb9qcxpL5plnhekKslW1gS3XoQH+S+vB7Q=; b=q0qeYhk0dD3Ktb eopRdJaNggQTgGXY6WDbLzu4+PduydezGRLTbO7kyQU3BkZNyXq33PKp60WCRvDTOXK1KVOzxRVLv 5+ohoLmdw00h1HLGxgirM4RrLNMN062PSGAVH5VA8V0+2RXi3alXZB1mP0C6/3FCwb1zKTO4pyzgT kzFVIV+Jo26DNumENvb6Eu/tPKxAkjOgJHOvKxYe/nnIIpMsIScpI25mrFKx7TnXTg2+CLhiFoHp7 53FsqAbu0GuAvNt5L5SJJpYUAL2a0ZrFi+np/RMZFllFb76jcJOfg8dJaR9edbg042VBybJcmDWqg B3Rr3/RsCa5ba+IM0+Eg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4nNH-003bxE-8O; Mon, 12 Dec 2022 18:17:59 +0000 Received: from out-24.mta0.migadu.com ([2001:41d0:1004:224b::18]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4nND-003bvW-L9 for linux-riscv@lists.infradead.org; Mon, 12 Dec 2022 18:17:57 +0000 Date: Mon, 12 Dec 2022 18:17:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1670869065; 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: in-reply-to:in-reply-to:references:references; bh=a9Id/GViUZAo9zRK46q4+Dpl7Meohnepciy9W7jEdXE=; b=fE9WRJWJ8x2O7m5Gd09O9tkOQ7F6YcPGusN7I2RL/OS2Rivtpch9NFEYCzf1v/E4NtmVv2 FLeZtByUzGij7gtzYD2aTQDXJlv0CdgVRUMS8Aas8M3DkxaG3WKtYQ+564OB8J8mbI1PHJ LneF0SsRvU08OUrrniHIKR30jQw8fVg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Cc: David Matlack , "Yang, Weijiang" , Paolo Bonzini , Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , Paul Walmsley , Palmer Dabbelt , Albert Ou , Andrew Morton , Anshuman Khandual , "Amit, Nadav" , "Matthew Wilcox (Oracle)" , Vlastimil Babka , "Liam R. Howlett" , Suren Baghdasaryan , Peter Xu , xu xin , Arnd Bergmann , Yu Zhao , Colin Cross , Hugh Dickins , Ben Gardon , Mingwei Zhang , Krish Sadhukhan , Ricardo Koller , Jing Zhang , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "kvmarm@lists.cs.columbia.edu" , "linux-mips@vger.kernel.org" , "kvm@vger.kernel.org" , "kvm-riscv@lists.infradead.org" , "linux-riscv@lists.infradead.org" Subject: Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role Message-ID: References: <20221208193857.4090582-1-dmatlack@google.com> <20221208193857.4090582-2-dmatlack@google.com> <22fe2332-497e-fe30-0155-e026b0eded97@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221212_101756_167235_535AFD8B X-CRM114-Status: GOOD ( 19.95 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, Dec 12, 2022 at 05:39:38PM +0000, Sean Christopherson wrote: > On Fri, Dec 09, 2022, David Matlack wrote: > > On Fri, Dec 9, 2022 at 9:25 AM Oliver Upton wrote: > > > > > > On Fri, Dec 09, 2022 at 10:37:47AM +0800, Yang, Weijiang wrote: > > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > > > > index 4d188f056933..f375b719f565 100644 > > > > > --- a/arch/x86/kvm/mmu/mmu.c > > > > > +++ b/arch/x86/kvm/mmu/mmu.c > > > > > @@ -5056,7 +5056,7 @@ kvm_calc_cpu_role(struct kvm_vcpu *vcpu, const struct kvm_mmu_role_regs *regs) > > > > > union kvm_cpu_role role = {0}; > > > > > role.base.access = ACC_ALL; > > > > > - role.base.smm = is_smm(vcpu); > > > > > + role.base.as_id = is_smm(vcpu); > > > > > > > > I'm not familiar with other architectures, is there similar conception as > > > > x86 smm mode? > > > > The notion of address spaces is already existing architecture-neutral > > concept in KVM (e.g. see uses of KVM_ADDRESS_SPACE_NUM in > > virt/kvm/kvm_main.c), although SMM is the only use-case I'm aware of. > > Yes, SMM is currently the only use-case. > > > Architectures that do not use multiple address spaces will just leave > > as_id is as always 0. > > My preference would be to leave .smm in x86's page role. IMO, defining multiple > address spaces to support SMM emulation was a mistake that should be contained to > SMM, i.e. should never be used for any other feature. And with CONFIG_KVM_SMM, > even x86 can opt out. +1 I don't think something is architecture-neutral by virtue of it existing in virt/kvm/*. > Emulating something like TrustZone or EL3 would be quite similar. /me shudders I know it is for the sake of discussion, but for posterity: please no! -- Best, Oliver _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 390BBC4332F for ; Mon, 12 Dec 2022 18:19:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hWnF9HYTrG2qpjjfLKo6aBl50kLRCUu29is2GG6cDXc=; b=W0w2YP+TFzuiXf 35vCkd4y/jgm4KdlwXko6ihjiyF2VH0rO63eJehAUEVaA/UfIN6RbQvW1bUqFFkQkyipShMLFeGeO 3BqGLzGua6k0TjgP0wXWhc52MzNJ33bj0Ok5X+ujQUoaeKJoStLmR/M+h/R7IoI1p5idDyWgFDClW teKkHIeyWJq97FhBEcTNR+o+NYststhrdriTAx0vYk2eweFWkMqSmJSIzgxqezzx84qoNfp9Prpyx wQR1DhvnY7TUO5x/mipGj5CmQR5i2UTTzighlF8kiTDYJhcn7asbS/6r40/W5huJvE2XHULJ6D0OT jRNI8QPYXdqI7/DOqO2Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4nNJ-003bxn-2r; Mon, 12 Dec 2022 18:18:01 +0000 Received: from out-196.mta0.migadu.com ([91.218.175.196]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4nND-003bvV-Uc for linux-arm-kernel@lists.infradead.org; Mon, 12 Dec 2022 18:17:58 +0000 Date: Mon, 12 Dec 2022 18:17:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1670869065; 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: in-reply-to:in-reply-to:references:references; bh=a9Id/GViUZAo9zRK46q4+Dpl7Meohnepciy9W7jEdXE=; b=fE9WRJWJ8x2O7m5Gd09O9tkOQ7F6YcPGusN7I2RL/OS2Rivtpch9NFEYCzf1v/E4NtmVv2 FLeZtByUzGij7gtzYD2aTQDXJlv0CdgVRUMS8Aas8M3DkxaG3WKtYQ+564OB8J8mbI1PHJ LneF0SsRvU08OUrrniHIKR30jQw8fVg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Cc: David Matlack , "Yang, Weijiang" , Paolo Bonzini , Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , Paul Walmsley , Palmer Dabbelt , Albert Ou , Andrew Morton , Anshuman Khandual , "Amit, Nadav" , "Matthew Wilcox (Oracle)" , Vlastimil Babka , "Liam R. Howlett" , Suren Baghdasaryan , Peter Xu , xu xin , Arnd Bergmann , Yu Zhao , Colin Cross , Hugh Dickins , Ben Gardon , Mingwei Zhang , Krish Sadhukhan , Ricardo Koller , Jing Zhang , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "kvmarm@lists.cs.columbia.edu" , "linux-mips@vger.kernel.org" , "kvm@vger.kernel.org" , "kvm-riscv@lists.infradead.org" , "linux-riscv@lists.infradead.org" Subject: Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role Message-ID: References: <20221208193857.4090582-1-dmatlack@google.com> <20221208193857.4090582-2-dmatlack@google.com> <22fe2332-497e-fe30-0155-e026b0eded97@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221212_101756_171974_761DF8BC X-CRM114-Status: GOOD ( 20.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Dec 12, 2022 at 05:39:38PM +0000, Sean Christopherson wrote: > On Fri, Dec 09, 2022, David Matlack wrote: > > On Fri, Dec 9, 2022 at 9:25 AM Oliver Upton wrote: > > > > > > On Fri, Dec 09, 2022 at 10:37:47AM +0800, Yang, Weijiang wrote: > > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > > > > index 4d188f056933..f375b719f565 100644 > > > > > --- a/arch/x86/kvm/mmu/mmu.c > > > > > +++ b/arch/x86/kvm/mmu/mmu.c > > > > > @@ -5056,7 +5056,7 @@ kvm_calc_cpu_role(struct kvm_vcpu *vcpu, const struct kvm_mmu_role_regs *regs) > > > > > union kvm_cpu_role role = {0}; > > > > > role.base.access = ACC_ALL; > > > > > - role.base.smm = is_smm(vcpu); > > > > > + role.base.as_id = is_smm(vcpu); > > > > > > > > I'm not familiar with other architectures, is there similar conception as > > > > x86 smm mode? > > > > The notion of address spaces is already existing architecture-neutral > > concept in KVM (e.g. see uses of KVM_ADDRESS_SPACE_NUM in > > virt/kvm/kvm_main.c), although SMM is the only use-case I'm aware of. > > Yes, SMM is currently the only use-case. > > > Architectures that do not use multiple address spaces will just leave > > as_id is as always 0. > > My preference would be to leave .smm in x86's page role. IMO, defining multiple > address spaces to support SMM emulation was a mistake that should be contained to > SMM, i.e. should never be used for any other feature. And with CONFIG_KVM_SMM, > even x86 can opt out. +1 I don't think something is architecture-neutral by virtue of it existing in virt/kvm/*. > Emulating something like TrustZone or EL3 would be quite similar. /me shudders I know it is for the sake of discussion, but for posterity: please no! -- Best, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel