search for: cpu_to_virtio

...t;>> > >>>> It supports legacy PCI device using single order-2 page buffer. > >>> > >>> Do you mean a legacy virtio device? I don't see why > >>> you would want to support pre-1.0 mode. > >>> If you drop that, you can drop all cpu_to_virtio things > >>> and just use __le accessors. > >> > >> I was thinking about the kvmtools which lacks 1.0 support AFAIK. > > > > Unless kvmtools wants to be left behind it has to go 1.0. > > And it also has to go ACPI. Is there any reason, apart from k...

...t;>> > >>>> It supports legacy PCI device using single order-2 page buffer. > >>> > >>> Do you mean a legacy virtio device? I don't see why > >>> you would want to support pre-1.0 mode. > >>> If you drop that, you can drop all cpu_to_virtio things > >>> and just use __le accessors. > >> > >> I was thinking about the kvmtools which lacks 1.0 support AFAIK. > > > > Unless kvmtools wants to be left behind it has to go 1.0. > > And it also has to go ACPI. Is there any reason, apart from k...

...current > > drivers, right? > > > > So why not just keep virtio-balloon as-is and just specify endianness > etc. for 1.0? Keeps the old drivers going without hacks, > and we can > start with a fresh driver for the new virtio-balloon. Well it doesn't really, we need cpu_to_virtio in a bunch of places anyway. So I kind of prefer making it clean, even just to avoid setting a bad example for other devices. Let me post the new patch where it's all fixed in a cleaner way, and everyone can discuss whether it's too much work. -- MST

...current > > drivers, right? > > > > So why not just keep virtio-balloon as-is and just specify endianness > etc. for 1.0? Keeps the old drivers going without hacks, > and we can > start with a fresh driver for the new virtio-balloon. Well it doesn't really, we need cpu_to_virtio in a bunch of places anyway. So I kind of prefer making it clean, even just to avoid setting a bad example for other devices. Let me post the new patch where it's all fixed in a cleaner way, and everyone can discuss whether it's too much work. -- MST

...atures_legacy. Wrt packing code more tightly, I did it like this to make it easier to compare the arrays. Each flag is on the same line in original and new array. > I was asking myself if we could do the conversion of the statical values > somehow upfront, to reduce the patch size and avoid cpu_to_virtio.* at those > places. > > Otherwise looks good to me. >

...atures_legacy. Wrt packing code more tightly, I did it like this to make it easier to compare the arrays. Each flag is on the same line in original and new array. > I was asking myself if we could do the conversion of the statical values > somehow upfront, to reduce the patch size and avoid cpu_to_virtio.* at those > places. > > Otherwise looks good to me. >

...block/virtio_blk.c @@ -80,7 +80,7 @@ static int __virtblk_add_req(struct virtqueue *vq, { struct scatterlist hdr, status, cmd, sense, inhdr, *sgs[6]; unsigned int num_out = 0, num_in = 0; - int type = vbr->out_hdr.type & ~VIRTIO_BLK_T_OUT; + __virtio32 type = vbr->out_hdr.type & ~cpu_to_virtio32(vq->vdev, VIRTIO_BLK_T_OUT); sg_init_one(&hdr, &vbr->out_hdr, sizeof(vbr->out_hdr)); sgs[num_out++] = &hdr; @@ -91,19 +91,19 @@ static int __virtblk_add_req(struct virtqueue *vq, * block, and before the normal inhdr we put the sense data and the * inhdr with addit...

...block/virtio_blk.c @@ -80,7 +80,7 @@ static int __virtblk_add_req(struct virtqueue *vq, { struct scatterlist hdr, status, cmd, sense, inhdr, *sgs[6]; unsigned int num_out = 0, num_in = 0; - int type = vbr->out_hdr.type & ~VIRTIO_BLK_T_OUT; + __virtio32 type = vbr->out_hdr.type & ~cpu_to_virtio32(vq->vdev, VIRTIO_BLK_T_OUT); sg_init_one(&hdr, &vbr->out_hdr, sizeof(vbr->out_hdr)); sgs[num_out++] = &hdr; @@ -91,19 +91,19 @@ static int __virtblk_add_req(struct virtqueue *vq, * block, and before the normal inhdr we put the sense data and the * inhdr with addit...

...----------- 1 file changed, 77 insertions(+), 86 deletions(-) diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h index 5c3b02245ecd..7fa000f02721 100644 --- a/include/linux/virtio_config.h +++ b/include/linux/virtio_config.h @@ -288,112 +288,103 @@ static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val) return __cpu_to_virtio64(virtio_is_little_endian(vdev), val); } -/* - * Only the checker differentiates between __virtioXX and __uXX types. But we - * try to share as much code as we can with the regular GCC build. - */ -#if !defined(CONFIG_CC_IS_GCC) &am...

...s warnings if I use virtio_cread() > for virtio-crypto device. I suspect that's because you are doing cread into an le32 variable. > Furthermore, it means the warnings exist for all VIRTIO_1 devices because > they are definitely LE, which it's not necessary to use virtio_to_cpu/cpu_to_virtio. > > > PS: I googled a discussion about this topic for virtio-input device, pls see: > http://linux.kernel.narkive.com/3argfbWz/patch-1-1-add-virtio-input-driver > > Regards, > -Gonglei Looks like we changed the macros since - at least ATM virtio_console_config uses __u16...

...s warnings if I use virtio_cread() > for virtio-crypto device. I suspect that's because you are doing cread into an le32 variable. > Furthermore, it means the warnings exist for all VIRTIO_1 devices because > they are definitely LE, which it's not necessary to use virtio_to_cpu/cpu_to_virtio. > > > PS: I googled a discussion about this topic for virtio-input device, pls see: > http://linux.kernel.narkive.com/3argfbWz/patch-1-1-add-virtio-input-driver > > Regards, > -Gonglei Looks like we changed the macros since - at least ATM virtio_console_config uses __u16...

...ity(struct virtqueue *vq, int cpu) return 0; } +/* Memory accessors */ +#define DEFINE_VIRTIO_XX_TO_CPU(bits) \ +static inline u##bits virtio##bits##_to_cpu(struct virtio_device *vdev, __virtio##bits val) \ +{ \ + return __virtio##bits##_to_cpu(false, val); \ +} \ +static inline __virtio##bits cpu_to_virtio##bits(struct virtio_device *vdev, u##bits val) \ +{ \ + return __cpu_to_virtio##bits(false, val); \ +} + +DEFINE_VIRTIO_XX_TO_CPU(16) +DEFINE_VIRTIO_XX_TO_CPU(32) +DEFINE_VIRTIO_XX_TO_CPU(64) + /* Config space accessors. */ #define virtio_cread(vdev, structname, member, ptr) \ do { \ d...

...ity(struct virtqueue *vq, int cpu) return 0; } +/* Memory accessors */ +#define DEFINE_VIRTIO_XX_TO_CPU(bits) \ +static inline u##bits virtio##bits##_to_cpu(struct virtio_device *vdev, __virtio##bits val) \ +{ \ + return __virtio##bits##_to_cpu(false, val); \ +} \ +static inline __virtio##bits cpu_to_virtio##bits(struct virtio_device *vdev, u##bits val) \ +{ \ + return __cpu_to_virtio##bits(false, val); \ +} + +DEFINE_VIRTIO_XX_TO_CPU(16) +DEFINE_VIRTIO_XX_TO_CPU(32) +DEFINE_VIRTIO_XX_TO_CPU(64) + /* Config space accessors. */ #define virtio_cread(vdev, structname, member, ptr) \ do { \ d...

On Tue, Nov 22, 2016 at 04:10:22PM +0800, Gonglei wrote: > Virtio modern devices are always little edian, let's introduce > the LE functions for read/write configuration space for > virtio modern devices, which avoid complaint by Sparse when > we use the virtio_creaed/virtio_cwrite in VIRTIO_1 devices. > > Signed-off-by: Gonglei <arei.gonglei at huawei.com> > ---

On Tue, Nov 22, 2016 at 04:10:22PM +0800, Gonglei wrote: > Virtio modern devices are always little edian, let's introduce > the LE functions for read/write configuration space for > virtio modern devices, which avoid complaint by Sparse when > we use the virtio_creaed/virtio_cwrite in VIRTIO_1 devices. > > Signed-off-by: Gonglei <arei.gonglei at huawei.com> > ---

...mation (like ftrace dump) later. > > > > > > It supports legacy PCI device using single order-2 page buffer. > > > > Do you mean a legacy virtio device? I don't see why > > you would want to support pre-1.0 mode. > > If you drop that, you can drop all cpu_to_virtio things > > and just use __le accessors. > > I was thinking about the kvmtools which lacks 1.0 support AFAIK. Unless kvmtools wants to be left behind it has to go 1.0. > But > I think it'd be better to always use __le type anyway. Will change. > > > > > &...

...mation (like ftrace dump) later. > > > > > > It supports legacy PCI device using single order-2 page buffer. > > > > Do you mean a legacy virtio device? I don't see why > > you would want to support pre-1.0 mode. > > If you drop that, you can drop all cpu_to_virtio things > > and just use __le accessors. > > I was thinking about the kvmtools which lacks 1.0 support AFAIK. Unless kvmtools wants to be left behind it has to go 1.0. > But > I think it'd be better to always use __le type anyway. Will change. > > > > > &...

...gt; > > > > > So why not just keep virtio-balloon as-is and just specify endianness > > etc. for 1.0? Keeps the old drivers going without hacks, > > and we can > > start with a fresh driver for the new virtio-balloon. > > Well it doesn't really, we need cpu_to_virtio in a bunch of > places anyway. Of course, but what about keeping changes minimal? > > So I kind of prefer making it clean, even just to avoid setting a bad > example for other devices. > > Let me post the new patch where it's all fixed in a cleaner way, and > everyone c...

...>>>>> It supports legacy PCI device using single order-2 page buffer. >>>>> >>>>> Do you mean a legacy virtio device? I don't see why >>>>> you would want to support pre-1.0 mode. >>>>> If you drop that, you can drop all cpu_to_virtio things >>>>> and just use __le accessors. >>>> >>>> I was thinking about the kvmtools which lacks 1.0 support AFAIK. >>> >>> Unless kvmtools wants to be left behind it has to go 1.0. >> >> And it also has to go ACPI. Is there any...

...--------------- 1 file changed, 2 insertions(+), 26 deletions(-) diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h index cc7a2b1fd7b2..ecb166c824bb 100644 --- a/include/linux/virtio_config.h +++ b/include/linux/virtio_config.h @@ -293,19 +293,7 @@ static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val) __u8: (x), \ __virtio16: virtio16_to_cpu((vdev), (x)), \ __virtio32: virtio32_to_cpu((vdev), (x)), \ - __virtio64: virtio64_to_cpu((vdev), (x)), \ - /* - * Why define a default? checker can distinguish between - * e.g. __u16, __le16 and __virtio...