search for: to_cpu

...nd act accordingly. > > > diff --git a/include/linux/virtio_byteorder.h b/include/linux/virtio_byteorder.h > > new file mode 100644 > > index 0000000..824ed0b > > --- /dev/null > > +++ b/include/linux/virtio_byteorder.h > > > +static inline u16 __virtio16_to_cpu(bool little_endian, __virtio16 val) > > +{ > > + if (little_endian) > > + return le16_to_cpu((__force __le16)val); > > + else > > + return (__force u16)val; > > +} > > What's wrong with just using le16-to_cpu() ....

...nd act accordingly. > > > diff --git a/include/linux/virtio_byteorder.h b/include/linux/virtio_byteorder.h > > new file mode 100644 > > index 0000000..824ed0b > > --- /dev/null > > +++ b/include/linux/virtio_byteorder.h > > > +static inline u16 __virtio16_to_cpu(bool little_endian, __virtio16 val) > > +{ > > + if (little_endian) > > + return le16_to_cpu((__force __le16)val); > > + else > > + return (__force u16)val; > > +} > > What's wrong with just using le16-to_cpu() ....

Hi Konrad, The following patch causes fairly large packet loss when transmitting from dom0 to the physical network, at least with my tg3 hardware, but I assume it can impact anything which uses this interface. I suspect that the issue is that the compound pages allocated in this way are not backed by contiguous mfns and so things fall apart when the driver tries to do DMA. However I

...gt;> > diff --git a/include/linux/virtio_byteorder.h b/include/linux/virtio_byteorder.h >> > new file mode 100644 >> > index 0000000..824ed0b >> > --- /dev/null >> > +++ b/include/linux/virtio_byteorder.h >> >> > +static inline u16 __virtio16_to_cpu(bool little_endian, __virtio16 val) >> > +{ >> > + if (little_endian) >> > + return le16_to_cpu((__force __le16)val); >> > + else >> > + return (__force u16)val; >> > +} >> >> What's wrong...

...#ifndef _LINUX_VIRTIO_BYTEORDER_H +#define _LINUX_VIRTIO_BYTEORDER_H +#include <linux/types.h> +#include <uapi/linux/virtio_types.h> + +/* + * Memory accessors for handling virtio in modern little endian and in + * compatibility native endian format. + */ + +static inline u16 __virtio16_to_cpu(bool little_endian, __virtio16 val) +{ + if (little_endian) + return le16_to_cpu((__force __le16)val); + else + return (__force u16)val; +} + +static inline __virtio16 __cpu_to_virtio16(bool little_endian, u16 val) +{ + if (little_endian) + return (__force __virtio16)cpu_to_le16(val); + else +...

...#ifndef _LINUX_VIRTIO_BYTEORDER_H +#define _LINUX_VIRTIO_BYTEORDER_H +#include <linux/types.h> +#include <uapi/linux/virtio_types.h> + +/* + * Memory accessors for handling virtio in modern little endian and in + * compatibility native endian format. + */ + +static inline u16 __virtio16_to_cpu(bool little_endian, __virtio16 val) +{ + if (little_endian) + return le16_to_cpu((__force __le16)val); + else + return (__force u16)val; +} + +static inline __virtio16 __cpu_to_virtio16(bool little_endian, u16 val) +{ + if (little_endian) + return (__force __virtio16)cpu_to_le16(val); + else +...

...ers that > query device endian-ness and act accordingly. > diff --git a/include/linux/virtio_byteorder.h b/include/linux/virtio_byteorder.h > new file mode 100644 > index 0000000..824ed0b > --- /dev/null > +++ b/include/linux/virtio_byteorder.h > +static inline u16 __virtio16_to_cpu(bool little_endian, __virtio16 val) > +{ > + if (little_endian) > + return le16_to_cpu((__force __le16)val); > + else > + return (__force u16)val; > +} What's wrong with just using le16-to_cpu() ... > --- a/include/uapi/linux/virtio...