search for: vdpa_op

...m, or other bus and device. No need for an extra bus here, PCI is the bus. - No bus, ie for a simulator or binding to a netdev. (existing vhost?) They point is that the HW driver's job is to adapt from the bus level interfaces (eg readl/writel) to the subsystem level (eg something like the vdpa_ops). For instance that Intel driver should be a pci_driver to bind to a struct pci_device for its VF and then call some 'vhost&vdpa' _register() function to pass its ops to the subsystem which in turn creates the struct device of the subsystem calls, common char devices, sysfs, etc and...

...m, or other bus and device. No need for an extra bus here, PCI is the bus. - No bus, ie for a simulator or binding to a netdev. (existing vhost?) They point is that the HW driver's job is to adapt from the bus level interfaces (eg readl/writel) to the subsystem level (eg something like the vdpa_ops). For instance that Intel driver should be a pci_driver to bind to a struct pci_device for its VF and then call some 'vhost&vdpa' _register() function to pass its ops to the subsystem which in turn creates the struct device of the subsystem calls, common char devices, sysfs, etc and...

...lated ops access the virtio registers directly to take immediate actions. So ifcvf_start_datapath() should retire. ifcvf_add_status() is retierd because we should not change device status by a vendor driver's decision, this driver should only set device status which is from virito drivers upon vdpa_ops.set_status() Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> --- drivers/vdpa/ifcvf/ifcvf_base.c | 19 ------------------- drivers/vdpa/ifcvf/ifcvf_base.h | 1 - drivers/vdpa/ifcvf/ifcvf_main.c | 23 ----------------------- 3 files changed, 43 deletions(-) diff --git a/drivers/vd...

...- No bus, ie for a simulator or binding to a netdev. (existing vhost?) Note, simulator can have its own class (sysfs etc.). > > They point is that the HW driver's job is to adapt from the bus level > interfaces (eg readl/writel) to the subsystem level (eg something like > the vdpa_ops). > > For instance that Intel driver should be a pci_driver to bind to a > struct pci_device for its VF and then call some 'vhost&vdpa' > _register() function to pass its ops to the subsystem which in turn > creates the struct device of the subsystem calls, common char d...

On Thu, Feb 13, 2020 at 10:41:06AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:05:42AM -0400, Jason Gunthorpe wrote: > > On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote: > > > > > > On 2020/2/13 ??9:41, Jason Gunthorpe wrote: > > > > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote: > > > > > > >

On Thu, Feb 13, 2020 at 10:41:06AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:05:42AM -0400, Jason Gunthorpe wrote: > > On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote: > > > > > > On 2020/2/13 ??9:41, Jason Gunthorpe wrote: > > > > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote: > > > > > > >

Formerly, ifcvf driver has implemented a lazy-initialization mechanism for the virtqueues and other config space contents, it would store all configurations that passed down from the userspace, then load them to the device config space upon DRIVER_OK. This can not serve live migration, so this series implement an immediate initialization mechanism, which means rather than the former store-load

Formerly, ifcvf driver has implemented a lazy-initialization mechanism for the virtqueues and other config space contents, it would store all configurations that passed down from the userspace, then load them to the device config space upon DRIVER_OK. This can not serve live migration, so this series implement an immediate initialization mechanism, which means rather than the former store-load