diff options
| author | Marc Hartmayer | 2020-09-01 17:00:19 +0200 |
|---|---|---|
| committer | Stefan Hajnoczi | 2020-09-23 14:41:58 +0200 |
| commit | 2ffc54708087c6e524297957be2fc5d543abb767 (patch) | |
| tree | a659f96fd782d1db7f09d832072fc1d3ba149254 /include | |
| parent | MAINTAINERS: add Stefan Hajnoczi as block/nvme.c maintainer (diff) | |
| download | qemu-2ffc54708087c6e524297957be2fc5d543abb767.tar.gz qemu-2ffc54708087c6e524297957be2fc5d543abb767.tar.xz qemu-2ffc54708087c6e524297957be2fc5d543abb767.zip | |
libvhost-user: handle endianness as mandated by the spec
Since virtio existed even before it got standardized, the virtio
standard defines the following types of virtio devices:
+ legacy device (pre-virtio 1.0)
+ non-legacy or VIRTIO 1.0 device
+ transitional device (which can act both as legacy and non-legacy)
Virtio 1.0 defines the fields of the virtqueues as little endian,
while legacy uses guest's native endian [1]. Currently libvhost-user
does not handle virtio endianness at all, i.e. it works only if the
native endianness matches with whatever is actually needed. That means
things break spectacularly on big-endian targets. Let us handle virtio
endianness for non-legacy as required by the virtio specification [1]
and fence legacy virtio, as there is no safe way to figure out the
needed endianness conversions for all cases. The fencing of legacy
virtio devices is done in `vu_set_features_exec`.
[1] https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-210003
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Message-id: 20200901150019.29229-3-mhartmay@linux.ibm.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions