From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) (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 26E8F37DEBC for ; Tue, 23 Jun 2026 13:52:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782222756; cv=none; b=Rk5ICd3Cbag6oWdcUC7jgUCLLDIIxxBTc+c0ThaSPut3/L93FX+IfLLnWqRvChL2r2VBT3rAf9oNSe622OY9ARKK22cAEJZITXLWla1kIrtQK5U946Ag5cdCjaeZV3HZ2IJa+97ptLxKY9k4beG78B3gGNozjeQoLJe6d7uXLB0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782222756; c=relaxed/simple; bh=ovLBAvklLxZwC7Jq9ETpckjB1i/iju7Qpbi9FQGDqWQ=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FvUnoidpJxVyJlSUAP+ul3gOicCdNPOMpMpw5ZUSk22qfT2mXpl0WccuyHJnlFllQ2qBbmMKkjJRHOUPrQlxQA46rwDcMe2/IcbAvkMSxgnRV1tQmzagV+foonA3OD/6IEXaMl2blJveFria/HnqNtlo3UWIsofhDOKOP4Nj3NE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=gVzTRPNu; arc=none smtp.client-ip=95.215.58.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="gVzTRPNu" X-Forwarded-Encrypted: i=1; AFNElJ+bUEJSbc15343DFYeelUVp6AAZFuiLeaqdq1ZJsNfo3wOGrDmomf9F8++mdkBKcpSgzrVIdx/pmFZH3es=@vger.kernel.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782222750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=F77g4j7YjD5E5qC6B2ZdRa5uX5Miz2j/ZR1CSt9++g4=; b=gVzTRPNu0aFxDov8CPyoT60I5VkmkLabRcx+yCJKozDsCzoDT3lImRJbXkBdBFxD6g20ec nXylqyBNKIONfXXI7vC7MofWMzEy7fiwDRtWEKlF6XDyvmes7kcv/IC+1wr5/gCB2sk5Ks OSjAFt9z9nDDmo2UmpQbH/009zw7Ufc= X-Gm-Message-State: AOJu0Yw2Jl7Syn72wNY23Jf+vFaTr9Idisw/P5m+6lu+MiiA7Czzxl+H m/kxystGaAeCR4FkafF7NoXYQlRAkgLAp5B3ZCKq3N7UC/QwPB0+RWbmTk2bPUJn1/y20KDn/7x tuhjmUvPWBf7I91LE8rFKq7Vew1bQsNT6iwP/x89i X-Received: by 2002:a05:622a:411b:b0:519:df4f:6c93 with SMTP id d75a77b69052e-51a5255375emr10017941cf.20.1782222746042; Tue, 23 Jun 2026 06:52:26 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260622190701.2039766-1-fuad.tabba@linux.dev> <20260622190701.2039766-2-fuad.tabba@linux.dev> <86tsqtqu9u.wl-maz@kernel.org> In-Reply-To: <86tsqtqu9u.wl-maz@kernel.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Fuad Tabba Date: Tue, 23 Jun 2026 14:51:49 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AVVi8CebMVsOKX8XmdbtdzDxdkE6ig5bh0MmMzjJbv-f8yL8AKg1mgeDyXjOPkk Message-ID: Subject: Re: [PATCH 1/2] KVM: arm64: Fix sign-extension of MMIO loads To: Marc Zyngier 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 Content-Type: text/plain; charset="UTF-8" X-Migadu-Flow: FLOW_OUT On Tue, 23 Jun 2026 at 14:08, Marc Zyngier wrote: > > 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? Endianess always confuses me too :D My reading of the ARM ARM is that the byte reversal is keyed on the access size there too. It lives in Mem{size}, with the register width handled separately by SignExtend(regsize): data = Mem[address, 2]; // byte-reversed by the access size, BE X[t] = SignExtend(data, regsize); So vcpu_data_host_to_guest(..., len) swapping by len matches the Mem-side reversal. Swapping by the register width would reorder bytes that were never loaded. An LDRSH into Wt reads 2 bytes but would bswap 4: the halfword reaches the helper as 0x0180 host-native, cpu_to_be32 turns it into 0x80010000 instead of the 0x8001 cpu_to_be16 gives, and it never sign-extends to 0xffff8001. If that reading holds, none of the helper's ops are individually wrong, and the only bug was the order, with the sign-extend running before the swap and the width mask then dropping it. But I've gone round in circles on endianness before (to say the least), so please say if I've done it again. Cheers, /fuad > > M. > > -- > Without deviation from the norm, progress is not possible.