similar to: [vhost:vhost 38/45] include/linux/vdpa.h:43:21: error: expected ';' at end of declaration list

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 84d40e4b4bc64456abf5ef5663871053b40e84ac commit: fee8fe6bd8ccacd27e963b71b4f943be3721779e [38/45] vdpa: make sure set_features in invoked for legacy :::::: branch date: 5 hours ago :::::: commit date: 6 hours ago config: x86_64-randconfig-s021-20200727 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 84d40e4b4bc64456abf5ef5663871053b40e84ac commit: fee8fe6bd8ccacd27e963b71b4f943be3721779e [38/45] vdpa: make sure set_features in invoked for legacy config: m68k-randconfig-r022-20200727 (attached as .config) compiler: m68k-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget

Some legacy guests just assume features are 0 after reset. We detect that config space is accessed before features are set and set features to 0 automatically. Note: some legacy guests might not even access config space, if this is reported in the field we might need to catch a kick to handle these. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vdpa/vdpa.c | 1 +

Some legacy guests just assume features are 0 after reset. We detect that config space is accessed before features are set and set features to 0 automatically. Note: some legacy guests might not even access config space, if this is reported in the field we might need to catch a kick to handle these. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vdpa/vdpa.c | 1 +

On Wed, Aug 05, 2020 at 02:14:07PM +0800, Jason Wang wrote: > > On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > > Some legacy guests just assume features are 0 after reset. > > We detect that config space is accessed before features are > > set and set features to 0 automatically. > > Note: some legacy guests might not even access config space, if this is > >

On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > Some legacy guests just assume features are 0 after reset. > We detect that config space is accessed before features are > set and set features to 0 automatically. > Note: some legacy guests might not even access config space, if this is > reported in the field we might need to catch a kick to handle these. I wonder whether it's

On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > Some legacy guests just assume features are 0 after reset. > We detect that config space is accessed before features are > set and set features to 0 automatically. > Note: some legacy guests might not even access config space, if this is > reported in the field we might need to catch a kick to handle these. I wonder whether it's

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 84d40e4b4bc64456abf5ef5663871053b40e84ac commit: 03750f7fa49f9384911059fe16f5367b7e86f99d [40/45] virtio_vdpa: legacy features handling config: nds32-randconfig-r003-20200728 (attached as .config) compiler: nds32le-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget

On Wed, Feb 26, 2020 at 02:04:54PM +0800, Jason Wang wrote: > +struct vdpa_device *vdpa_alloc_device(struct device *parent, > + struct device *dma_dev, > + const struct vdpa_config_ops *config) > +{ > + struct vdpa_device *vdev; > + int err = -ENOMEM; > + > + if (!parent || !dma_dev || !config) > + goto err; > + > + vdev = kzalloc(sizeof(*vdev),

? 2023/2/7 20:08, Nanyong Sun ??: > From: Rong Wang <wangrong68 at huawei.com> > > Once enable iommu domain for one device, the MSI > translation tables have to be there for software-managed MSI. > Otherwise, platform with software-managed MSI without an > irq bypass function, can not get a correct memory write event > from pcie, will not get irqs. > The solution is

vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single Physical Function - VF (Virtual Function) - Device that supports

vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single Physical Function - VF (Virtual Function) - Device that supports

On Sun, Apr 02, 2023 at 11:10:34AM +0300, Alvaro Karsz wrote: > Add VIRTIO_F_NOTIFICATION_DATA support for vDPA transport. > If this feature is negotiated, the driver passes extra data when kicking > a virtqueue. > > A device that offers this feature needs to implement the > kick_vq_with_data callback. > > kick_vq_with_data receives the vDPA device and data. > data

On Sun, Apr 2, 2023 at 4:10?PM Alvaro Karsz <alvaro.karsz at solid-run.com> wrote: > > Add VIRTIO_F_NOTIFICATION_DATA support for vDPA transport. > If this feature is negotiated, the driver passes extra data when kicking > a virtqueue. > > A device that offers this feature needs to implement the > kick_vq_with_data callback. > > kick_vq_with_data receives the vDPA

Add VIRTIO_F_NOTIFICATION_DATA support for vDPA transport. If this feature is negotiated, the driver passes extra data when kicking a virtqueue. A device that offers this feature needs to implement the kick_vq_with_data callback. kick_vq_with_data receives the vDPA device and data. data includes: 16 bits vqn and 16 bits next available index for split virtqueues. 16 bits vqs, 15 least significant

Add VIRTIO_F_NOTIFICATION_DATA support for vDPA transport. If this feature is negotiated, the driver passes extra data when kicking a virtqueue. A device that offers this feature needs to implement the kick_vq_with_data callback. kick_vq_with_data receives the vDPA device and data. data includes the vqn, next_off and next_wrap for packed virtqueues. This patch follows a patch [1] by Viktor

On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote: > +/** > + * vdpa_register_device - register a vDPA device > + * Callers must have a succeed call of vdpa_init_device() before. > + * @vdev: the vdpa device to be registered to vDPA bus > + * > + * Returns an error when fail to add to vDPA bus > + */ > +int vdpa_register_device(struct vdpa_device *vdev) > +{

On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote: > +/** > + * vdpa_register_device - register a vDPA device > + * Callers must have a succeed call of vdpa_init_device() before. > + * @vdev: the vdpa device to be registered to vDPA bus > + * > + * Returns an error when fail to add to vDPA bus > + */ > +int vdpa_register_device(struct vdpa_device *vdev) > +{

On Wed, Jul 29, 2020 at 08:54:52AM +0300, Eli Cohen wrote: > On Tue, Jul 28, 2020 at 02:53:34PM +0800, Jason Wang wrote: > > > > Just notice Michael's vhost branch can not compile due to this commit: > > > > commit fee8fe6bd8ccacd27e963b71b4f943be3721779e > > Author: Michael S. Tsirkin <mst at redhat.com> > > Date:???? Mon Jul 27 10:51:55 2020

On 2020/2/11 ??9:47, Jason Gunthorpe wrote: > On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote: >> +/** >> + * vdpa_register_device - register a vDPA device >> + * Callers must have a succeed call of vdpa_init_device() before. >> + * @vdev: the vdpa device to be registered to vDPA bus >> + * >> + * Returns an error when fail to add to vDPA bus