From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Mon, 12 Dec 2022 17:39:38 +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 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. For all potential use cases I'm aware of, SMM included, separate address spaces are overkill. The SMM use case is to define a region of guest memory that is accessible if and only if the vCPU is operating in SMM. Emulating something like TrustZone or EL3 would be quite similar. Ditto for Intel's TXT Private Space (though I can't imagine KVM ever emulating TXT :-) ). Using separate address spaces means that userspace needs to define the overlapping GPA areas multiple times, which is inefficient for both memory and CPU usage. E.g. for SMM, userspace needs to redefine all of "regular" memory for SMM in addition to memory that is SMM-only. And more bizarelly, nothing prevents userspace from defining completely different memslot layouts for each address space, which might may not add complexity in terms of code, but does make it more difficult to reason about KVM behavior at the boundaries between modes. Unless I'm missing something, e.g. a need to map GPAs differently for SMM vs. non-SMM, SMM could have been implemented with a simple flag in a memslot to mark the memslot as SMM-only. Or likely even better, as an overlay to track attributes, e.g. similar to how private vs. shared memory will be handled for protected VMs. That would be slightly less efficient for memslot searches for use cases where all memory is mutually exclusive, but simpler and more efficient overall. And separate address spaces become truly nasty if the CPU can access multiple protected regions, e.g. if the CPU can access type X and type Y at the same time, then there would need to be memslots for "regular", X, Y, and X+Y. 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 5E2D2C4332F for ; Mon, 12 Dec 2022 17:39:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C8C5A4B963; Mon, 12 Dec 2022 12:39:47 -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=@google.com 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 IfR8DgzbnYMT; Mon, 12 Dec 2022 12:39:46 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 770404B896; Mon, 12 Dec 2022 12:39:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 166EC4B889 for ; Mon, 12 Dec 2022 12:39:45 -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 vW9UnqaNs4Xy for ; Mon, 12 Dec 2022 12:39:43 -0500 (EST) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 8C4D64B87D for ; Mon, 12 Dec 2022 12:39:43 -0500 (EST) Received: by mail-pg1-f181.google.com with SMTP id 82so8724197pgc.0 for ; Mon, 12 Dec 2022 09:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=9QS7ynIDmKRlIs3oQp3nNRq3SgpEDJuiT7l2fKUtqJA=; b=Q0nnG/dD12oshnk2CykCxq72d8uZrdzzqkuH5dft2uszejZpVFSnXayz+SB3Bwgro8 BRpXeeCgbqfUn2wNBfcOZyX3qyFKQJ6SczkPWVABh1mpb57722xzOrsTLiE48vG5UkwV bWLck3WppDEGsIUBHKKGTEWgFtdCLpnoSQ2bevYVQ/nLcPPAgPGAlA/9ZOfUNOvgOGId G76GaBjjIODSpD0MI08sPApYWZ6pYb2TgRVicuKhWCGe6JSitmtMJPjC2xPhiXqe6dk1 lh4RR1K4cJ0EETmdVRDXbjpYPE9b76QlJk+PQjM9eohHtNpBi7HjhEH0vhjhhqilbAjf 2W6A== 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=9QS7ynIDmKRlIs3oQp3nNRq3SgpEDJuiT7l2fKUtqJA=; b=MYMNzU5O1ry6X4F71qz6+YNdIr0MBHlCZvKAqX5dLlT6ksZc6pB2KmtuiuP21LbpXs uVmP9a5M2LJyJYaTUNXJvsFwzW0gqsn4xFskKXnCSWDdwOj38tgZ0vx1s4k4/9tOcfHf 0bT5mxFQ9abBfH5I5wktYhj7YJyrxBff2Xi8H8yai6n4FEbxhhleANXaf4T5/VTh8D+7 PRYFjnJ/nzwIsTkfyq2tRFpEdBcpdV8biCtwYk4/BcGMiz6sG8/OQqYW6P2yqtEoE1N4 9PEwhXvGsHcroq23mjruXQ7Ur5nOk8tWOkCgyCoNF6ViQYDg18ghwV7y3AeIroZUQzix 5RRg== X-Gm-Message-State: ANoB5pnvRP4VmdMZfNPlfg3EeiHJx6OVZlytbtrHR8nUV/a2ndhsgH2k 1UgPxn0wjjB6Z0vVMdzGmVWHJg== X-Google-Smtp-Source: AA0mqf4fRjcF7yqcwPoqLk9QucrmsFbaTw1SZFxx+iK6d+zjxBOpK3Jkaq0gjsaSmdZVgYI9LkA78w== X-Received: by 2002:a05:6a00:27a4:b0:576:22d7:fd9e with SMTP id bd36-20020a056a0027a400b0057622d7fd9emr657961pfb.0.1670866782130; Mon, 12 Dec 2022 09:39:42 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y10-20020aa793ca000000b0057555d35f79sm6092008pff.101.2022.12.12.09.39.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 09:39:41 -0800 (PST) Date: Mon, 12 Dec 2022 17:39:38 +0000 From: Sean Christopherson To: David Matlack 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: Cc: Anshuman Khandual , Hugh Dickins , Paul Walmsley , "Yang, Weijiang" , "Amit, Nadav" , Colin Cross , 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 , "kvmarm@lists.linux.dev" , Suren Baghdasaryan , Vlastimil Babka , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , "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 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. For all potential use cases I'm aware of, SMM included, separate address spaces are overkill. The SMM use case is to define a region of guest memory that is accessible if and only if the vCPU is operating in SMM. Emulating something like TrustZone or EL3 would be quite similar. Ditto for Intel's TXT Private Space (though I can't imagine KVM ever emulating TXT :-) ). Using separate address spaces means that userspace needs to define the overlapping GPA areas multiple times, which is inefficient for both memory and CPU usage. E.g. for SMM, userspace needs to redefine all of "regular" memory for SMM in addition to memory that is SMM-only. And more bizarelly, nothing prevents userspace from defining completely different memslot layouts for each address space, which might may not add complexity in terms of code, but does make it more difficult to reason about KVM behavior at the boundaries between modes. Unless I'm missing something, e.g. a need to map GPAs differently for SMM vs. non-SMM, SMM could have been implemented with a simple flag in a memslot to mark the memslot as SMM-only. Or likely even better, as an overlay to track attributes, e.g. similar to how private vs. shared memory will be handled for protected VMs. That would be slightly less efficient for memslot searches for use cases where all memory is mutually exclusive, but simpler and more efficient overall. And separate address spaces become truly nasty if the CPU can access multiple protected regions, e.g. if the CPU can access type X and type Y at the same time, then there would need to be memslots for "regular", X, Y, and X+Y. _______________________________________________ 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 mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E6933212 for ; Mon, 12 Dec 2022 17:39:43 +0000 (UTC) Received: by mail-pg1-f178.google.com with SMTP id 62so8671769pgb.13 for ; Mon, 12 Dec 2022 09:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=9QS7ynIDmKRlIs3oQp3nNRq3SgpEDJuiT7l2fKUtqJA=; b=Q0nnG/dD12oshnk2CykCxq72d8uZrdzzqkuH5dft2uszejZpVFSnXayz+SB3Bwgro8 BRpXeeCgbqfUn2wNBfcOZyX3qyFKQJ6SczkPWVABh1mpb57722xzOrsTLiE48vG5UkwV bWLck3WppDEGsIUBHKKGTEWgFtdCLpnoSQ2bevYVQ/nLcPPAgPGAlA/9ZOfUNOvgOGId G76GaBjjIODSpD0MI08sPApYWZ6pYb2TgRVicuKhWCGe6JSitmtMJPjC2xPhiXqe6dk1 lh4RR1K4cJ0EETmdVRDXbjpYPE9b76QlJk+PQjM9eohHtNpBi7HjhEH0vhjhhqilbAjf 2W6A== 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=9QS7ynIDmKRlIs3oQp3nNRq3SgpEDJuiT7l2fKUtqJA=; b=obYJjJbjVw0lW805mzNwxrDVRMZcNl711UwxoMNl5MwW4Fd/xgs5qumEc/jd9ChPgp MWHU3EX0Xxaz9iwA360pWfs6Mzjxlvei4uTw17/IPDI/kYEcwedeKHzifjYgtRZ73I6q 17UX2a6WGWB4o0RCfXjQNt7lS5h0iOMjQXR4xHepbPtNDigEjPm/0/UtNivMS1OvndS6 Ak2qgmtad1Bbwg/+y0BOMt91Fd6N7i3vuUlGMg4eTMS0GwbsmqszSRCfFTGilk1XJBU1 hTU3rg8gZ1Sst+wMG3Vu3q4pjjI70xKGrswiqCLw2HxPXeBGrJLbDau6wpQBcx6n4ne8 jlyg== X-Gm-Message-State: ANoB5plsWuGEPQYvzxbX4w4H+ECrGyOr31rZSSFMJQrUoCdtPMjcbemO FlnNe/ozt9TZshY/diUlreigSA== X-Google-Smtp-Source: AA0mqf4fRjcF7yqcwPoqLk9QucrmsFbaTw1SZFxx+iK6d+zjxBOpK3Jkaq0gjsaSmdZVgYI9LkA78w== X-Received: by 2002:a05:6a00:27a4:b0:576:22d7:fd9e with SMTP id bd36-20020a056a0027a400b0057622d7fd9emr657961pfb.0.1670866782130; Mon, 12 Dec 2022 09:39:42 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y10-20020aa793ca000000b0057555d35f79sm6092008pff.101.2022.12.12.09.39.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 09:39:41 -0800 (PST) Date: Mon, 12 Dec 2022 17:39:38 +0000 From: Sean Christopherson To: David Matlack Cc: Oliver Upton , "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: Message-ID: <20221212173938.IKognmQG7iQshPqcDCiUYQfnDgrjuMlYSj3kcrxaJvY@z> 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. For all potential use cases I'm aware of, SMM included, separate address spaces are overkill. The SMM use case is to define a region of guest memory that is accessible if and only if the vCPU is operating in SMM. Emulating something like TrustZone or EL3 would be quite similar. Ditto for Intel's TXT Private Space (though I can't imagine KVM ever emulating TXT :-) ). Using separate address spaces means that userspace needs to define the overlapping GPA areas multiple times, which is inefficient for both memory and CPU usage. E.g. for SMM, userspace needs to redefine all of "regular" memory for SMM in addition to memory that is SMM-only. And more bizarelly, nothing prevents userspace from defining completely different memslot layouts for each address space, which might may not add complexity in terms of code, but does make it more difficult to reason about KVM behavior at the boundaries between modes. Unless I'm missing something, e.g. a need to map GPAs differently for SMM vs. non-SMM, SMM could have been implemented with a simple flag in a memslot to mark the memslot as SMM-only. Or likely even better, as an overlay to track attributes, e.g. similar to how private vs. shared memory will be handled for protected VMs. That would be slightly less efficient for memslot searches for use cases where all memory is mutually exclusive, but simpler and more efficient overall. And separate address spaces become truly nasty if the CPU can access multiple protected regions, e.g. if the CPU can access type X and type Y at the same time, then there would need to be memslots for "regular", X, Y, and X+Y. 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 D6A9AC4332F for ; Mon, 12 Dec 2022 17:40: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=lp7YkwhG7sQWBSE+katseSIrGVUuHQfcCEG6jNTi97E=; b=M5pBpAg3PP/Z9D Hl235AWDIodU8q5QTnwnFeqRxx4U+iwr020iq0wdfuq/NINhVfw+CQ5l18+0giGvi5TeH7Fy66r3r U/AtegszAwIMg+UM/26GQocpjy33WneQS7hgPS+b6yCz0cthU/pS0K0j7I+JxQT2htGYVMWYSIEiq lVaZ8CHGRZ+m8keE9zwzu1VmmmD1XeOnHR7fymhzaXZe7uo1IEs2SRqCxcxIXWntRT89NfsBmnslQ rLyW4Klhmuy8/Jh2dH0dlB6hdDbSqq+/rU0cz70KzWj50Xeg+Fhv+r87YuKxkCVpp+4FAC7Z8tniT M6yaEdqOsyEchfy77mUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4mmV-0030kE-V3; Mon, 12 Dec 2022 17:39:59 +0000 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4mmJ-00306U-Ua for linux-riscv@lists.infradead.org; Mon, 12 Dec 2022 17:39:50 +0000 Received: by mail-pg1-x531.google.com with SMTP id 142so8695335pga.1 for ; Mon, 12 Dec 2022 09:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=9QS7ynIDmKRlIs3oQp3nNRq3SgpEDJuiT7l2fKUtqJA=; b=Q0nnG/dD12oshnk2CykCxq72d8uZrdzzqkuH5dft2uszejZpVFSnXayz+SB3Bwgro8 BRpXeeCgbqfUn2wNBfcOZyX3qyFKQJ6SczkPWVABh1mpb57722xzOrsTLiE48vG5UkwV bWLck3WppDEGsIUBHKKGTEWgFtdCLpnoSQ2bevYVQ/nLcPPAgPGAlA/9ZOfUNOvgOGId G76GaBjjIODSpD0MI08sPApYWZ6pYb2TgRVicuKhWCGe6JSitmtMJPjC2xPhiXqe6dk1 lh4RR1K4cJ0EETmdVRDXbjpYPE9b76QlJk+PQjM9eohHtNpBi7HjhEH0vhjhhqilbAjf 2W6A== 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=9QS7ynIDmKRlIs3oQp3nNRq3SgpEDJuiT7l2fKUtqJA=; b=6zW08TqOiBc0rjgEcRFgUgFNgmyxa34392INElfzglnnhUZyz0E+MaNlx3QrgKhg4y kqyI1f3pGFDbcJ7JfOSp9FOqoeD9bExoUn3dPzJcTnESqTUjq3NfROjxgBkhRfTluCon Wd6y7i9+/3tXlgqQpVDGy65n3smbJHiby3/nIMu/UfhAZtDbprXu1wMGr5rgiciOEyb3 UUNbW2VDPJrUVs6tWno47bihf4wj1oqbOvTLcF8LCpYU21pw6rzKXo0JQ7nISjRYQVOo V5Z5IZ1KQynZOl/6T/Fx5563VyAagKsX0C7u+WFWakseIY/jKP8/9tkByxDtnE9BPNei cevw== X-Gm-Message-State: ANoB5pkLHCOicBrRb1Y0iVownyScEF1WnM6JDDNZzoCG7r9YNspwKIqR G9DZxwqotI/Wi7LyAwaeBTGNSg== X-Google-Smtp-Source: AA0mqf4fRjcF7yqcwPoqLk9QucrmsFbaTw1SZFxx+iK6d+zjxBOpK3Jkaq0gjsaSmdZVgYI9LkA78w== X-Received: by 2002:a05:6a00:27a4:b0:576:22d7:fd9e with SMTP id bd36-20020a056a0027a400b0057622d7fd9emr657961pfb.0.1670866782130; Mon, 12 Dec 2022 09:39:42 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y10-20020aa793ca000000b0057555d35f79sm6092008pff.101.2022.12.12.09.39.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 09:39:41 -0800 (PST) Date: Mon, 12 Dec 2022 17:39:38 +0000 From: Sean Christopherson To: David Matlack Cc: Oliver Upton , "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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221212_093947_996013_9A1BE511 X-CRM114-Status: GOOD ( 21.90 ) 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 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. For all potential use cases I'm aware of, SMM included, separate address spaces are overkill. The SMM use case is to define a region of guest memory that is accessible if and only if the vCPU is operating in SMM. Emulating something like TrustZone or EL3 would be quite similar. Ditto for Intel's TXT Private Space (though I can't imagine KVM ever emulating TXT :-) ). Using separate address spaces means that userspace needs to define the overlapping GPA areas multiple times, which is inefficient for both memory and CPU usage. E.g. for SMM, userspace needs to redefine all of "regular" memory for SMM in addition to memory that is SMM-only. And more bizarelly, nothing prevents userspace from defining completely different memslot layouts for each address space, which might may not add complexity in terms of code, but does make it more difficult to reason about KVM behavior at the boundaries between modes. Unless I'm missing something, e.g. a need to map GPAs differently for SMM vs. non-SMM, SMM could have been implemented with a simple flag in a memslot to mark the memslot as SMM-only. Or likely even better, as an overlay to track attributes, e.g. similar to how private vs. shared memory will be handled for protected VMs. That would be slightly less efficient for memslot searches for use cases where all memory is mutually exclusive, but simpler and more efficient overall. And separate address spaces become truly nasty if the CPU can access multiple protected regions, e.g. if the CPU can access type X and type Y at the same time, then there would need to be memslots for "regular", X, Y, and X+Y. _______________________________________________ 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 D4CBBC4332F for ; Mon, 12 Dec 2022 17:40:52 +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=hn/9hj/sk2ws1i4pc6iZTfl1fOQ2AwdbPq7PK0yRgPQ=; b=LuRTPWQMC2lHSL ePkVgMu2TzKJ+u6vdJJxzcvwSlxH4o3vybjwtlD4k8oGI7N9vzH3lXLEA4+9V+9gGFW23GLYmOibj qcLlKovnz/7ZswowIWxzDmGCy6oGAjttE/zHKFu2GAHoRVhgpJ7Krjdbr9R2CLA2gvS06yMkeCG2A FclpQXElPBxEj+p3HrpD5a/UjElcn9lbnVM7XsH/TRtuXqZg0IpCP95veXxYQFx+WVDwcxh3HzMuX M5pI07YQdCfd11hqAQpAc4mM2T6WHtl+B28xwKmQJu6EC+rT8LTC2H8HvlzmYt3WlGmFmiHGyUkzG 4dvazxES3dsXrJcvL1Zg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4mmM-0030Pf-QA; Mon, 12 Dec 2022 17:39:51 +0000 Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4mmJ-00306X-O7 for linux-arm-kernel@lists.infradead.org; Mon, 12 Dec 2022 17:39:49 +0000 Received: by mail-pg1-x529.google.com with SMTP id f9so8679774pgf.7 for ; Mon, 12 Dec 2022 09:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=9QS7ynIDmKRlIs3oQp3nNRq3SgpEDJuiT7l2fKUtqJA=; b=Q0nnG/dD12oshnk2CykCxq72d8uZrdzzqkuH5dft2uszejZpVFSnXayz+SB3Bwgro8 BRpXeeCgbqfUn2wNBfcOZyX3qyFKQJ6SczkPWVABh1mpb57722xzOrsTLiE48vG5UkwV bWLck3WppDEGsIUBHKKGTEWgFtdCLpnoSQ2bevYVQ/nLcPPAgPGAlA/9ZOfUNOvgOGId G76GaBjjIODSpD0MI08sPApYWZ6pYb2TgRVicuKhWCGe6JSitmtMJPjC2xPhiXqe6dk1 lh4RR1K4cJ0EETmdVRDXbjpYPE9b76QlJk+PQjM9eohHtNpBi7HjhEH0vhjhhqilbAjf 2W6A== 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=9QS7ynIDmKRlIs3oQp3nNRq3SgpEDJuiT7l2fKUtqJA=; b=ND1eDBxre7haN5kvf1UNc6sXXSgv3wfmSvZn3pyV4bS1lzB6tSIJM06HsPUxEzOFD3 igqghCZGsUL6GboQT4M9pVhAlGi/on+Ilyvq8wLDY+Uk0rSMMTXONg8sFN9KLebKSQMR U34Ym6rkWpMtd3CxUN57awlDxN3zm/Cz+a/niUmzNDUZ36L1+shkQ0n4jaoX16MDcaPr uInCuEXtALxUhOgmUZdix2GDLqOEi6NCm5eSUORdYOtAvu4r+3FSeFsZ2zi/caoFgYJx 1St9r+SvCVvnrG1U0z7rkREauteyYZAwEMw36WHka8SzanA9WVE3K9BXnzX28haXfsft IhVA== X-Gm-Message-State: ANoB5pkSMxsuVZeJ5CcVaINsnzeUkWt+/zmXToLAW1EXjRybV8F/KVDD YDRBeCQmnhfxwJ7d1YuYADxHxA== X-Google-Smtp-Source: AA0mqf4fRjcF7yqcwPoqLk9QucrmsFbaTw1SZFxx+iK6d+zjxBOpK3Jkaq0gjsaSmdZVgYI9LkA78w== X-Received: by 2002:a05:6a00:27a4:b0:576:22d7:fd9e with SMTP id bd36-20020a056a0027a400b0057622d7fd9emr657961pfb.0.1670866782130; Mon, 12 Dec 2022 09:39:42 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y10-20020aa793ca000000b0057555d35f79sm6092008pff.101.2022.12.12.09.39.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 09:39:41 -0800 (PST) Date: Mon, 12 Dec 2022 17:39:38 +0000 From: Sean Christopherson To: David Matlack Cc: Oliver Upton , "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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221212_093947_820798_2DC710E0 X-CRM114-Status: GOOD ( 23.50 ) 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 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. For all potential use cases I'm aware of, SMM included, separate address spaces are overkill. The SMM use case is to define a region of guest memory that is accessible if and only if the vCPU is operating in SMM. Emulating something like TrustZone or EL3 would be quite similar. Ditto for Intel's TXT Private Space (though I can't imagine KVM ever emulating TXT :-) ). Using separate address spaces means that userspace needs to define the overlapping GPA areas multiple times, which is inefficient for both memory and CPU usage. E.g. for SMM, userspace needs to redefine all of "regular" memory for SMM in addition to memory that is SMM-only. And more bizarelly, nothing prevents userspace from defining completely different memslot layouts for each address space, which might may not add complexity in terms of code, but does make it more difficult to reason about KVM behavior at the boundaries between modes. Unless I'm missing something, e.g. a need to map GPAs differently for SMM vs. non-SMM, SMM could have been implemented with a simple flag in a memslot to mark the memslot as SMM-only. Or likely even better, as an overlay to track attributes, e.g. similar to how private vs. shared memory will be handled for protected VMs. That would be slightly less efficient for memslot searches for use cases where all memory is mutually exclusive, but simpler and more efficient overall. And separate address spaces become truly nasty if the CPU can access multiple protected regions, e.g. if the CPU can access type X and type Y at the same time, then there would need to be memslots for "regular", X, Y, and X+Y. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel