On Mon, Oct 14, 2013 at 8:52 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> Il 14/10/2013 17:12, Marc Zyngier ha scritto:
>> On 14/10/13 15:56, Paolo Bonzini wrote:
>>> Il 14/10/2013 16:52, Marc Zyngier ha scritto:
>>>>>> Sure. And I imagine this traps back into the kernel to read some
>>>>>> register and find out what the endianness of the accessing CPU is?
>>>>>
>>>>> Not yet. To be exact, it does the below today. But all virtio device
>>>>> emulation is 100% guest endianness unaware. This helper is the only
>>>>> piece of code where it gets any idea what endianness the guest has. So
>>>>> by checking for references to it in the code you know where endianness
>>>>> is an issue. And that's only in the config space.
>>>>
>>>> Only config space? How do you deal with virtio ring descriptors, for
>>>> example?
>>>
>>> They also use guest endianness, but do not use virtio_is_big_endian()
>>> (yet?) so Alex missed them.
>>
>> Yeah, I thought as much. There is a whole bunch of things that need byte
>> swapping, both at the virtio level itself, and at the device level as well.
>>
>> Grep-ing for __u{16,32,64} through include/uapi/linux/virtio* shows the
>> extent of the disaster.
>
> Devices are fine in QEMU, it's only the "generic" parts (rings) that are
> missing AFAICT.
We need to take care of endianness of "device" specific descriptors in
a VirtIO device.
For example:
In VirtIO Net device, the guest sends "struct virtio_net_hdr" for each Tx
packet which describes the Tx offloads needed for packet and other info.
>
> Paolo
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@xxxxxxxxxxxxxxxxxxxxx
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
--
Anup
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
