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.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 BD359C433E0 for ; Thu, 25 Jun 2020 08:12:59 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 4582A2067D for ; Thu, 25 Jun 2020 08:12:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wajtMIDF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4582A2067D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 B8A084B493; Thu, 25 Jun 2020 04:12:58 -0400 (EDT) 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=@kernel.org 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 3qjarM-hsSDk; Thu, 25 Jun 2020 04:12:56 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 89F664B495; Thu, 25 Jun 2020 04:12:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B39024B493 for ; Thu, 25 Jun 2020 04:12:54 -0400 (EDT) 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 ojpuwkHS2nkP for ; Thu, 25 Jun 2020 04:12:53 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 7C4864B489 for ; Thu, 25 Jun 2020 04:12:53 -0400 (EDT) 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 4FFDB2067D; Thu, 25 Jun 2020 08:12:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593072772; bh=hFDSF6sOyHk09xBbSGXCSJ7Em905+sQZ3Jw5UdSgHV8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=wajtMIDFxtK5LLIDrbKmwtzS9/M5CgCQN4zTXbE8/DDNcLXzi1STfYFv+j/nOtPfH ZFDQkMzjJ20GLc/xMuQOC0szrItUDL/GJ315KGMpP8iDpI40ybpQi787V/BTBo9yYP 76PYC2BW92IQ47rgvV3RC2Jmg+W+2lEEg8y5qn2c= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1joN06-006HRd-Mb; Thu, 25 Jun 2020 09:12:50 +0100 MIME-Version: 1.0 Date: Thu, 25 Jun 2020 09:12:50 +0100 From: Marc Zyngier To: David Brazdil Subject: Re: [PATCH v3 05/15] arm64: kvm: Build hyp-entry.S separately for VHE/nVHE In-Reply-To: <20200622102041.myve2otyoj5q7j5s@google.com> References: <20200618122537.9625-1-dbrazdil@google.com> <20200618122537.9625-6-dbrazdil@google.com> <5029f8fb4a7816e11de7469c09347c79@kernel.org> <20200622102041.myve2otyoj5q7j5s@google.com> User-Agent: Roundcube Webmail/1.4.5 Message-ID: <491f3c8877897a4ac69d69fb7354c1cb@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: dbrazdil@google.com, will@kernel.org, catalin.marinas@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kernel-team@android.com, android-kvm@google.com, Catalin Marinas , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Will Deacon , kvmarm@lists.cs.columbia.edu 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi David, On 2020-06-22 11:20, David Brazdil wrote: > Hi Marc, > >> > - void *dst = lm_alias(__bp_harden_hyp_vecs + slot * SZ_2K); >> > + char *vec = has_vhe() ? __bp_harden_hyp_vecs >> > + : kvm_nvhe_sym(__bp_harden_hyp_vecs); >> >> If we get this construct often, then something that abstracts >> the uggliness of the symbol duality would be nice... > > Agreed, I do hope that this will end up being limited to finding the > address of > the hyp-init vector once EL2 becomes self-contained. Even this vector > selection > can be done in EL2 where the symbol duality does not exist. > If we were to hide it, there is a trade off between code "elegance" and > clarity > of what's happening under the hood. I was thinking we could extract > this > `has_vhe() ? foo : __kvm_nvhe_foo` as a `#define foo` but I do worry > that > anybody debugging this code would be cursing my name. I would say that whoever is debugging this code better have an understanding of how things are supposed to work. Given that this is only a handful of people so far, I think your name is safe! ;-) > It would also not work > with other macros that take symbol names, notably kvm_ksym_ref. But > that can be > rewritten to accept a pointer instead. The more verbose but less magic > approach > is to have a bunch of different helpers for various situations, eg. > __pa_symbol_nvhe. What would be your preference? I'd be happy with the (maybe temporary) magic approach. It helps reasoning about things, and makes the transition smoother. Yes, bugs could crop up there, but given the static nature of obtaining a symbol's address, I'm fairly confident we'll get it right. The same cannot be said about pointers though. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ 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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 76485C433DF for ; Thu, 25 Jun 2020 08:14:40 +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 417E02067D for ; Thu, 25 Jun 2020 08:14:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="IL8XtUJn"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wajtMIDF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 417E02067D 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7+2uj4wGxr38MEbBIOhGfVJVRpkqaHYz/Xkeh7YU7GM=; b=IL8XtUJnkX3Gl8gLYye46LP0U qOa8jWVO2r0MuJQGhunD0ocfSaGWCfzCqXcC3uTSSanePKwwTeBiRtGUJAsC9O6GxLzYKGx9IXTYJ lC7pgugcDKx1iCnBuR+rKi7C7SWRm7DRQF03HDfGUIJPB8w5lKoZmsixaPNA5DdMcQsliAWsbr29q m68CXHMJcoh2QaZ5dwBRZZ9ebQRRJ32lVk6SnRTYqbAQkOONmgv+Nlw0Xer9HVc79+C8SvdsT34Ri ncMXJo+QgL/wM61EBLRiNhLhrXYYRAd7ZJMyjqvDdNv3VAc+aAoru1sxFV1o+2KZlzlZmewKNyG7N EBhyvrl8Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1joN0B-0006Ed-ND; Thu, 25 Jun 2020 08:12:55 +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 1joN09-0006E7-8l for linux-arm-kernel@lists.infradead.org; Thu, 25 Jun 2020 08:12:54 +0000 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 4FFDB2067D; Thu, 25 Jun 2020 08:12:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593072772; bh=hFDSF6sOyHk09xBbSGXCSJ7Em905+sQZ3Jw5UdSgHV8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=wajtMIDFxtK5LLIDrbKmwtzS9/M5CgCQN4zTXbE8/DDNcLXzi1STfYFv+j/nOtPfH ZFDQkMzjJ20GLc/xMuQOC0szrItUDL/GJ315KGMpP8iDpI40ybpQi787V/BTBo9yYP 76PYC2BW92IQ47rgvV3RC2Jmg+W+2lEEg8y5qn2c= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1joN06-006HRd-Mb; Thu, 25 Jun 2020 09:12:50 +0100 MIME-Version: 1.0 Date: Thu, 25 Jun 2020 09:12:50 +0100 From: Marc Zyngier To: David Brazdil Subject: Re: [PATCH v3 05/15] arm64: kvm: Build hyp-entry.S separately for VHE/nVHE In-Reply-To: <20200622102041.myve2otyoj5q7j5s@google.com> References: <20200618122537.9625-1-dbrazdil@google.com> <20200618122537.9625-6-dbrazdil@google.com> <5029f8fb4a7816e11de7469c09347c79@kernel.org> <20200622102041.myve2otyoj5q7j5s@google.com> User-Agent: Roundcube Webmail/1.4.5 Message-ID: <491f3c8877897a4ac69d69fb7354c1cb@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: dbrazdil@google.com, will@kernel.org, catalin.marinas@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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 K Poulose , android-kvm@google.com, Catalin Marinas , linux-kernel@vger.kernel.org, James Morse , linux-arm-kernel@lists.infradead.org, Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi David, On 2020-06-22 11:20, David Brazdil wrote: > Hi Marc, > >> > - void *dst = lm_alias(__bp_harden_hyp_vecs + slot * SZ_2K); >> > + char *vec = has_vhe() ? __bp_harden_hyp_vecs >> > + : kvm_nvhe_sym(__bp_harden_hyp_vecs); >> >> If we get this construct often, then something that abstracts >> the uggliness of the symbol duality would be nice... > > Agreed, I do hope that this will end up being limited to finding the > address of > the hyp-init vector once EL2 becomes self-contained. Even this vector > selection > can be done in EL2 where the symbol duality does not exist. > If we were to hide it, there is a trade off between code "elegance" and > clarity > of what's happening under the hood. I was thinking we could extract > this > `has_vhe() ? foo : __kvm_nvhe_foo` as a `#define foo` but I do worry > that > anybody debugging this code would be cursing my name. I would say that whoever is debugging this code better have an understanding of how things are supposed to work. Given that this is only a handful of people so far, I think your name is safe! ;-) > It would also not work > with other macros that take symbol names, notably kvm_ksym_ref. But > that can be > rewritten to accept a pointer instead. The more verbose but less magic > approach > is to have a bunch of different helpers for various situations, eg. > __pa_symbol_nvhe. What would be your preference? I'd be happy with the (maybe temporary) magic approach. It helps reasoning about things, and makes the transition smoother. Yes, bugs could crop up there, but given the static nature of obtaining a symbol's address, I'm fairly confident we'll get it right. The same cannot be said about pointers though. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ 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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 444D8C433DF for ; Thu, 25 Jun 2020 08:12:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 064002076E for ; Thu, 25 Jun 2020 08:12:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593072775; bh=hFDSF6sOyHk09xBbSGXCSJ7Em905+sQZ3Jw5UdSgHV8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=gNnzQnXC8nDxX0b1xaKbPrX13HXkjZB8ni37IfVuWCzdmeVc1gIdmJ8E6dSmzLYiP guLsn4BJVoT2UeG5mz95pGByYSVYUzcqgooFDdQw0RQ+DhQo3DEfNNpAYEObs9370h Yyr+xHLLLzAORqkXMMMfGyxgImAVocQWBjI2BmlE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390511AbgFYIMx (ORCPT ); Thu, 25 Jun 2020 04:12:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:38558 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726930AbgFYIMx (ORCPT ); Thu, 25 Jun 2020 04:12:53 -0400 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 4FFDB2067D; Thu, 25 Jun 2020 08:12:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593072772; bh=hFDSF6sOyHk09xBbSGXCSJ7Em905+sQZ3Jw5UdSgHV8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=wajtMIDFxtK5LLIDrbKmwtzS9/M5CgCQN4zTXbE8/DDNcLXzi1STfYFv+j/nOtPfH ZFDQkMzjJ20GLc/xMuQOC0szrItUDL/GJ315KGMpP8iDpI40ybpQi787V/BTBo9yYP 76PYC2BW92IQ47rgvV3RC2Jmg+W+2lEEg8y5qn2c= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1joN06-006HRd-Mb; Thu, 25 Jun 2020 09:12:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 25 Jun 2020 09:12:50 +0100 From: Marc Zyngier To: David Brazdil Cc: Will Deacon , Catalin Marinas , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, kernel-team@android.com Subject: Re: [PATCH v3 05/15] arm64: kvm: Build hyp-entry.S separately for VHE/nVHE In-Reply-To: <20200622102041.myve2otyoj5q7j5s@google.com> References: <20200618122537.9625-1-dbrazdil@google.com> <20200618122537.9625-6-dbrazdil@google.com> <5029f8fb4a7816e11de7469c09347c79@kernel.org> <20200622102041.myve2otyoj5q7j5s@google.com> User-Agent: Roundcube Webmail/1.4.5 Message-ID: <491f3c8877897a4ac69d69fb7354c1cb@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: dbrazdil@google.com, will@kernel.org, catalin.marinas@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On 2020-06-22 11:20, David Brazdil wrote: > Hi Marc, > >> > - void *dst = lm_alias(__bp_harden_hyp_vecs + slot * SZ_2K); >> > + char *vec = has_vhe() ? __bp_harden_hyp_vecs >> > + : kvm_nvhe_sym(__bp_harden_hyp_vecs); >> >> If we get this construct often, then something that abstracts >> the uggliness of the symbol duality would be nice... > > Agreed, I do hope that this will end up being limited to finding the > address of > the hyp-init vector once EL2 becomes self-contained. Even this vector > selection > can be done in EL2 where the symbol duality does not exist. > If we were to hide it, there is a trade off between code "elegance" and > clarity > of what's happening under the hood. I was thinking we could extract > this > `has_vhe() ? foo : __kvm_nvhe_foo` as a `#define foo` but I do worry > that > anybody debugging this code would be cursing my name. I would say that whoever is debugging this code better have an understanding of how things are supposed to work. Given that this is only a handful of people so far, I think your name is safe! ;-) > It would also not work > with other macros that take symbol names, notably kvm_ksym_ref. But > that can be > rewritten to accept a pointer instead. The more verbose but less magic > approach > is to have a bunch of different helpers for various situations, eg. > __pa_symbol_nvhe. What would be your preference? I'd be happy with the (maybe temporary) magic approach. It helps reasoning about things, and makes the transition smoother. Yes, bugs could crop up there, but given the static nature of obtaining a symbol's address, I'm fairly confident we'll get it right. The same cannot be said about pointers though. Thanks, M. -- Jazz is not dead. It just smells funny...