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 0EF77C636CD for ; Fri, 10 Feb 2023 16:42:03 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=aaT4+dpSGoL6VTYDZUFzD8kvaHy7NJ+8XAFQhMKlzoE=; b=r720tP8dPF4hty U6B8YC0GyYq2ulbRUKn9thJzy0jshyogs/kdXv6EmX1qru+mWwsMvVd4/zZZNaCGn0tLrkgkQChNK puBsEgefIzZ9hX8GK5tceOY4FuJBE4qOCbqo1JpeC6qEBHmKXNkYpOHNY80aiWafgX/nsZdHBuft0 69auInt8YbUoSAOp2yMmY8sdiIXkWLX3yoxwNdc6PdpvNXnTJi4cwgTRzh8ndoIlUQx9KTyfRD978 8yMgJiWoXP5mr5TXSijt12r4XYWytsNq4hrm4d+96cdUtqZyHp4wjT5K0nhHbPJ+8RcrmABscIjPw Oojb+t582ewSC7A87LdQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQWSL-006Z6t-MS; Fri, 10 Feb 2023 16:41:01 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQWSH-006Z5m-G4 for linux-arm-kernel@lists.infradead.org; Fri, 10 Feb 2023 16:40:59 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 37B554B3; Fri, 10 Feb 2023 08:41:35 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.90.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0EEFD3F703; Fri, 10 Feb 2023 08:40:50 -0800 (PST) Date: Fri, 10 Feb 2023 16:40:33 +0000 From: Mark Rutland To: Marc Zyngier Cc: Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, Will Deacon , Catalin Marinas , Peter Zijlstra , Quentin Perret , Kees Cook Subject: Re: [RFC PATCH] arm64: Move HYP text out of kernel mapping Message-ID: References: <20230210100006.1161696-1-ardb@kernel.org> <86a61lzqcu.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <86a61lzqcu.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230210_084057_617877_88385185 X-CRM114-Status: GOOD ( 21.87 ) 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, Feb 10, 2023 at 11:56:01AM +0000, Marc Zyngier wrote: > On Fri, 10 Feb 2023 10:00:06 +0000, > Ard Biesheuvel wrote: > > So the questions are: > > a) Mark pointed out off-list that he has been getting rid of static keys > > in favor of alternatives in the arch code, as those are guaranteed to > > be patched only once. Should we try to get rid of these as well? > > The question is whether we can use these alternatives at such a late > point in the boot process. Today, we are done with the alternatives as > soon as all the early CPUs are up. My thinking is that anything pKVM relies upon must be settled around that time (and certainly before any late secondaries are onlined), so we should be able to pull the few remaining bits and pieces a little earlier. > > b) These look like they are set only once and never turned off again. > > The pKVM one is definitely only set at boot time, but I couldn't > > figure out whether the same applies to the PMU one? > > Yes, the PMU is in the same bag. As soon as we have found an > architectural PMU *and* that the driver has been registered, we're > good. As above, I was hoping we could somehow pull that before patching. > But we cannot just rely on the CPU ID regs as the perf backend > could fail to register. I thought pKVM just cared about homgeneity here, and was hiding the PMU state from the host, so does it matter what the host does, and if the host fails to register a perf backend? It doesn't seem right that pKVM would rely upon the host to manage the PMU given pKVM cannot trust the host... Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel