search for: le16

...lable at \field{topo_offset}. \end{description} \drivernormative{\subsubsection}{Feature bits}{Device Types / IOMMU Device / Feature bits} @@ -97,6 +100,7 @@ \subsection{Device configuration layout}\label{sec:Device Types / IOMMU Device / le32 end; } domain_range; le32 probe_size; + le16 topo_offset; }; \end{lstlisting} @@ -141,6 +145,90 @@ \subsection{Device initialization}\label{sec:Device Types / IOMMU Device / Devic If the driver does not accept the VIRTIO_IOMMU_F_BYPASS feature, the device SHOULD NOT let endpoints access the guest-physical address space. +\subsubsectio...

On Mon, Aug 17, 2015 at 11:07:15AM +0800, Jason Wang wrote: > > > On 08/16/2015 09:42 PM, Victor Kaplansky wrote: > > @@ -3128,6 +3134,7 @@ struct virtio_net_config { > > u8 mac[6]; > > le16 status; > > le16 max_virtqueue_pairs; > > + le16 default_mtu; > > Looks like "mtu" is ok, consider we use "mac" instead of "default_mac". Good point. I'll change the name in the next version of the patch. > > > }; &gt...

On Mon, Aug 17, 2015 at 11:07:15AM +0800, Jason Wang wrote: > > > On 08/16/2015 09:42 PM, Victor Kaplansky wrote: > > @@ -3128,6 +3134,7 @@ struct virtio_net_config { > > u8 mac[6]; > > le16 status; > > le16 max_virtqueue_pairs; > > + le16 default_mtu; > > Looks like "mtu" is ok, consider we use "mac" instead of "default_mac". Good point. I'll change the name in the next version of the patch. > > > }; &gt...

...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() ... le16-to_cpu() is simply wrong: virtio needs to be LE or native endian, depending on whether it's running in 0.9 or 1...

...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() ... le16-to_cpu() is simply wrong: virtio needs to be LE or native endian, depending on whether it's running in 0.9 or 1...

...ault_mtu} as + an initial value and reports MTU changes to the device. + \end{description} \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements} @@ -3128,6 +3134,7 @@ struct virtio_net_config { u8 mac[6]; le16 status; le16 max_virtqueue_pairs; + le16 default_mtu; }; \end{lstlisting} @@ -3158,6 +3165,15 @@ by the driver after negotiation. \field{max_virtqueue_pairs} is valid only if VIRTIO_NET_F_MQ is set and can be read by the driver. +\item [\field{default_mtu}] is a hint...

...===================================================== RCS file: /sources/grub/grub/stage2/fsys_xfs.c,v retrieving revision 1.5 diff -u -p -r1.5 fsys_xfs.c --- fsys_xfs.c 8 May 2005 02:18:14 -0000 1.5 +++ fsys_xfs.c 10 Jul 2008 13:09:50 -0000 @@ -101,7 +101,7 @@ static inline __const__ xfs_uint16_t le16 (xfs_uint16_t x) { __asm__("xchgb %b0,%h0" \ - : "=q" (x) \ + : "=Q" (x) \ : "0" (x)); \ return x; } @@ -109,9 +109,9 @@ le16 (xfs_uint16_t x) static inline __const__ xfs_uint32_t le32 (xfs_uint32_t x) { -#if 0 +#if 1 /* 386 doesn'...

This set of two patches adds a new field called default_mtu to the configuration area of network devices. The motivation is to allow libvirt to set initial MTU different from 1500 on guests virtual NICs. We also propose to use this new field to report MTU changes by the guest OS to the device to facilitate debugging and mtu tunning. The first patch just clarify the definition of existing fields

This set of two patches adds a new field called default_mtu to the configuration area of network devices. The motivation is to allow libvirt to set initial MTU different from 1500 on guests virtual NICs. We also propose to use this new field to report MTU changes by the guest OS to the device to facilitate debugging and mtu tunning. The first patch just clarify the definition of existing fields

...o16 gso_size; /* Bytes to append to hdr_len per frame */ > - __virtio16 csum_start; /* Position to start checksumming from */ > - __virtio16 csum_offset; /* Offset after that to place checksum */ > + union { > + __virtio16 csum_start; /* Position to start checksumming from */ > + __le16 rsc_ext_num_packets; /* num of coalesced packets */ > + }; > + union { > + __virtio16 csum_offset; /* Offset after that to place checksum */ > + __le16 rsc_ext_num_dupacks; /* num of duplicated acks */ dupacks -> dup_acks ? Also wouldn't it be cleaner to have an rsc struct? A...

...and reports MTU changes to the device. > + > \end{description} > > \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements} > @@ -3128,6 +3134,7 @@ struct virtio_net_config { > u8 mac[6]; > le16 status; > le16 max_virtqueue_pairs; > + le16 default_mtu; Looks like "mtu" is ok, consider we use "mac" instead of "default_mac". > }; > \end{lstlisting} > > @@ -3158,6 +3165,15 @@ by the driver after negotiation. > \fiel...

On 08/19/2015 07:31 PM, Victor Kaplansky wrote: > On Mon, Aug 17, 2015 at 11:07:15AM +0800, Jason Wang wrote: >> >> On 08/16/2015 09:42 PM, Victor Kaplansky wrote: >>> @@ -3128,6 +3134,7 @@ struct virtio_net_config { >>> u8 mac[6]; >>> le16 status; >>> le16 max_virtqueue_pairs; >>> + le16 default_mtu; >> Looks like "mtu" is ok, consider we use "mac" instead of "default_mac". > Good point. I'll change the name in the next version of the patch. > >>&gt...

...et driver desc_event_off/wrap"); > + return true; > + } > + > + off = vhost16_to_cpu(vq, event_off_wrap); > + > + wrap = off & 0x1; > + off >>= 1; Based on the below definitions in spec, wrap counter is the most significant bit. struct pvirtq_event_suppress { le16 { desc_event_off : 15; /* Descriptor Ring Change Event Offset */ desc_event_wrap : 1; /* Descriptor Ring Change Event Wrap Counter */ } desc; /* If desc_event_flags set to RING_EVENT_FLAGS_DESC */ le16 { desc_event_flags : 2, /* Descriptor Ring Change Event Flags */ reserved : 14; /* Rese...

...Distinguish different requests type */ > + __le64 flag: 8; /* Mark status for a specific request type */ > + __le64 id : 16; /* Distinguish requests of a specific type */ > + __le64 data_len: 32; /* Length of the following data, in bytes */ This use of __le64 makes no sense. Just use u8/le16/le32 pls. > +}; > + > #endif /* _LINUX_VIRTIO_BALLOON_H */ > -- > 1.9.1

...Distinguish different requests type */ > + __le64 flag: 8; /* Mark status for a specific request type */ > + __le64 id : 16; /* Distinguish requests of a specific type */ > + __le64 data_len: 32; /* Length of the following data, in bytes */ This use of __le64 makes no sense. Just use u8/le16/le32 pls. > +}; > + > #endif /* _LINUX_VIRTIO_BALLOON_H */ > -- > 1.9.1

...> 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() ... > > le16-to_cpu() is simply wrong: virtio needs to be > LE or native endian, depending on whe...

...e <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 + return (__force __virtio16)val; +} + +static inline u32 __virtio32_to_cpu(b...

...e <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 + return (__force __virtio16)val; +} + +static inline u32 __virtio32_to_cpu(b...

...> + __le64 flag: 8; /* Mark status for a specific request type */ > > > + __le64 id : 16; /* Distinguish requests of a specific type */ > > > + __le64 data_len: 32; /* Length of the following data, in bytes */ > > > > This use of __le64 makes no sense. Just use u8/le16/le32 pls. > > > > Got it, will change in the next version. > > And could help take a look at other parts? as well as the QEMU part. > > Thanks! > Liang Yes but first I would like to understand how come no fields in this new structure come up if I search for them in...

...> + __le64 flag: 8; /* Mark status for a specific request type */ > > > + __le64 id : 16; /* Distinguish requests of a specific type */ > > > + __le64 data_len: 32; /* Length of the following data, in bytes */ > > > > This use of __le64 makes no sense. Just use u8/le16/le32 pls. > > > > Got it, will change in the next version. > > And could help take a look at other parts? as well as the QEMU part. > > Thanks! > Liang Yes but first I would like to understand how come no fields in this new structure come up if I search for them in...