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 1D06FC4332F for ; Mon, 12 Dec 2022 18:19:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233058AbiLLSTJ (ORCPT ); Mon, 12 Dec 2022 13:19:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233045AbiLLSSe (ORCPT ); Mon, 12 Dec 2022 13:18:34 -0500 Received: from out-138.mta0.migadu.com (out-138.mta0.migadu.com [IPv6:2001:41d0:1004:224b::8a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63D35AE5E for ; Mon, 12 Dec 2022 10:17:48 -0800 (PST) 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.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