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 9420CC433F5 for ; Fri, 8 Apr 2022 07:48:18 +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: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=oGf7HbCTXFWvb0JdcPr6zIiR1tlzk/+BBkKjOQeVKOs=; b=DfFjlvJHwmSFmF GdkkxUMQso+7MpGLDXV/B6iOg9qBA9Fkf/tgEfNdnE1r9UY14IBiNPm9MgK37KsgtStnbe8x1yq9+ 59chzXGqyt+ZLELDZsYZgt6XEcJFW+g4CzXjX76OtI1u3J1uHqua3cDY4D23/eLFkZT/D95bbQFyu FGGbxrULG2Iw+9u3t3Z5Zb+h9KJkMOhR72BJac/sCwVn7UPeCIGUgd7h/RNwvuFaLfKjE2P9sTM65 JLOZiAm8FicPUOnulPllmeVf6xqNrZ22YzQlXg0wI3e6EOm74kh1zANbEcsntlDx0Xwik4PSDFL1W 0uff3jAPJhR9yOkfh6bw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncjKm-00Fbws-Lt; Fri, 08 Apr 2022 07:47:08 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncjKj-00Fbvb-0y for linux-arm-kernel@lists.infradead.org; Fri, 08 Apr 2022 07:47:06 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3A8CB62047; Fri, 8 Apr 2022 07:47:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A072DC385A1; Fri, 8 Apr 2022 07:47:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649404023; bh=4GhxIosvCGUubREkWd+vFgEQ79K5rcF2ZocmgP72yVA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SwWyJ1SzgbRYeV5Y60Gqtv+CIu8tteYZ5HyBEm8+Ywx+hr+HhsFsmKfxvIP4pNSWa uBL6HxTawysPGwGsrQQ/io1R7W01dy5px2sREoIdzlq8wtNCet5LBzSLKtchXwGzQH VpCd+c00DEz7xZ7mCkvW8u4hTXqd6RZdqjcJbj8+pxBlO2TltNJZ7paBgfb3oNRJvF uhz+EWSGKIHbq+nlTdt9/iS2bHFLzs0QZYvlurkwQ5135oSaqpgUif4ap4w3Dildju t53u8KqOTy87pzoqK9MR7hyEzoa1sia4xef8rC1IckbBvrzmOnLlAEmDio8d3McV5v YaIHrSs1M4Xsw== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.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 1ncjKf-002hMH-5z; Fri, 08 Apr 2022 08:47:01 +0100 Date: Fri, 08 Apr 2022 08:47:00 +0100 Message-ID: <87ee28auff.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, mark.rutland@arm.com Subject: Re: [PATCH 5/5] KVM: arm64: uapi: Add kvm_debug_exit_arch.hsr_high In-Reply-To: <20220407162327.396183-6-alexandru.elisei@arm.com> References: <20220407162327.396183-1-alexandru.elisei@arm.com> <20220407162327.396183-6-alexandru.elisei@arm.com> 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.219.108.64 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, mark.rutland@arm.com 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-20220408_004705_227069_3015495C X-CRM114-Status: GOOD ( 23.71 ) 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 Hi Alex, On Thu, 07 Apr 2022 17:23:27 +0100, Alexandru Elisei wrote: > > When userspace is debugging a VM, the kvm_debug_exit_arch part of the > kvm_run struct contains arm64 specific debug information: the ESR_EL2 > value, encoded in the field "hsr", and the address of the instruction > that caused the exception, encoded in the field "far". > > Linux has moved to treating ESR_EL2 as a 64-bit register, but unfortunately > kvm_debug_exit_arch.hsr cannot be changed to match because that would > change the memory layout of the struct on big endian machines: > > Current layout: | Layout with "hsr" extended to 64 bits: > | > offset 0: ESR_EL2[31:0] (hsr) | offset 0: ESR_EL2[61:32] (hsr[61:32]) > offset 4: padding | offset 4: ESR_EL2[31:0] (hsr[31:0]) > offset 8: FAR_EL2[61:0] (far) | offset 8: FAR_EL2[61:0] (far) > > which breaks existing code. > > The padding is inserted by the compiler because the "far" field must be > aligned to 8 bytes (each field must be naturally aligned - aapcs64 [1], > page 18) and the struct itself must be aligned to 8 bytes (the struct must > be aligned to the maximum alignment of its fields - aapcs64, page 18), > which means that "hsr" must be aligned to 8 bytes as it is the first field > in the struct. > > To avoid changing the struct size and layout for the existing fields, add a > new field, "hsr_high", which replaces the existing padding. "hsr_high" will > be used to hold the ESR_EL2[61:32] bits of the register. The memory layout, > both on big and little endian machine, becomes: > > Layout with "hsr_high" added: > > offset 0: ESR_EL2[31:0] (hsr) > offset 4: ESR_EL2[61:32] (hsr_high) > offset 8: FAR_EL2[61:0] (far) My concern with this change is that it isn't clear what the padding is currently initialised to, and I don't think there is any guarantee that it is zeroed. With that, a new userspace on an old kernel would interpret hsr_high, and potentially observe stuff that wasn't supposed to be interpreted. That's yet another mistake in our userspace ABI (where is the time machine when you need it?). In order to do this, we must advertise to userspace that we provide more information. This probably means adding a flag of some sort to kvm_run (there are at least 128 bits of x86 stuff that can be readily reclaimed). What do you think? 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