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.4 required=3.0 tests=BAYES_00,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 5507FC433B4 for ; Tue, 18 May 2021 12:16:48 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 CE24760FF1 for ; Tue, 18 May 2021 12:16:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE24760FF1 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=desiato.20200630; 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=vdfU/fyGnCGfAXUZj2wa1TGqSLb04jwGWjceW3613bk=; b=DyPydsyEehpu0sClRdGcBnDCR 3HLzx9r9mwAszuh2VTpp1r2tV7k3OCU9uF313Chroaisuqjej8TpVJPxz0DUVT4M4kmv7o8uXanqD tJrWMB9YQlCS2X74xQhU0N4cJzV56239FXMb8wiWrNj4hzNKEDR6zX0Htmy7WxJkM2o4N3cfXzGw8 vcQt6ZMIZN2HWFEAP2/lDSB1U5AOma1p4P6bU18YIYKWK4BHp0tq5Cqq8NhrVwS6QQmLDFEOnYBfA XAYNcDO3/dyAMeX8PeA1/J8416C1xvUzd3FFLtJs1aylPocREWiMtzxp9kyICxkOzjE82Zw+Y68iB eSHj/WWHw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1liycT-000io7-2R; Tue, 18 May 2021 12:14:41 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1liycP-000inc-8w for linux-arm-kernel@desiato.infradead.org; Tue, 18 May 2021 12:14:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:MIME-Version:References: In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=yEoGfBqxd7b1FVcb+yLeMLQ6wWnvXTAfgKwllkdgN1o=; b=AR6Obp6ZKVZh8m2Nq5TdgyXK84 3gCjEuuQw867MPJxoOVaQomHHxrZ7hb3DzJX/nOoJl641HAPoHFckOUaDVU/TxV2uLqe2NUnHXsI5 TRL3sThFSNoSLXorbtQwokyskBoXC+0DyJOhyUUwOdGqliAk8wbShbJ+QVrD5i8HDCcT+93ZjnbRf vwCGS1qk5oDqXwa3PJe02V3ph9BUOh7kR0PszQQZCIveaPbPdTwOo59m2/F/4b/WfsDAIemeI91Xw fihbXOwRacRKn/xhPKZfowRxbHcf0wUxSYrimZoRY1knUHTKrTlB78NuvRkhDKHxQT/sWgGW+ofx9 mCjxXWhA==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1liycM-00Edl6-Ob for linux-arm-kernel@lists.infradead.org; Tue, 18 May 2021 12:14:36 +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 76F4A60C41; Tue, 18 May 2021 12:14:34 +0000 (UTC) Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.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 1liycK-0024Dx-D4; Tue, 18 May 2021 13:14:32 +0100 Date: Tue, 18 May 2021 13:14:30 +0100 Message-ID: <87mtsstf15.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Mark Rutland , Lorenzo Pieralisi , Sudeep Holla , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1 2/2] arm64: smccc: Support SMCCC v1.3 SVE register saving hint In-Reply-To: <20210518115348.GA4358@sirena.org.uk> References: <20210518100919.6674-1-broonie@kernel.org> <20210518100919.6674-3-broonie@kernel.org> <87pmxotirl.wl-maz@kernel.org> <20210518115348.GA4358@sirena.org.uk> 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 (x86_64-pc-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: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.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-20210518_051434_859844_AD89EC48 X-CRM114-Status: GOOD ( 27.61 ) 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 Tue, 18 May 2021 12:53:48 +0100, Mark Brown wrote: > > [1 ] > On Tue, May 18, 2021 at 11:53:50AM +0100, Marc Zyngier wrote: > > Mark Brown wrote: > > > > +alternative_if ARM64_SVE > > > + > > > + adrp x15, smccc_has_sve_hint > > > The adrp instruction will give you a 4kB aligned address, which > > results in 1 chance out of 512 to point to the right location. The > > adr_l macro is probably what you want. > > Ouch, yes. This was working surprisingly well in my testing. It always does. In my experience, it starts failing the minute you push the code out. Sod's law. > > > > register unsigned long r2 asm("r2"); \ > > > register unsigned long r3 asm("r3"); \ > > > __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > > > - asm volatile(inst "\n" : \ > > > + asm volatile(SMCCC_SVE_CHECK \ > > > What happens when this is called from a context where > > __smccc_sve_check isn't mapped, nor does "current" mean anything? See > > arch/arm64/kvm/hyp/nvhe/psci-relay.c for an example. > > Ah, oh dear. I have to admit I haven't entirely been able to follow the > contexts the various bits of KVM run in yet, nor how much of the normal > kernel environment is being maintained :/ . A good approximation is *none*. We have the hypervisor text, and some data that we map as required. But unless the functions have been compiled as part of the hypervisor object, this won't go anywhere. I'm surprised it would even link, TBH, due to the symbol repainting that we have to prevent linking against unsuspecting kernel symbols. > I do see some ifdefery with __KVM_NVHE_HYPERVISOR__ elsewhere which > could be used to take care of that particular case either by > providing a __hyp mapping or just not trying to set the flag there > (the latter seems safer) but I'm guessing there's others. Do we > have a reliable way of identifying such contexts? __KVM_NVHE_HYPERVISOR__ usually is a good indication that we're compiling for the nVHE EL2 object. I guess that skipping the optimisation would be good enough for KVM, until we decide to provide a nVHE-specific helper that uses the private per-cpu information. 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