search for: memory_region_wrong_endian

Displaying 6 results from an estimated 6 matches for "memory_region_wrong_endian".

2015 Mar 11
4
[PATCH] virtio-pci: fix host notifiers on bi-endian architectures
...x.vnet.ibm.com> > > I am confused. > The value that notifications use is always LE. True but adjust_endianness() does swap unconditionally for ppc64 because of TARGET_WORDS_BIGENDIAN. > Can't we avoid multiple swaps? That would mean adding an extra endianness argument down to memory_region_wrong_endianness()... not sure we want to do that. > They make my head spin. > I understand that the current fixed target endianness paradigm is best suited for most architectures. Extra swaps in specific non-critical locations allows to support odd beasts like ppc64le and arm64be without trashing more...
2015 Mar 11
4
[PATCH] virtio-pci: fix host notifiers on bi-endian architectures
...x.vnet.ibm.com> > > I am confused. > The value that notifications use is always LE. True but adjust_endianness() does swap unconditionally for ppc64 because of TARGET_WORDS_BIGENDIAN. > Can't we avoid multiple swaps? That would mean adding an extra endianness argument down to memory_region_wrong_endianness()... not sure we want to do that. > They make my head spin. > I understand that the current fixed target endianness paradigm is best suited for most architectures. Extra swaps in specific non-critical locations allows to support odd beasts like ppc64le and arm64be without trashing more...
2015 Mar 12
0
[PATCH] virtio-pci: fix host notifiers on bi-endian architectures
...> > The value that notifications use is always LE. > > True but adjust_endianness() does swap unconditionally for ppc64 > because of TARGET_WORDS_BIGENDIAN. > > > Can't we avoid multiple swaps? > > That would mean adding an extra endianness argument down to > memory_region_wrong_endianness()... not sure we want to do that. > > > They make my head spin. > > > > I understand that the current fixed target endianness paradigm > is best suited for most architectures. Extra swaps in specific > non-critical locations allows to support odd beasts like ppc64l...
2015 Mar 12
0
[PATCH] virtio-pci: fix host notifiers on bi-endian architectures
...> > The value that notifications use is always LE. > > True but adjust_endianness() does swap unconditionally for ppc64 > because of TARGET_WORDS_BIGENDIAN. > > > Can't we avoid multiple swaps? > > That would mean adding an extra endianness argument down to > memory_region_wrong_endianness()... not sure we want to do that. > > > They make my head spin. > > > > I understand that the current fixed target endianness paradigm > is best suited for most architectures. Extra swaps in specific > non-critical locations allows to support odd beasts like ppc64l...
2015 Mar 11
2
[PATCH] virtio-pci: fix host notifiers on bi-endian architectures
vhost is seriously broken with ppc64le guests, even in the supposedly supported case where the host is ppc64le and we don't need cross-endian support. The TX virtqueue fails to be handled by vhost and falls back to QEMU. Despite this unexpected scenario where RX is vhost and TX is QEMU, the guest runs well with reduced upload performances... until you reboot, migrate, managed save or in fact
2015 Mar 11
2
[PATCH] virtio-pci: fix host notifiers on bi-endian architectures
vhost is seriously broken with ppc64le guests, even in the supposedly supported case where the host is ppc64le and we don't need cross-endian support. The TX virtqueue fails to be handled by vhost and falls back to QEMU. Despite this unexpected scenario where RX is vhost and TX is QEMU, the guest runs well with reduced upload performances... until you reboot, migrate, managed save or in fact