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 A18E1C25B74 for ; Mon, 13 May 2024 14:33:45 +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=gNAW/UbXjSEeyjJRd4lVzsxre28eId+zRiDJyAFD8Fs=; b=jxit9FUo8XERc8 1VBJ3QgSn12TRiWNcEkpdrygRPqMwfwcHBKd1m37CaQnhSTaMTE98fE8bbcVhJjhst+ofqGAuiiMW +1xEHh8lPqzR0zDDgIc44kdlvcHWsNVhj6Sn7vt63MTUKwkVEi56kaNFoL/uDbWRQrYOPsDZ05xMG aTGamSfhTt186hzCt4MrUY8Xla90zQ7OA4PNw4hxafvjOrxXdwfoHWbE+RcaBWXtmWDC71M5qjnwb 7dWTnKGBcwu3eaqMCjjp9f4Td82FropyfIPs2MJyrehNI/peltylV0KaAGF1HrG2Knv/+Tj/6kG4p yQYaE0s4hUaVQ6wYaA2Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s6WkB-0000000DCf4-2QvT; Mon, 13 May 2024 14:33:35 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s6Wk8-0000000DCeE-2Ufb for linux-arm-kernel@lists.infradead.org; Mon, 13 May 2024 14:33:33 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id BC47360E09; Mon, 13 May 2024 14:33:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA02EC113CC; Mon, 13 May 2024 14:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715610811; bh=9jEc6XmA0JeD1+JytrCC6//7y4ZhOVxPGuwBwfPOHzI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fCxvi4VrBIynn0VQB9XqYDfNx+t2zPA4u3bbND2INwP6HWYu7HrKY0PLWvDw+xr59 YntfxdLievt/TUBO0qYudsP8sbyzeqYJiCPhEtCmFDq8wwIfJYBnxVNj3249vK5rW+ 3RiyN7VryYl1GIrdtj35TAbae1ix87gL/txem3DgtJBNdueAYS4k6JnoHA3yKo80zR Jle8IQ9mkPMtiLCXiDM4ayD+WY5N/GPtyauvlC88qKyjPW35lmIQP5rG1EoEDsR5FG uZz140esb4qaXe8Yj9qrCDR5Wtb82GvP6Pr3Ce54ZMR67RA5rK9ecAutnKONXQsNlC weIpDhBsXKQrQ== Date: Mon, 13 May 2024 15:33:26 +0100 From: Will Deacon To: =?iso-8859-1?Q?Pierre-Cl=E9ment?= Tosi Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Marc Zyngier , Oliver Upton , Suzuki K Poulose , Vincent Donnefort Subject: Re: [PATCH v3 06/12] KVM: arm64: nVHE: gen-hyprel: Skip R_AARCH64_ABS32 Message-ID: <20240513143326.GE28749@willie-the-truck> References: <20240510112645.3625702-1-ptosi@google.com> <20240510112645.3625702-7-ptosi@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240510112645.3625702-7-ptosi@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240513_073332_824796_773D2B44 X-CRM114-Status: GOOD ( 10.42 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, May 10, 2024 at 12:26:35PM +0100, Pierre-Cl=E9ment Tosi wrote: > Ignore R_AARCH64_ABS32 relocations, instead of panicking, when emitting > the relocation table of the hypervisor. The toolchain might produce them > when generating function calls with kCFI, to allow type ID resolution > across compilation units (between the call-site check and the callee's > prefixed u32) at link time. They are therefore not needed in the final > (runtime) relocation table. Hmm. Please can you elaborate a bit more on this? Are these absolute addresses in the kernel VA space or the hypervisor VA space? Generally, absolute addressing at EL2 is going to cause problems, so I'm not keen on waving all R_AARCH64_ABS32 relocs through. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel