From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4066C242D89; Tue, 23 Jun 2026 13:08:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782220097; cv=none; b=tWWAOPYf5bRbh9iBtll9v8cSeHsOxHnsh+DoBc3LcTe90f/gQYU6ajyJaAuLeh1vKOM9nAG8p0MH26U7fa6e+BvKOo/obM40phMVsy/WmxR6eYqGdG4W1Y5Ao2TEr+KryeCelLhTnOFMNJKhRr073prFe85Ko1z5kSPL8t2S3e0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782220097; c=relaxed/simple; bh=7vw+9J+DTNSwvtLViC9SiWeB7maDPlQ+Zi/TYykzFzQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=d+vI9rGSGsWU0AvZs3d12IaFq5qrz1I2JPY9CQHf75JJWBPOJqJijg5RrQdMgADAhEph43+MVI781cmdMDcUZcBQnf2pGsvFHtpv/OaUt1vkAPE0FjRrIxG5XeGhe+qRrAmJbxQLkKg/13QFFEJIJyr1IrDlLr+de+SGIA2iamc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IKdtfNpt; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IKdtfNpt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 012441F000E9; Tue, 23 Jun 2026 13:08:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782220096; bh=Z8sTU+8G5Nx/47JjD+XoYdzr54hu2EhVfKCrwOv3fY8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=IKdtfNpthkRsIZNECjJYBclOhDXwhnotLrdCTAhR5DMuhpxIayAjQ4CNj+rqwVf3r Z5zDiQ5W5UbbmG/IZSTC+Tlg6KTxRtzouWnSGnDxnXWNkBFlqleoqWymQrnLw+gZ+z hIeBv821mJ9qswsDBUI+SgHxT4AcjK5FbmCk59zU6IKIfuALcJI9EPeJeHdagJDy/i U1Up6/JsISCwWIb+jPyBJuTHsXxzRFvMjPunOOW5sx50K6TCL1Drw/pSy3xxPon0Nv higzH/g5EIioQim1dIuaIRm5+prm3NeNnxbepWxBJIoNYut+07nO/i4qTHIwFV+MfA HdJPvqBLCNJHg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wc0rN-0000000FIFR-1tPY; Tue, 23 Jun 2026 13:08:13 +0000 Date: Tue, 23 Jun 2026 14:08:13 +0100 Message-ID: <86tsqtqu9u.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Steffen Eiden , Catalin Marinas , Will Deacon , Shuah Khan , Christoffer Dall , Victor Kamensky , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] KVM: arm64: Fix sign-extension of MMIO loads In-Reply-To: <20260622190701.2039766-2-fuad.tabba@linux.dev> References: <20260622190701.2039766-1-fuad.tabba@linux.dev> <20260622190701.2039766-2-fuad.tabba@linux.dev> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: fuad.tabba@linux.dev, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, seiden@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, shuah@kernel.org, christoffer.dall@linaro.org, victor.kamensky@linaro.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 22 Jun 2026 20:07:00 +0100, Fuad Tabba wrote: > > A sign-extending load from MMIO (LDRSB, LDRSH, LDRSW) delivers a > zero-extended value: in kvm_handle_mmio_return(), vcpu_data_host_to_guest() > masks the data to the access width after sign-extension, stripping the > sign bits. > > Move vcpu_data_host_to_guest() ahead of sign-extension so the width mask > runs first. trace_kvm_mmio() moves with it and keeps reporting the raw > access-width data. > > Fixes: b30070862edbd ("ARM64: KVM: MMIO support BE host running LE code") > Signed-off-by: Fuad Tabba > --- > arch/arm64/kvm/mmio.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c > index e2285ed8c91de..d1c3a352d5a22 100644 > --- a/arch/arm64/kvm/mmio.c > +++ b/arch/arm64/kvm/mmio.c > @@ -126,6 +126,10 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu) > len = kvm_vcpu_dabt_get_as(vcpu); > data = kvm_mmio_read_buf(run->mmio.data, len); > > + trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr, > + &data); > + data = vcpu_data_host_to_guest(vcpu, data, len); This helper is in charge of the endianness of the read from the guest's PoV. How can the sign-extension (which happens from the host's perspective) correctly work if it takes place after the byte swapping? To me, the real issue appears to be in the that helper, which swaps the data based on the size of the access instead of the width of the register. Or am I once more completely confused with the endianness crap? M. -- Without deviation from the norm, progress is not possible.