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 X-Spam-Level: X-Spam-Status: No, score=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7F29C32771 for ; Fri, 24 Jan 2020 12:21:02 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 519612075D for ; Fri, 24 Jan 2020 12:21:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="cMFyr4Xh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 519612075D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8D0F54AF36; Fri, 24 Jan 2020 07:21:01 -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 H3R4bSjFAvND; Fri, 24 Jan 2020 07:21:00 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7B9664AF11; Fri, 24 Jan 2020 07:21:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 30EEA4AF0A for ; Fri, 24 Jan 2020 07:21:00 -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 pR6mVik6RSLi for ; Fri, 24 Jan 2020 07:20:59 -0500 (EST) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 089A94AEF4 for ; Fri, 24 Jan 2020 07:20:59 -0500 (EST) Received: by mail-wr1-f67.google.com with SMTP id y17so1738038wrh.5 for ; Fri, 24 Jan 2020 04:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Q5/QGs5gkh2XO+BQ2zRh4RVM54DuioXv50QpwNO/LOs=; b=cMFyr4Xh6yV515G1Qq+7238gv8y/HlkKi/4rDB6GTsgTNRmR41qvT7PZ2twHVSP9qh D0smuhi515A4wWVRtwHtSu2wHrxMvbX7auVyndUubiJrmU7agt48NX0/V74cmH9LQs1C RkanOyFY4U4cvEHWtLbatOG1cyxqEyAqm0Um96aKuPDMfonfVjFkDYJrdkk3sTnWdC1y QiK17UFDkrb+5NS4E1JnK5cXikgYvzO0gKkH0idqWjeUnf1qDy1Dskr30XUYsiC9mrrX /dAs9Kj8wLaDI7RvsWsLChvwOE9D0HUIvys2vSFyUMFzGYYetTx+/MKDP6UiVbqDJ04K bbhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Q5/QGs5gkh2XO+BQ2zRh4RVM54DuioXv50QpwNO/LOs=; b=beNs6UDzlBmoyPHAT6mTMBIRb+hyo8pBGlr77qrnOBLgChujZaJjy8vQMjNARPRXfb j4Uw7ogs+1J5BThegHxbUKlbrNS9GbLLeHvWrNIml3SOgRMnG/X9gRaTEvObGeBL/pmW rXtYMr6xNoA+lw4WedPhUCCohf/Rcr1MaaIQxjJFcS58QjK+NyMY3RAsEUEey1rYbo6x FNrtkNphjrzBaOxt7unZ1P70G6CsGKyBkPsF3ocNPJ/E1YsmnWMSDTYtujGlOltnuVj/ ny67sIvq9CUSzhWfGdOIkqDn7HNyPP7bl8w/jSVoMVkQeISXuaRRU95DM55+5V5+xwYR xe2A== X-Gm-Message-State: APjAAAUw8UbwROsP+neJEt6ojVaCrngJvu6R0ejXoH8is2mWACLUcG5J lYV4+vo5nmgk5moPcMPGzVilVw== X-Google-Smtp-Source: APXvYqwc1Foj2c7KnaKvacpILFbKY0n7Gl1OeFMdCaXfhHe+gYzfLhnQoBCMml+AofYQ5iRp2XnYpw== X-Received: by 2002:a5d:68c5:: with SMTP id p5mr3938040wrw.193.1579868457525; Fri, 24 Jan 2020 04:20:57 -0800 (PST) Received: from google.com ([2a00:79e0:d:110:d6cc:2030:37c1:9964]) by smtp.gmail.com with ESMTPSA id u7sm6587819wmj.3.2020.01.24.04.20.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jan 2020 04:20:56 -0800 (PST) Date: Fri, 24 Jan 2020 12:20:53 +0000 From: Quentin Perret To: Marc Zyngier Subject: Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables Message-ID: <20200124122053.GA150292@google.com> References: <20200113111323.10463-1-rppt@kernel.org> <20200122185017.GA17321@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: kernel-team@android.com, Anshuman Khandual , Catalin Marinas , linux-kernel@vger.kernel.org, Russell King , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Mike Rapoport , Will Deacon , kvmarm@lists.cs.columbia.edu, Mike Rapoport 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 Hi Marc, On Wednesday 22 Jan 2020 at 18:56:38 (+0000), Marc Zyngier wrote: > But maybe this is the reason we've all been waiting for, for which we > sacrifice 32bit KVM host on the altar of progress, and finally move along. > > Will and I are the only known users, and that'd be a good incentive to > experience some if this 64bit goodness... ;-) Jumping in this discussion a bit randomly, but I just wanted to share some thoughts that hopefully are relevant to this discussion and can be of interest to the community. Context: we have a use-case where guests would need some degree of memory protection from the host for confidentiality reasons. We're currently looking at extending KVM to support this feature by enabling the stage 2 translation for the host (in the NVHE case) so we can prevent it from accessing private guest memory, in addition to many other changes required to make this work properly. We're currently at the prototyping stage, but hopefully we'll be able to share patches soon. I'm bringing this up now because this particular use-case doesn't seem relevant in the arm32 world -- all our potential users are on arm64. However, because of the current structure of the arm/arm64 KVM host code, making significant arm64-specific changes turns out to be really hard. We're currently left with three options: 1. move code from virt/kvm/arm and duplicate it in the arch/arm and arch/arm64 folders so the arm64 version can diverge. I can imagine this duplication isn't exactly an appealing solution from a maintainer's perspective ... 2. do changes in the virt/kvm/arm folder directly, but these must be met with matching changes in the respective arch/ folders. The code added to arch/arm, however, would be practically dead code, largely un-used and un-tested as there will be no real arm32 users of this feature. 3. have lots of kvm_arm_* callbacks stubbed for arm32, but this tends to be really hard to apply to this use-case as some of the changes are really quite intrusive. Obviously, details matter for all of this, and lots of discussions will be needed once the patches are on the list. But the point I'm trying to make here is the following: regardless of the option we end up choosing (most likely a mix of all three), the sole fact that we have to deal with this is clearly slowing down development of the feature. This would a be perfectly reasonable and acceptable overhead if this had to be done to keep 32bit KVM host support for a real user community, but since it doesn't seem to exist (?), fighting with the above options feels like a lot of wasted efforts. (Note: I am not implying that Will and you are not real persons, but well, you see what I mean ;-)). So, this is the end of my daily rant. But hopefully this other example of a real-world feature that's being held back by the 32bit KVM host code will be useful background when/if we go ahead and finally decide stop supporting it. Thanks, Quentin _______________________________________________ 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 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFC06C2D0DB for ; Fri, 24 Jan 2020 12:21:09 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id A5EB4206D4 for ; Fri, 24 Jan 2020 12:21:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZrHcK4go"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="cMFyr4Xh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5EB4206D4 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=r/ZJmauAxI0LUSzpL/ibpzG/QSgxk8wbxKEjjR/0+eo=; b=ZrHcK4goS+N+Xs E6BYns+QedcI/kECkNWwJKenJ1IcEIRMQ05eVFJpI//8JJHmU/SyK8hgq9PyTYNoEjTT1Fmpqk50R 837udfBlGGl5pRxkHJrK007lVv38avORXPNcVlu6I+im2TmfQl3DKUidocNtD8t/ayH6iHxYBHqPl 4kL0b+ftd22jUmEUapJwd7XTQ3IuKRoH5H9qYw5aCy7j/SBo/Y8927C2HmvHVNX139F2YPSOE9OGT 6K3Wcx1BawSeXKC8EFrzl+eEzIgNIsATIbA5LA+xQw0vUOVZKDuxdGfmLjPE6olU994V3DeUaXG0u +JjYLwBUG6Tg1abN+NZg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iuxxS-0003ml-41; Fri, 24 Jan 2020 12:21:06 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iuxxP-0003ln-CO for linux-arm-kernel@lists.infradead.org; Fri, 24 Jan 2020 12:21:04 +0000 Received: by mail-wr1-x443.google.com with SMTP id c14so1726421wrn.7 for ; Fri, 24 Jan 2020 04:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Q5/QGs5gkh2XO+BQ2zRh4RVM54DuioXv50QpwNO/LOs=; b=cMFyr4Xh6yV515G1Qq+7238gv8y/HlkKi/4rDB6GTsgTNRmR41qvT7PZ2twHVSP9qh D0smuhi515A4wWVRtwHtSu2wHrxMvbX7auVyndUubiJrmU7agt48NX0/V74cmH9LQs1C RkanOyFY4U4cvEHWtLbatOG1cyxqEyAqm0Um96aKuPDMfonfVjFkDYJrdkk3sTnWdC1y QiK17UFDkrb+5NS4E1JnK5cXikgYvzO0gKkH0idqWjeUnf1qDy1Dskr30XUYsiC9mrrX /dAs9Kj8wLaDI7RvsWsLChvwOE9D0HUIvys2vSFyUMFzGYYetTx+/MKDP6UiVbqDJ04K bbhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Q5/QGs5gkh2XO+BQ2zRh4RVM54DuioXv50QpwNO/LOs=; b=aKMldoggrxupk3iVm/5bduh7zdm7hRxFda3iGz/Q00DXPGMuHrzq8BVI0/nGgw89nm mll0SdkBdht2xIWrnhyN2r6QESc3eYgrvOTtSVJL+uaMi1jPrAiCa2PiT7LxgZ4uiq2Y 0iPMpN7eXo+HxhvtMWWbD2kVGZ+lZ4CUT7k2GQxe6SONhGKFaiGlq7SAD+D4rHliLNUq iLevs17BOk474St3DZsnscjH256jcUi5wXealg2AYVWRWNkxhLJ8GCrG1QCBpqOiNvAV hwtWPYduDKss6nUiY+h+CzmoEwz5GP98xj0Z1brpnfOq5OE03Pi+AWdbsFdM25CKK+UB riGA== X-Gm-Message-State: APjAAAXP0y2uFSqX/P+UAJKBzzL6IN8Mz5pabUr5nrN921mU+I+gvDkd X3gReVHpqKNQ3UVsKOdCsBnBnd4dWIr5Ig== X-Google-Smtp-Source: APXvYqwc1Foj2c7KnaKvacpILFbKY0n7Gl1OeFMdCaXfhHe+gYzfLhnQoBCMml+AofYQ5iRp2XnYpw== X-Received: by 2002:a5d:68c5:: with SMTP id p5mr3938040wrw.193.1579868457525; Fri, 24 Jan 2020 04:20:57 -0800 (PST) Received: from google.com ([2a00:79e0:d:110:d6cc:2030:37c1:9964]) by smtp.gmail.com with ESMTPSA id u7sm6587819wmj.3.2020.01.24.04.20.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jan 2020 04:20:56 -0800 (PST) Date: Fri, 24 Jan 2020 12:20:53 +0000 From: Quentin Perret To: Marc Zyngier Subject: Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables Message-ID: <20200124122053.GA150292@google.com> References: <20200113111323.10463-1-rppt@kernel.org> <20200122185017.GA17321@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200124_042103_426294_098CB892 X-CRM114-Status: GOOD ( 18.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kernel-team@android.com, Anshuman Khandual , Catalin Marinas , linux-kernel@vger.kernel.org, Russell King , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Mike Rapoport , Will Deacon , kvmarm@lists.cs.columbia.edu, Mike Rapoport Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Marc, On Wednesday 22 Jan 2020 at 18:56:38 (+0000), Marc Zyngier wrote: > But maybe this is the reason we've all been waiting for, for which we > sacrifice 32bit KVM host on the altar of progress, and finally move along. > > Will and I are the only known users, and that'd be a good incentive to > experience some if this 64bit goodness... ;-) Jumping in this discussion a bit randomly, but I just wanted to share some thoughts that hopefully are relevant to this discussion and can be of interest to the community. Context: we have a use-case where guests would need some degree of memory protection from the host for confidentiality reasons. We're currently looking at extending KVM to support this feature by enabling the stage 2 translation for the host (in the NVHE case) so we can prevent it from accessing private guest memory, in addition to many other changes required to make this work properly. We're currently at the prototyping stage, but hopefully we'll be able to share patches soon. I'm bringing this up now because this particular use-case doesn't seem relevant in the arm32 world -- all our potential users are on arm64. However, because of the current structure of the arm/arm64 KVM host code, making significant arm64-specific changes turns out to be really hard. We're currently left with three options: 1. move code from virt/kvm/arm and duplicate it in the arch/arm and arch/arm64 folders so the arm64 version can diverge. I can imagine this duplication isn't exactly an appealing solution from a maintainer's perspective ... 2. do changes in the virt/kvm/arm folder directly, but these must be met with matching changes in the respective arch/ folders. The code added to arch/arm, however, would be practically dead code, largely un-used and un-tested as there will be no real arm32 users of this feature. 3. have lots of kvm_arm_* callbacks stubbed for arm32, but this tends to be really hard to apply to this use-case as some of the changes are really quite intrusive. Obviously, details matter for all of this, and lots of discussions will be needed once the patches are on the list. But the point I'm trying to make here is the following: regardless of the option we end up choosing (most likely a mix of all three), the sole fact that we have to deal with this is clearly slowing down development of the feature. This would a be perfectly reasonable and acceptable overhead if this had to be done to keep 32bit KVM host support for a real user community, but since it doesn't seem to exist (?), fighting with the above options feels like a lot of wasted efforts. (Note: I am not implying that Will and you are not real persons, but well, you see what I mean ;-)). So, this is the end of my daily rant. But hopefully this other example of a real-world feature that's being held back by the 32bit KVM host code will be useful background when/if we go ahead and finally decide stop supporting it. Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 036A3C2D0DB for ; Fri, 24 Jan 2020 12:21:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A50E820708 for ; Fri, 24 Jan 2020 12:21:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="cMFyr4Xh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A50E820708 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 423AE6B026E; Fri, 24 Jan 2020 07:21:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D2826B026F; Fri, 24 Jan 2020 07:21:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C1C16B0270; Fri, 24 Jan 2020 07:21:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 182CB6B026E for ; Fri, 24 Jan 2020 07:21:00 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id C77A4180AD807 for ; Fri, 24 Jan 2020 12:20:59 +0000 (UTC) X-FDA: 76412437038.29.rifle11_42d419da6db21 X-HE-Tag: rifle11_42d419da6db21 X-Filterd-Recvd-Size: 6413 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jan 2020 12:20:59 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id q6so1717317wro.9 for ; Fri, 24 Jan 2020 04:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Q5/QGs5gkh2XO+BQ2zRh4RVM54DuioXv50QpwNO/LOs=; b=cMFyr4Xh6yV515G1Qq+7238gv8y/HlkKi/4rDB6GTsgTNRmR41qvT7PZ2twHVSP9qh D0smuhi515A4wWVRtwHtSu2wHrxMvbX7auVyndUubiJrmU7agt48NX0/V74cmH9LQs1C RkanOyFY4U4cvEHWtLbatOG1cyxqEyAqm0Um96aKuPDMfonfVjFkDYJrdkk3sTnWdC1y QiK17UFDkrb+5NS4E1JnK5cXikgYvzO0gKkH0idqWjeUnf1qDy1Dskr30XUYsiC9mrrX /dAs9Kj8wLaDI7RvsWsLChvwOE9D0HUIvys2vSFyUMFzGYYetTx+/MKDP6UiVbqDJ04K bbhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Q5/QGs5gkh2XO+BQ2zRh4RVM54DuioXv50QpwNO/LOs=; b=kPS28XXupSeBDEhwEvvvkWWyFEftU3ORk+yf7ZYhGGdtu6/rxiEcQKx3MPm01l4gat oPJFwI3CoHduFhabhLjyZGwzyqASyWyZUBhbaW04+YiE6y0RT/IfLndDCM44/UxvR+gi IfPT2Z0i4DlU1KDMKeJGysCN3eDMi2GH8gSxa0dhNF4mozelSMIfYRl0tA6VSPOCDGjE criV1IeEDsirGu8Rb2AKhuCV/Jvm5+ZO0WhKAYb88EgRNl9eVFwyWqzPVdefXmlGy2B8 IcAxI0bUvJfriCB7/ovGNoVs3mPXhKHGyryEgyHkvRlQM0GFZd/U2EvoB4m3h8pfRJOG FLOQ== X-Gm-Message-State: APjAAAVw/OH7vo34/T6LO0sFWoiNyVVXiHqJriBiT6VQKyM9ZV0I/iul 3RVVQFNFdo1PsCnu+JT9d8cdFg== X-Google-Smtp-Source: APXvYqwc1Foj2c7KnaKvacpILFbKY0n7Gl1OeFMdCaXfhHe+gYzfLhnQoBCMml+AofYQ5iRp2XnYpw== X-Received: by 2002:a5d:68c5:: with SMTP id p5mr3938040wrw.193.1579868457525; Fri, 24 Jan 2020 04:20:57 -0800 (PST) Received: from google.com ([2a00:79e0:d:110:d6cc:2030:37c1:9964]) by smtp.gmail.com with ESMTPSA id u7sm6587819wmj.3.2020.01.24.04.20.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jan 2020 04:20:56 -0800 (PST) Date: Fri, 24 Jan 2020 12:20:53 +0000 From: Quentin Perret To: Marc Zyngier Cc: Will Deacon , Mike Rapoport , Anshuman Khandual , Catalin Marinas , Russell King , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Mike Rapoport , kvmarm@lists.cs.columbia.edu, kernel-team@android.com Subject: Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables Message-ID: <20200124122053.GA150292@google.com> References: <20200113111323.10463-1-rppt@kernel.org> <20200122185017.GA17321@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Marc, On Wednesday 22 Jan 2020 at 18:56:38 (+0000), Marc Zyngier wrote: > But maybe this is the reason we've all been waiting for, for which we > sacrifice 32bit KVM host on the altar of progress, and finally move along. > > Will and I are the only known users, and that'd be a good incentive to > experience some if this 64bit goodness... ;-) Jumping in this discussion a bit randomly, but I just wanted to share some thoughts that hopefully are relevant to this discussion and can be of interest to the community. Context: we have a use-case where guests would need some degree of memory protection from the host for confidentiality reasons. We're currently looking at extending KVM to support this feature by enabling the stage 2 translation for the host (in the NVHE case) so we can prevent it from accessing private guest memory, in addition to many other changes required to make this work properly. We're currently at the prototyping stage, but hopefully we'll be able to share patches soon. I'm bringing this up now because this particular use-case doesn't seem relevant in the arm32 world -- all our potential users are on arm64. However, because of the current structure of the arm/arm64 KVM host code, making significant arm64-specific changes turns out to be really hard. We're currently left with three options: 1. move code from virt/kvm/arm and duplicate it in the arch/arm and arch/arm64 folders so the arm64 version can diverge. I can imagine this duplication isn't exactly an appealing solution from a maintainer's perspective ... 2. do changes in the virt/kvm/arm folder directly, but these must be met with matching changes in the respective arch/ folders. The code added to arch/arm, however, would be practically dead code, largely un-used and un-tested as there will be no real arm32 users of this feature. 3. have lots of kvm_arm_* callbacks stubbed for arm32, but this tends to be really hard to apply to this use-case as some of the changes are really quite intrusive. Obviously, details matter for all of this, and lots of discussions will be needed once the patches are on the list. But the point I'm trying to make here is the following: regardless of the option we end up choosing (most likely a mix of all three), the sole fact that we have to deal with this is clearly slowing down development of the feature. This would a be perfectly reasonable and acceptable overhead if this had to be done to keep 32bit KVM host support for a real user community, but since it doesn't seem to exist (?), fighting with the above options feels like a lot of wasted efforts. (Note: I am not implying that Will and you are not real persons, but well, you see what I mean ;-)). So, this is the end of my daily rant. But hopefully this other example of a real-world feature that's being held back by the 32bit KVM host code will be useful background when/if we go ahead and finally decide stop supporting it. Thanks, Quentin