On 9/7/26 17:41, Miao Wang wrote:
2026年7月9日 23:06，Peter Maydell <[email protected]> 写道：
On Thu, 9 Jul 2026 at 15:54, Miao Wang <[email protected]> wrote:
Hi,
2026年7月9日 22:41，Philippe Mathieu-Daudé <[email protected]> 写道：
On 9/7/26 08:39, Michael Tokarev wrote:
On 05.06.2026 16:27, Miao Wang via B4 Relay wrote:
From: Miao Wang <[email protected]>
This patch improves the implementation of the pvscsi device by
translating the endianness of the data sent or received from the guest.
This ensures pvscsi can work on big-endian hosts with little-endian
guests.
Hi!
Can we pick this one up for 11.1 please?
I know right to nothing about s390x internals so can't really review
the change. But the fix seems to work, and it should be picked up for
the stable qemu series too, it loks like.
I tagged this for review and forgot. Basically we shouldn't using
tswap*() anywhere in system emulation except semihosting. Here it
seems reasonable to use cpu_to_le*()/le*_to_cpu().
I have no idea why tswap* should not be used. Here the problem in
pvscsi is that the driver on the guest side is using the native
endianness of the guest CPU while for handling the values on the
host size, we need to convert it to host endianness. As a result,
what should be done is to convert from the target endianness to
the host endianness and vice versa, instead of converting from
a specific endianness to to host endianness.
Right, but what is the spec of the device supposed to be?
Generally speaking in real hardware devices don't have any
way of knowing the endianness of the CPU, they're specified
as "data is always little endian" or "data is always big endian".
Sometimes paravirtual devices end up with "assumes guest
endianness" baked into them, but this is usually a bad idea:
the legacy virtio does this, but we fixed this in 1.0 virtio,
which is always little endian.
Do you have a pointer to the specification for this device?
There's no URL in the source files.
Sadly, I do not have such specification and I strongly suspect
that neither does the designer of it, since it is designed to
be used with x86. In the source code of its driver in Linux,
it can be seen that the code is not endianness aware. However
in the Kconfig, the driver is limited to be compiled on X86.
As a result, there might be two possibilities:
- pvscsi is designed to use (guest) native endianness
- pvscsi is designed to use little endianness and since the
linux driver limits itself to be used on X86, the author
chose not to bother to ensure the correctness of the
endianness
Likely the 2nd possibility ;) Also known as "implicit endianness".
