> 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
Cheers,
Miao Wang
