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 B08EDC433F5 for ; Wed, 2 Mar 2022 07:47:53 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MC5mODNVUaMvccR2Fi2a42pPJv99c5tjWPKm76sjfYk=; b=HIlsWj5U+81Wot ggJTf/2Qt9nyVnMTgsSXUDtmQdYMgeTnsdkjvhtRFV+OBCpFx4PknH/a+2k8wrCeydTzWXOG7DGr2 ff5j64YTB9Z1qtUqVWH/ZSuMthTGOpxZinh1p3k3NAzJiDxhDe1+rFcQCe89BkXer2RAXq37mZxEO nROFRXW4j6N0LTGCMz7Lc2OcEZ43boZ4lowJFuFRfbpZL0/0sMJpYrkB8brT29TR2HXWRwXRhtZOB y7w7qXuGCeHJXelCNbS+ZEcjCUAOxabRkMmzAtZxyhZqfdHE2aaqPipkzFPcpdG4Mxmn/FuGFDgov qKKUVzlA1xQpr42w7IRQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPJhC-001l32-Ro; Wed, 02 Mar 2022 07:46:51 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPJh9-001l2D-UO for linux-arm-kernel@lists.infradead.org; Wed, 02 Mar 2022 07:46:49 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 09585B81F1D; Wed, 2 Mar 2022 07:46:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3297C340EF; Wed, 2 Mar 2022 07:46:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646207204; bh=saY4uFacqmTSqZECGMkmCoPAAs90t/+LOjZSwwOwbOs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ADExU80jY0rCuB1MLxUsZbsn2dmH1n/N7E8zpyl2JnH93MaN8Q5ol/fmRPgUsmc2T avv7Uo44zr8igfL2hCz8WrnE396s23ZKOjSWgEo3xPmkfsLp31XbAdezPOWqH1alTw hVyNKN02A/lBCyhc9mto47EraNfvWJpPpuOCGIg6cIh66GJ8aUgvJq6aAyU9pm0ayl VkR9dwE042ukx+SD8foK1q9DsH0dmkpWX8MCNmjWn0Tfbwr6FrVmKO5vBocVrRnrjC +dJ0k6mgIqsM+LYxDOhcNDRQs8tZuUqukTNLqrLBAdmWIuQRWjKfMbZmduLx0nuify Ph/Lt18XMf1wg== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=billy-the-mountain.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nPJh3-00BbhG-UP; Wed, 02 Mar 2022 07:46:42 +0000 Date: Wed, 02 Mar 2022 07:46:35 +0000 Message-ID: <87v8ww6bl0.wl-maz@kernel.org> From: Marc Zyngier To: Kalesh Singh Cc: will@kernel.org, qperret@google.com, tabba@google.com, surenb@google.com, kernel-team@android.com, James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Mark Rutland , Mark Brown , Masami Hiramatsu , Peter Collingbourne , "Madhavan T. Venkataraman" , Andrew Scull , Paolo Bonzini , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/8] KVM: arm64: Introduce pkvm_alloc_private_va_range() In-Reply-To: <20220225033548.1912117-3-kaleshsingh@google.com> References: <20220225033548.1912117-1-kaleshsingh@google.com> <20220225033548.1912117-3-kaleshsingh@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: kaleshsingh@google.com, will@kernel.org, qperret@google.com, tabba@google.com, surenb@google.com, kernel-team@android.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, mark.rutland@arm.com, broonie@kernel.org, mhiramat@kernel.org, pcc@google.com, madvenka@linux.microsoft.com, ascull@google.com, pbonzini@redhat.com, ardb@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220301_234648_300059_49A63E65 X-CRM114-Status: GOOD ( 20.48 ) 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, 25 Feb 2022 03:34:47 +0000, Kalesh Singh wrote: > > pkvm_hyp_alloc_private_va_range() can be used to reserve private VA ranges > in the pKVM nVHE hypervisor (). Also update __pkvm_create_private_mapping() > to allow specifying an alignment for the private VA mapping. > > These will be used to implement stack guard pages for pKVM nVHE hypervisor > (in a subsequent patch in the series). > > Credits to Quentin Perret for the idea of moving > private VA allocation out of __pkvm_create_private_mapping() > > Signed-off-by: Kalesh Singh > --- > > Changes in v4: > - Handle null ptr in pkvm_alloc_private_va_range() and replace > IS_ERR_OR_NULL checks in callers with IS_ERR checks, per Fuad > - Fix kernel-doc comments format, per Fuad > - Format __pkvm_create_private_mapping() prototype args (< 80 col), per Fuad > > Changes in v3: > - Handle null ptr in IS_ERR_OR_NULL checks, per Mark > > Changes in v2: > - Allow specifying an alignment for the private VA allocations, per Marc I probably badly expressed my earlier concern. Yes, an alignment is necessary. But how often do we want an alignment that isn't naturally aligned to the size of the allocation (i.e. the power of 2 >= the size of the allocation)? This is what the rest of the kernel does (get_order() and co), and I thing we should follow this. This applies to both this patch and the previous one. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel