search for: vhost_msg_v2

Displaying 16 results from an estimated 16 matches for "vhost_msg_v2".

2018 Aug 03
4
[PATCH net-next] vhost: switch to use new message format
...of 32bit in 64bit machine because of the alignment. This leads a different formats between 32bit API and 64bit API. What's more it will break 32bit program running on 64bit machine. So fixing this by introducing a new message type with an explicit 32bit reserved field after type like: struct vhost_msg_v2 { int type; __u32 reserved; union { struct vhost_iotlb_msg iotlb; __u8 padding[64]; }; }; We will have a consistent ABI after switching to use this. To enable this capability, introduce a new ioctl (VHOST_SET_BAKCEND_FEATURE) for userspace to enable this feature (VHOST_BACKEND_F_IOTLB_V2)....
2018 Aug 03
4
[PATCH net-next] vhost: switch to use new message format
...of 32bit in 64bit machine because of the alignment. This leads a different formats between 32bit API and 64bit API. What's more it will break 32bit program running on 64bit machine. So fixing this by introducing a new message type with an explicit 32bit reserved field after type like: struct vhost_msg_v2 { int type; __u32 reserved; union { struct vhost_iotlb_msg iotlb; __u8 padding[64]; }; }; We will have a consistent ABI after switching to use this. To enable this capability, introduce a new ioctl (VHOST_SET_BAKCEND_FEATURE) for userspace to enable this feature (VHOST_BACKEND_F_IOTLB_V2)....
2018 Aug 06
1
[PATCH net-next V2] vhost: switch to use new message format
...of 32bit in 64bit machine because of the alignment. This leads a different formats between 32bit API and 64bit API. What's more it will break 32bit program running on 64bit machine. So fixing this by introducing a new message type with an explicit 32bit reserved field after type like: struct vhost_msg_v2 { __u32 type; __u32 reserved; union { struct vhost_iotlb_msg iotlb; __u8 padding[64]; }; }; We will have a consistent ABI after switching to use this. To enable this capability, introduce a new ioctl (VHOST_SET_BAKCEND_FEATURE) for userspace to enable this feature (VHOST_BACKEND_F_IOTLB_V2...
2018 Aug 03
0
[PATCH net-next] vhost: switch to use new message format
...of the alignment. This leads a different formats between 32bit API and > 64bit API. What's more it will break 32bit program running on 64bit > machine. > > So fixing this by introducing a new message type with an explicit > 32bit reserved field after type like: > > struct vhost_msg_v2 { > int type; > __u32 reserved; > union { > struct vhost_iotlb_msg iotlb; > __u8 padding[64]; > }; > }; > > We will have a consistent ABI after switching to use this. To enable > this capability, introduce a new ioctl (VHOST_SET_BAKCEND_FEATURE) for > users...
2020 Feb 05
2
[PATCH] vhost: introduce vDPA based backend
...ATE???????? 2 #define VHOST_IOTLB_INVALIDATE???? 3 #define VHOST_IOTLB_ACCESS_FAIL??? 4 ??? __u8 type; }; #define VHOST_IOTLB_MSG 0x1 #define VHOST_IOTLB_MSG_V2 0x2 struct vhost_msg { ??? int type; ??? union { ??? ??? struct vhost_iotlb_msg iotlb; ??? ??? __u8 padding[64]; ??? }; }; struct vhost_msg_v2 { ??? __u32 type; ??? __u32 reserved; ??? union { ??? ??? struct vhost_iotlb_msg iotlb; ??? ??? __u8 padding[64]; ??? }; };
2020 Feb 05
2
[PATCH] vhost: introduce vDPA based backend
...ATE???????? 2 #define VHOST_IOTLB_INVALIDATE???? 3 #define VHOST_IOTLB_ACCESS_FAIL??? 4 ??? __u8 type; }; #define VHOST_IOTLB_MSG 0x1 #define VHOST_IOTLB_MSG_V2 0x2 struct vhost_msg { ??? int type; ??? union { ??? ??? struct vhost_iotlb_msg iotlb; ??? ??? __u8 padding[64]; ??? }; }; struct vhost_msg_v2 { ??? __u32 type; ??? __u32 reserved; ??? union { ??? ??? struct vhost_iotlb_msg iotlb; ??? ??? __u8 padding[64]; ??? }; };
2020 Feb 05
2
[PATCH] vhost: introduce vDPA based backend
...; >> #define VHOST_IOTLB_MSG 0x1 >> #define VHOST_IOTLB_MSG_V2 0x2 >> >> struct vhost_msg { >> ??? int type; >> ??? union { >> ??? ??? struct vhost_iotlb_msg iotlb; >> ??? ??? __u8 padding[64]; >> ??? }; >> }; >> >> struct vhost_msg_v2 { >> ??? __u32 type; >> ??? __u32 reserved; >> ??? union { >> ??? ??? struct vhost_iotlb_msg iotlb; >> ??? ??? __u8 padding[64]; >> ??? }; >> }; > Oh ok. So with a real device, I suspect we do not want to wait for each > change to be processed...
2020 Feb 05
2
[PATCH] vhost: introduce vDPA based backend
...; >> #define VHOST_IOTLB_MSG 0x1 >> #define VHOST_IOTLB_MSG_V2 0x2 >> >> struct vhost_msg { >> ??? int type; >> ??? union { >> ??? ??? struct vhost_iotlb_msg iotlb; >> ??? ??? __u8 padding[64]; >> ??? }; >> }; >> >> struct vhost_msg_v2 { >> ??? __u32 type; >> ??? __u32 reserved; >> ??? union { >> ??? ??? struct vhost_iotlb_msg iotlb; >> ??? ??? __u8 padding[64]; >> ??? }; >> }; > Oh ok. So with a real device, I suspect we do not want to wait for each > change to be processed...
2020 Feb 05
1
[PATCH] vhost: introduce vDPA based backend
...t;>> >>>> struct vhost_msg { >>>> ??? int type; >>>> ??? union { >>>> ??? ??? struct vhost_iotlb_msg iotlb; >>>> ??? ??? __u8 padding[64]; >>>> ??? }; >>>> }; >>>> >>>> struct vhost_msg_v2 { >>>> ??? __u32 type; >>>> ??? __u32 reserved; >>>> ??? union { >>>> ??? ??? struct vhost_iotlb_msg iotlb; >>>> ??? ??? __u8 padding[64]; >>>> ??? }; >>>> }; >>> Oh ok. So with a real device,...
2018 Aug 04
0
[PATCH net-next] vhost: switch to use new message format
From: Jason Wang <jasowang at redhat.com> Date: Fri, 3 Aug 2018 15:04:51 +0800 > So fixing this by introducing a new message type with an explicit > 32bit reserved field after type like: > > struct vhost_msg_v2 { > int type; > __u32 reserved; Please use fixed sized types consistently. Use 's32' instead of 'int' here. Thanks!
2020 Feb 05
0
[PATCH] vhost: introduce vDPA based backend
...B_ACCESS_FAIL??? 4 > ??? __u8 type; > }; > > #define VHOST_IOTLB_MSG 0x1 > #define VHOST_IOTLB_MSG_V2 0x2 > > struct vhost_msg { > ??? int type; > ??? union { > ??? ??? struct vhost_iotlb_msg iotlb; > ??? ??? __u8 padding[64]; > ??? }; > }; > > struct vhost_msg_v2 { > ??? __u32 type; > ??? __u32 reserved; > ??? union { > ??? ??? struct vhost_iotlb_msg iotlb; > ??? ??? __u8 padding[64]; > ??? }; > }; Oh ok. So with a real device, I suspect we do not want to wait for each change to be processed by device completely, so we might want an a...
2020 Feb 05
2
[PATCH] vhost: introduce vDPA based backend
On 2020/2/5 ??10:05, Tiwei Bie wrote: > On Tue, Feb 04, 2020 at 02:46:16PM +0800, Jason Wang wrote: >> On 2020/2/4 ??2:01, Michael S. Tsirkin wrote: >>> On Tue, Feb 04, 2020 at 11:30:11AM +0800, Jason Wang wrote: >>>> 5) generate diffs of memory table and using IOMMU API to setup the dma >>>> mapping in this method >>> Frankly I think that's a
2020 Feb 05
2
[PATCH] vhost: introduce vDPA based backend
On 2020/2/5 ??10:05, Tiwei Bie wrote: > On Tue, Feb 04, 2020 at 02:46:16PM +0800, Jason Wang wrote: >> On 2020/2/4 ??2:01, Michael S. Tsirkin wrote: >>> On Tue, Feb 04, 2020 at 11:30:11AM +0800, Jason Wang wrote: >>>> 5) generate diffs of memory table and using IOMMU API to setup the dma >>>> mapping in this method >>> Frankly I think that's a
2020 Feb 05
0
[PATCH] vhost: introduce vDPA based backend
...IOTLB_MSG_V2 0x2 > > > > > > struct vhost_msg { > > > ??? int type; > > > ??? union { > > > ??? ??? struct vhost_iotlb_msg iotlb; > > > ??? ??? __u8 padding[64]; > > > ??? }; > > > }; > > > > > > struct vhost_msg_v2 { > > > ??? __u32 type; > > > ??? __u32 reserved; > > > ??? union { > > > ??? ??? struct vhost_iotlb_msg iotlb; > > > ??? ??? __u8 padding[64]; > > > ??? }; > > > }; > > Oh ok. So with a real device, I suspect we do not wan...
2020 Sep 24
30
[RFC PATCH 00/24] Control VQ support in vDPA
Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is
2020 Sep 24
30
[RFC PATCH 00/24] Control VQ support in vDPA
Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is