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.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 75990C43461 for ; Thu, 10 Sep 2020 10:58:58 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 E6E8D20BED for ; Thu, 10 Sep 2020 10:58:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nr4bNtoc"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yu5PpokJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6E8D20BED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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=b36rPw0Eo7CloVjYi5jokUGUAjO+xX9+6u8n0n1CfVk=; b=nr4bNtockWSWHu6JtRdmS6C3I PGk6O78l2qP8ZovvHqfu1kGu6fPf7m3CQMHKyHgaoKS+er6HHZ7Y1lLdBrDDa/RonrjgWyDHHUlow r7jBDrlGcQ31rAMhDwT4Id/10vWDdNgRX3PDUIGY85oiljlF3H4NSh/Pn8WZ6A0kfPKTluFDUnZeA XfXwT5IU4FKyIoG4t54zh6VYFzxy7sjyZLXhytFIRlVRBpfb5lN6nc/visoLw1+qY/Wix6PUQt5Cb sZe/iJa1amKkeuCzg9oq0Z8MyCW1Zjrj20i/gKvFXvMSBF79G5tZfyGZ3nvbKFeZ8PnRtpBH6aCl6 CAX27pKMQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGKGq-0000xi-7R; Thu, 10 Sep 2020 10:57:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGKGk-0000vO-4s for linux-arm-kernel@lists.infradead.org; Thu, 10 Sep 2020 10:57:35 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 37A6B20BED; Thu, 10 Sep 2020 10:57:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599735453; bh=AEAtw8EJgKeoXMPWto+9quUxLrmFhEfBRBwjWEZ2/0Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Yu5PpokJ3ghEAjezuRVBNjyMIUAC6gxk0QekWNAP7XwByeidMT97mVgPOUc4XearW y328m4PQnGmtWHYgT9RPskc9vn8+255FSWhuzcln27GYeiob9U9SboGUOB4v8IZP8y 3elMItzoSrgPPrcEX4cHN5ek8RqCx/v9f52KSiT0= Date: Thu, 10 Sep 2020 11:57:27 +0100 From: Will Deacon To: Gavin Shan Subject: Re: [PATCH v4 02/21] KVM: arm64: Add stand-alone page-table walker infrastructure Message-ID: <20200910105727.GC17887@willie-the-truck> References: <20200907152344.12978-1-will@kernel.org> <20200907152344.12978-3-will@kernel.org> <56510d79-ce08-c058-03f8-10b1a37d05b0@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <56510d79-ce08-c058-03f8-10b1a37d05b0@redhat.com> 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-20200910_065734_294976_CD001AAB X-CRM114-Status: GOOD ( 27.55 ) 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, Suzuki Poulose , Marc Zyngier , Quentin Perret , James Morse , Catalin Marinas , Alexandru Elisei , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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 Tue, Sep 08, 2020 at 10:03:30AM +1000, Gavin Shan wrote: > On 9/8/20 1:23 AM, Will Deacon wrote: > > The KVM page-table code is intricately tied into the kernel page-table > > code and re-uses the pte/pmd/pud/p4d/pgd macros directly in an attempt > > to reduce code duplication. Unfortunately, the reality is that there is > > an awful lot of code required to make this work, and at the end of the > > day you're limited to creating page-tables with the same configuration > > as the host kernel. Furthermore, lifting the page-table code to run > > directly at EL2 on a non-VHE system (as we plan to to do in future > > patches) is practically impossible due to the number of dependencies it > > has on the core kernel. > > > > Introduce a framework for walking Armv8 page-tables configured > > independently from the host kernel. > > > > Cc: Marc Zyngier > > Cc: Quentin Perret > > Signed-off-by: Will Deacon > > --- > > It looks good to me. However, If you get a chance to respin, I guess > it would be nice to add some comments about kvm_block_mapping_supported(). > More details are provoided below. > > Reviewed-by: Gavin Shan [...] > > +static bool kvm_block_mapping_supported(u64 addr, u64 end, u64 phys, u32 level) > > +{ > > + u64 granule = kvm_granule_size(level); > > + > > + /* > > + * Reject invalid block mappings and don't bother with 4TB mappings for > > + * 52-bit PAs. > > + */ > > + if (level == 0 || (PAGE_SIZE != SZ_4K && level == 1)) > > + return false; > > + > > + if (granule > (end - addr)) > > + return false; > > + > > + return IS_ALIGNED(addr, granule) && IS_ALIGNED(phys, granule); > > +} > > + > > If you get a chance to respin, it would be nice to have more comments to > explain why 4TB block mapping is rejected here. I guess it depends on the > fact: hugeTLB/THP doesn't support such kind of huge block mapping yet? It's just because I'm lazy, really :) We don't know if we're using 52-bit PAs here, and I couldn't be bothered to propagate that information given that this doesn't seem like something anybody will be using at the moment. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel