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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 B5812C2BB40 for ; Mon, 7 Dec 2020 13:55:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 93146235FC for ; Mon, 7 Dec 2020 13:55:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726712AbgLGNzc (ORCPT ); Mon, 7 Dec 2020 08:55:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:54838 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726685AbgLGNzb (ORCPT ); Mon, 7 Dec 2020 08:55:31 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 33FD4235DD; Mon, 7 Dec 2020 13:54:51 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kmGyW-00Gm6K-SB; Mon, 07 Dec 2020 13:54:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 07 Dec 2020 13:54:48 +0000 From: Marc Zyngier To: Quentin Perret Cc: Fuad Tabba , Catalin Marinas , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , Rob Herring , Frank Rowand , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , open list , "open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" , kernel-team@android.com, Android KVM Subject: Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection In-Reply-To: References: <20201117181607.1761516-1-qperret@google.com> <20201117181607.1761516-17-qperret@google.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: qperret@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, robh+dt@kernel.org, frowand.list@gmail.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu, devicetree@vger.kernel.org, kernel-team@android.com, android-kvm@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 2020-12-07 11:58, Quentin Perret wrote: > On Monday 07 Dec 2020 at 11:16:05 (+0000), Fuad Tabba wrote: >> On Fri, Dec 4, 2020 at 6:01 PM Quentin Perret >> wrote: >> > >> > On Thursday 03 Dec 2020 at 12:57:33 (+0000), Fuad Tabba wrote: >> > >> > > > +int hyp_create_idmap(void); >> > > > +int hyp_map_vectors(void); >> > > > +int hyp_back_vmemmap(phys_addr_t phys, unsigned long size, phys_addr_t back); >> > > > +int hyp_cpu_set_vector(enum arm64_hyp_spectre_vector slot); >> > > > +int hyp_create_mappings(void *from, void *to, enum kvm_pgtable_prot prot); >> > > > +int __hyp_create_mappings(unsigned long start, unsigned long size, >> > > > + unsigned long phys, unsigned long prot); >> > > > +unsigned long __hyp_create_private_mapping(phys_addr_t phys, size_t size, >> > > > + unsigned long prot); >> > > > + >> > > >> > > nit: I also thought that the hyp_create_mappings function names are a >> > > bit confusing, since there's the create_hyp_mappings functions which >> > > use the aforementioned *hyp_pgtable. >> > >> > Sure, happy to re-name those (and hyp_pgtable above). Any suggestions? >> >> Perhaps something to indicate that these are temporary, tmp_ or >> bootstrap_ maybe? > > Hmm, the thing is these are temporary only in protected mode, they're > permanent otherwise :/ > > Perhaps I could prefix the protected pgtable (and associated functions) > with 'pkvm_' or so? Marc, any preferences? None. Whichever name you pick, someone will ask you to change it. Just call it Bob. What I really *don't* want is see a blanket rename of existing symbols or concepts. Thanks, M. -- Jazz is not dead. It just smells funny...