From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Matlack Date: Mon, 12 Dec 2022 17:18:35 -0800 Subject: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role In-Reply-To: <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com> References: <20221208193857.4090582-1-dmatlack@google.com> <20221208193857.4090582-2-dmatlack@google.com> <22fe2332-497e-fe30-0155-e026b0eded97@intel.com> <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.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 11:50:29PM +0100, Paolo Bonzini wrote: > On 12/12/22 18:39, Sean Christopherson wrote: > > > 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. > > It's possible that in the future Hyper-V VTLs will also have per-level > protections. It wouldn't use as_id, but it would likely be recorded in the > upper byte of the role. > > I'm not sure if Microsoft intends to port those to ARM as well. > > > My preference would be to leave .smm in x86's page role > > What about defining a byte of arch_role and a macro to build it? Both would work. I went with as_id in the common role since that's how it's encoded in kvm_memory_slot and because, not matter what, the TDP MMU still has to handle multiple address spaces. i.e. Even if we hide SMM away in the role, the TDP MMU still has to access it with some wrapper e.g. kvm_mmu_page_as_id() (that would just return 0 outside of x86). From that perspective, just having as_id directly in the common role seemed like the cleanest option. The only way to truly shield the TDP MMU from SMM would be to disallow it. e.g. Disable the TDP MMU if defined(CONFIG_KVM_SMM), or something similar. But I don't know enough about how KVM SMM support is used to say if that's even worth entertaining. 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 07266C4332F for ; Tue, 13 Dec 2022 01:18:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 79A034B8E3; Mon, 12 Dec 2022 20:18:45 -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 WHV7n7JCH7Vo; Mon, 12 Dec 2022 20:18:44 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 449DD4B91F; Mon, 12 Dec 2022 20:18:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C6EC54B922 for ; Mon, 12 Dec 2022 20:18:42 -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 ipmn-YIx7VWQ for ; Mon, 12 Dec 2022 20:18:41 -0500 (EST) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9A6974B8E3 for ; Mon, 12 Dec 2022 20:18:41 -0500 (EST) Received: by mail-pj1-f44.google.com with SMTP id z8-20020a17090abd8800b00219ed30ce47so1839780pjr.3 for ; Mon, 12 Dec 2022 17:18:41 -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=65IDnHecXM4GAPku5HHW6zoqaWMBpSe6UVEVil1rUW8=; b=aCbTEC5zVQHMxXGUQTyU3DWgykcdtGQYX+TMVnYfhhivfYDwUdEI2A+rvhEs/NwsaF DBS7EUg/X3QUOeZSsBrnvtkOTybUx0UgHQfTJ3hA35ipZDaXqrdLdH18As7YVMN94+FU E0ZAjnBtiWq0DWCLJTMY1LLhx6oaO6nTa/LCKJnCfj9cvh92FEO+h9Fh1uCxf/eAl6iw 7hyDu3aUhJ3UKrfyvsiyjGIexzmF9DmyPzjASetqH/jMJK8TS5INlchOlJfnBagkkznK 3XYQb4be1caEftz1e2fA0GEffMBeGMtYKiW3GQDIe6ihjILD9JWzVjZUmCWBKLdW3ozR bQkw== 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=65IDnHecXM4GAPku5HHW6zoqaWMBpSe6UVEVil1rUW8=; b=pV4t1mfHK4nX5/d+lXUePrDhnG4dF51hRpP10Hq6u7qOIu6wXRYOcOnoE7ZGsx5iTg aZmRdgssE9bpSHrkkFe7gxQj6lRijasMSKWx8vmu/vhqUNSKYNZUjkMGaSJX95ztw5iz Qcl8vYYrMouKeo/g09vjvO1p5gsZ0xWwoHoDbkpbPpmdvalThwDpDOavG4NnpMsVUbCQ GR7W4vD1csvMv0bgFxj5zR/BrBqtaEX8QEVT+0tWiGiIwBwJeLq9eZIOHOJ/x/7lvy5w p0Kwu68C34bvwtq0jAJSc/Q36MbyorK1+A5xkTV7iYrz7xvGokW4xXiHNrVfV0CGkaL7 qsCQ== X-Gm-Message-State: ANoB5pnJ7NOtzx/HcAsIfg4SUoBuDOk36quUeM8qKw9s7N8UEePscoua Ve/wKmpP1TQKeiUobHgDWG2dpQ== X-Google-Smtp-Source: AA0mqf5INLD3H26KoHZlGz+PIVih+odmnj70wLNIiESaeaUKfnuuF7xa7n6FGQnW8NJxdar9YAD0/g== X-Received: by 2002:a05:6a20:2d21:b0:a4:9691:6e9 with SMTP id g33-20020a056a202d2100b000a4969106e9mr23637142pzl.1.1670894320396; Mon, 12 Dec 2022 17:18:40 -0800 (PST) Received: from google.com (223.103.125.34.bc.googleusercontent.com. [34.125.103.223]) by smtp.gmail.com with ESMTPSA id r14-20020a63a54e000000b00460ea630c1bsm5762650pgu.46.2022.12.12.17.18.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 17:18:40 -0800 (PST) Date: Mon, 12 Dec 2022 17:18:35 -0800 From: David Matlack To: Paolo Bonzini 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> <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com> 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 , 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" , Marc Zyngier , 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 11:50:29PM +0100, Paolo Bonzini wrote: > On 12/12/22 18:39, Sean Christopherson wrote: > > > 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. > > It's possible that in the future Hyper-V VTLs will also have per-level > protections. It wouldn't use as_id, but it would likely be recorded in the > upper byte of the role. > > I'm not sure if Microsoft intends to port those to ARM as well. > > > My preference would be to leave .smm in x86's page role > > What about defining a byte of arch_role and a macro to build it? Both would work. I went with as_id in the common role since that's how it's encoded in kvm_memory_slot and because, not matter what, the TDP MMU still has to handle multiple address spaces. i.e. Even if we hide SMM away in the role, the TDP MMU still has to access it with some wrapper e.g. kvm_mmu_page_as_id() (that would just return 0 outside of x86). From that perspective, just having as_id directly in the common role seemed like the cleanest option. The only way to truly shield the TDP MMU from SMM would be to disallow it. e.g. Disable the TDP MMU if defined(CONFIG_KVM_SMM), or something similar. But I don't know enough about how KVM SMM support is used to say if that's even worth entertaining. _______________________________________________ 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-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 3162715B0 for ; Tue, 13 Dec 2022 01:18:41 +0000 (UTC) Received: by mail-pl1-f171.google.com with SMTP id l10so357859plb.8 for ; Mon, 12 Dec 2022 17:18:41 -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=65IDnHecXM4GAPku5HHW6zoqaWMBpSe6UVEVil1rUW8=; b=aCbTEC5zVQHMxXGUQTyU3DWgykcdtGQYX+TMVnYfhhivfYDwUdEI2A+rvhEs/NwsaF DBS7EUg/X3QUOeZSsBrnvtkOTybUx0UgHQfTJ3hA35ipZDaXqrdLdH18As7YVMN94+FU E0ZAjnBtiWq0DWCLJTMY1LLhx6oaO6nTa/LCKJnCfj9cvh92FEO+h9Fh1uCxf/eAl6iw 7hyDu3aUhJ3UKrfyvsiyjGIexzmF9DmyPzjASetqH/jMJK8TS5INlchOlJfnBagkkznK 3XYQb4be1caEftz1e2fA0GEffMBeGMtYKiW3GQDIe6ihjILD9JWzVjZUmCWBKLdW3ozR bQkw== 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=65IDnHecXM4GAPku5HHW6zoqaWMBpSe6UVEVil1rUW8=; b=MxSFZdu+G7aJdHIs6WMCHW1IPSN7nVh8qONW2rv793XHS2mK06c0lcVDzaRty3i7tC C0h0/OvLl9zLYlqVtJgS3WmOWkXVPgMrK+W07RjS9X499nejwhz+LNHZiiJ7th+0icDM 6F+jNyoE/aogF4VKE8dZHRo1CvfpWjpbWYKyZLiZdfctoePKnsoIY8+hsQRoWZCwk7ZA 7tdk8tU/OsXHrvPatP2+3KA/vRVc4Y5argQABeNRT4u+aXJrBjA+SU0xsGl2if8JggOM rcziiD1mqVHyxbUcQQjfZonEMnyGS1PcxN2a36TMKMCC0vJ2svVtt59WIs8cED2fmzT4 VWWw== X-Gm-Message-State: ANoB5pnocVgdv2DFC7BjI9xabCGQ+HzLaO9x3AWKMX3Hy6lAHCUbJif1 SV7xcjvmlIKRyvPXQGFtrPxJEg== X-Google-Smtp-Source: AA0mqf5INLD3H26KoHZlGz+PIVih+odmnj70wLNIiESaeaUKfnuuF7xa7n6FGQnW8NJxdar9YAD0/g== X-Received: by 2002:a05:6a20:2d21:b0:a4:9691:6e9 with SMTP id g33-20020a056a202d2100b000a4969106e9mr23637142pzl.1.1670894320396; Mon, 12 Dec 2022 17:18:40 -0800 (PST) Received: from google.com (223.103.125.34.bc.googleusercontent.com. [34.125.103.223]) by smtp.gmail.com with ESMTPSA id r14-20020a63a54e000000b00460ea630c1bsm5762650pgu.46.2022.12.12.17.18.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 17:18:40 -0800 (PST) Date: Mon, 12 Dec 2022 17:18:35 -0800 From: David Matlack To: Paolo Bonzini Cc: Sean Christopherson , Oliver Upton , "Yang, Weijiang" , 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> <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.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: <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com> Message-ID: <20221213011835.mxjRoIR0PByaprSqJ-fwwq6jGSuEijSTLp6cRM-tPV0@z> On Mon, Dec 12, 2022 at 11:50:29PM +0100, Paolo Bonzini wrote: > On 12/12/22 18:39, Sean Christopherson wrote: > > > 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. > > It's possible that in the future Hyper-V VTLs will also have per-level > protections. It wouldn't use as_id, but it would likely be recorded in the > upper byte of the role. > > I'm not sure if Microsoft intends to port those to ARM as well. > > > My preference would be to leave .smm in x86's page role > > What about defining a byte of arch_role and a macro to build it? Both would work. I went with as_id in the common role since that's how it's encoded in kvm_memory_slot and because, not matter what, the TDP MMU still has to handle multiple address spaces. i.e. Even if we hide SMM away in the role, the TDP MMU still has to access it with some wrapper e.g. kvm_mmu_page_as_id() (that would just return 0 outside of x86). From that perspective, just having as_id directly in the common role seemed like the cleanest option. The only way to truly shield the TDP MMU from SMM would be to disallow it. e.g. Disable the TDP MMU if defined(CONFIG_KVM_SMM), or something similar. But I don't know enough about how KVM SMM support is used to say if that's even worth entertaining. 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 E728FC00145 for ; Tue, 13 Dec 2022 01:19:04 +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=jvbx9jHIT2c5+GMmkgBZQbANZ3xpZKWNxYA8QAJjLAE=; b=YShoqUdyi1NYwL W8lgoEierTdcxsuHMMSsjU8b6RhhIHghlgLaphVcpE9X/mmcOWOySoO6Twf5WHaDofBUCyoQaDVB9 A1n6cecISN6h2MUZHlTgGTIm93w7erihJSSvwenbSoAjw0grkt8W+rXryth2E9aEoDKaohs4CTdma 5f0UwnBPAUmBxCi44WeRn4Iw0eD82nsbo1Dy3g6cZUcaOz77GnclaL0jmBEDh32pN0Mdffyqzn1vF 0uGhUUY6udK6DJL0bFisYgp/I9Ge1GMihzSMd3STWDic9wlLHlepanWtzZZuliTnnt3mBYXH2tJtv ugcqcJYBvzdrLpF/7prw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4twd-008snO-4S; Tue, 13 Dec 2022 01:18:55 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4twU-008sO2-Nv for linux-riscv@lists.infradead.org; Tue, 13 Dec 2022 01:18:48 +0000 Received: by mail-pl1-x62a.google.com with SMTP id d3so13945695plr.10 for ; Mon, 12 Dec 2022 17:18:41 -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=65IDnHecXM4GAPku5HHW6zoqaWMBpSe6UVEVil1rUW8=; b=aCbTEC5zVQHMxXGUQTyU3DWgykcdtGQYX+TMVnYfhhivfYDwUdEI2A+rvhEs/NwsaF DBS7EUg/X3QUOeZSsBrnvtkOTybUx0UgHQfTJ3hA35ipZDaXqrdLdH18As7YVMN94+FU E0ZAjnBtiWq0DWCLJTMY1LLhx6oaO6nTa/LCKJnCfj9cvh92FEO+h9Fh1uCxf/eAl6iw 7hyDu3aUhJ3UKrfyvsiyjGIexzmF9DmyPzjASetqH/jMJK8TS5INlchOlJfnBagkkznK 3XYQb4be1caEftz1e2fA0GEffMBeGMtYKiW3GQDIe6ihjILD9JWzVjZUmCWBKLdW3ozR bQkw== 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=65IDnHecXM4GAPku5HHW6zoqaWMBpSe6UVEVil1rUW8=; b=68BlidXO6c6ZPKXi5ZUcZlRHLFSP6lmaobODNLfqi/EeyWC06EYGyYzG9LQaqVdVcO IHwmeLnm65abQmyTx8VYJWACIeyQWesGN8xExbeCUfACrJUIJkIv0pd8QOGzlFCTtXBL FBByYa8RGq6RKkZeHtO2Smlu3+qi8Uyzr/5kec+4zkG7D4lPMknUYz/fbXFlzXTU9Zys oHbmoS5LYlmZQPcuEqPSfY5FgICbX7n29ey9Oyd5+c74e3O9YiqKmqEcJQWWqSIijE36 w28Omt3WSevLRn7I9iWLtJQCjuKSDZsGIfQJvrZ3+I4c+pA/+cf/Cj/+T26C09mE6fxZ rFBA== X-Gm-Message-State: ANoB5plgNVT0LKyNubEQwsb7GmIReIQJXhwJ+yZm60p8cosvLoxLK5C5 PWxvwg3nhMnXGva+ucWGto7IGQ== X-Google-Smtp-Source: AA0mqf5INLD3H26KoHZlGz+PIVih+odmnj70wLNIiESaeaUKfnuuF7xa7n6FGQnW8NJxdar9YAD0/g== X-Received: by 2002:a05:6a20:2d21:b0:a4:9691:6e9 with SMTP id g33-20020a056a202d2100b000a4969106e9mr23637142pzl.1.1670894320396; Mon, 12 Dec 2022 17:18:40 -0800 (PST) Received: from google.com (223.103.125.34.bc.googleusercontent.com. [34.125.103.223]) by smtp.gmail.com with ESMTPSA id r14-20020a63a54e000000b00460ea630c1bsm5762650pgu.46.2022.12.12.17.18.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 17:18:40 -0800 (PST) Date: Mon, 12 Dec 2022 17:18:35 -0800 From: David Matlack To: Paolo Bonzini Cc: Sean Christopherson , Oliver Upton , "Yang, Weijiang" , 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> <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221212_171846_805678_525F2321 X-CRM114-Status: GOOD ( 18.66 ) 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 11:50:29PM +0100, Paolo Bonzini wrote: > On 12/12/22 18:39, Sean Christopherson wrote: > > > 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. > > It's possible that in the future Hyper-V VTLs will also have per-level > protections. It wouldn't use as_id, but it would likely be recorded in the > upper byte of the role. > > I'm not sure if Microsoft intends to port those to ARM as well. > > > My preference would be to leave .smm in x86's page role > > What about defining a byte of arch_role and a macro to build it? Both would work. I went with as_id in the common role since that's how it's encoded in kvm_memory_slot and because, not matter what, the TDP MMU still has to handle multiple address spaces. i.e. Even if we hide SMM away in the role, the TDP MMU still has to access it with some wrapper e.g. kvm_mmu_page_as_id() (that would just return 0 outside of x86). From that perspective, just having as_id directly in the common role seemed like the cleanest option. The only way to truly shield the TDP MMU from SMM would be to disallow it. e.g. Disable the TDP MMU if defined(CONFIG_KVM_SMM), or something similar. But I don't know enough about how KVM SMM support is used to say if that's even worth entertaining. _______________________________________________ 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 B357DC4332F for ; Tue, 13 Dec 2022 01:19:54 +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=Ay+uy2BXnRTkwFJxf7CijTTsUpYRVBwV2298+Jtc/eQ=; b=sm5+25umT2Ug0o 8CZgnEvQhSRPWVL8x1bFfD7zTcv6B8RIxHylBFh5DKakxwD3NJ+U90ECBjT89sbByfAM3e/HMOr81 U3kN70q2aJUdNhTaQBZSla6qFXgJBxw63yfoTyV569HSoBb04C+5oSKyxcylBbQVZkhF7fy4cQA+X KOh3npmrb0BLaSdszCpMkMRSaVZmGLDXgX4Ru7yd/llHSSUTF92AtyVh+M/rujOU3b5EQz6cTDmhT jY9TiN5Emi8B7vjjPbYzXpvxH+8GwAMXw6RFdVdWXo717++TsqkKd4V8nMhW+EuEnygtqlphvjvWi MABzILcjRwzKlnHuUr4A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4twV-008sg5-1b; Tue, 13 Dec 2022 01:18:47 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4twR-008sO4-UE for linux-arm-kernel@lists.infradead.org; Tue, 13 Dec 2022 01:18:45 +0000 Received: by mail-pj1-x102f.google.com with SMTP id v13-20020a17090a6b0d00b00219c3be9830so1885673pjj.4 for ; Mon, 12 Dec 2022 17:18:41 -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=65IDnHecXM4GAPku5HHW6zoqaWMBpSe6UVEVil1rUW8=; b=aCbTEC5zVQHMxXGUQTyU3DWgykcdtGQYX+TMVnYfhhivfYDwUdEI2A+rvhEs/NwsaF DBS7EUg/X3QUOeZSsBrnvtkOTybUx0UgHQfTJ3hA35ipZDaXqrdLdH18As7YVMN94+FU E0ZAjnBtiWq0DWCLJTMY1LLhx6oaO6nTa/LCKJnCfj9cvh92FEO+h9Fh1uCxf/eAl6iw 7hyDu3aUhJ3UKrfyvsiyjGIexzmF9DmyPzjASetqH/jMJK8TS5INlchOlJfnBagkkznK 3XYQb4be1caEftz1e2fA0GEffMBeGMtYKiW3GQDIe6ihjILD9JWzVjZUmCWBKLdW3ozR bQkw== 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=65IDnHecXM4GAPku5HHW6zoqaWMBpSe6UVEVil1rUW8=; b=yyXGTpp5aWemBkzawyFPzf7/79hvxWTs23hIkEEEp3fXeW8PX1eER0BEn/jSmIJB0x 0X4l948dLWOyulQtN6zEOtn9jsoX5dYJpGWIMAsS1OkJ1Zp518smonaaZCXAZvPyVilp 7jVtBWSjV+sgjrkFP7gxYIolhsbPdCll93IpVJpjUzyVLkWzV6qc2FvWCQnfNWr1Wv0j NvkyA4uxsMJ3cp/1Wo7af8XxereMSbztmo+31wWT3wXULz4UVa/+tyi60Y14lSfdFbVY xH1s4O6OJpizaldiwcBxxgCHAmjcKIK6DD33qFZuQ6rtJ65lS6Vv6Ip9znASRU/Zk4Fm 3W/g== X-Gm-Message-State: ANoB5pnPuZPkKGJvlgFdbYbbKCSZkDQ3miekNI7yPUzT89eEtej4ZjID 7EeldGGiq+uO+YKfhjkk/0nd4w== X-Google-Smtp-Source: AA0mqf5INLD3H26KoHZlGz+PIVih+odmnj70wLNIiESaeaUKfnuuF7xa7n6FGQnW8NJxdar9YAD0/g== X-Received: by 2002:a05:6a20:2d21:b0:a4:9691:6e9 with SMTP id g33-20020a056a202d2100b000a4969106e9mr23637142pzl.1.1670894320396; Mon, 12 Dec 2022 17:18:40 -0800 (PST) Received: from google.com (223.103.125.34.bc.googleusercontent.com. [34.125.103.223]) by smtp.gmail.com with ESMTPSA id r14-20020a63a54e000000b00460ea630c1bsm5762650pgu.46.2022.12.12.17.18.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 17:18:40 -0800 (PST) Date: Mon, 12 Dec 2022 17:18:35 -0800 From: David Matlack To: Paolo Bonzini Cc: Sean Christopherson , Oliver Upton , "Yang, Weijiang" , 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> <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <01cb4882-7a06-176f-7d55-f80cca300ffd@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221212_171843_997481_FD0A2CDF X-CRM114-Status: GOOD ( 20.26 ) 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 11:50:29PM +0100, Paolo Bonzini wrote: > On 12/12/22 18:39, Sean Christopherson wrote: > > > 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. > > It's possible that in the future Hyper-V VTLs will also have per-level > protections. It wouldn't use as_id, but it would likely be recorded in the > upper byte of the role. > > I'm not sure if Microsoft intends to port those to ARM as well. > > > My preference would be to leave .smm in x86's page role > > What about defining a byte of arch_role and a macro to build it? Both would work. I went with as_id in the common role since that's how it's encoded in kvm_memory_slot and because, not matter what, the TDP MMU still has to handle multiple address spaces. i.e. Even if we hide SMM away in the role, the TDP MMU still has to access it with some wrapper e.g. kvm_mmu_page_as_id() (that would just return 0 outside of x86). From that perspective, just having as_id directly in the common role seemed like the cleanest option. The only way to truly shield the TDP MMU from SMM would be to disallow it. e.g. Disable the TDP MMU if defined(CONFIG_KVM_SMM), or something similar. But I don't know enough about how KVM SMM support is used to say if that's even worth entertaining. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel