Linux Virtualization - Apr 2023 - [PATCH 0/5] vDPA/ifcvf: implement immediate initialization mechanism

On Mon, Apr 24, 2023 at 11:50:20AM +0800, Jason Wang
wrote:
> On Thu, Apr 20, 2023 at 5:17?PM Zhu, Lingshan <lingshan.zhu at
intel.com> wrote:
> >
> >
> >
> > On 4/3/2023 6:10 PM, Zhu, Lingshan wrote:
> > >
> > >
> > > On 4/3/2023 1:28 PM, Jason Wang wrote:
> > >> On Fri, Mar 31, 2023 at 8:49?PM Zhu Lingshan <lingshan.zhu
at intel.com>
> > >> 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 process, the virtio operations like vq
ops
> > >>> would take immediate actions by access the virtio
registers.
> > >> Is there any chance that ifcvf can use virtio_pci_modern_dev
library?
> > >>
> > >> Then we don't need to duplicate the codes.
> > >>
> > >> Note that pds_vdpa will be the second user for
virtio_pci_modern_dev
> > >> library (and the first vDPA parent to use that library).
> > > Yes I agree this library can help a lot for a standard virtio pci
device.
> > > But this change would be huge, its like require to change every
line of
> > > the driver. For example current driver functions work on the
adapter and
> > > ifcvf_hw, if we wants to reuse the lib, we need the driver work
on
> > > struct virtio_pci_modern_device.
> > > Almost need to re-write the driver.
> > >
> > > Can we plan this huge change in following series?
> > ping
> 
> Will go through this this week.
> 
> Thanks
why do you expect it to go through, you didn't ack?
> > >
> > > Thanks,
> > > Zhu Lingshan
> > >>
> > >> Thanks
> > >>
> > >>> This series also implement irq synchronization in the
reset
> > >>> routine
> > >>>
> > >>> Zhu Lingshan (5):
> > >>>    virt queue ops take immediate actions
> > >>>    get_driver_features from virito registers
> > >>>    retire ifcvf_start_datapath and ifcvf_add_status
> > >>>    synchronize irqs in the reset routine
> > >>>    a vendor driver should not set _CONFIG_S_FAILED
> > >>>
> > >>>   drivers/vdpa/ifcvf/ifcvf_base.c | 162
> > >>> +++++++++++++++++++-------------
> > >>>   drivers/vdpa/ifcvf/ifcvf_base.h |  16 ++--
> > >>>   drivers/vdpa/ifcvf/ifcvf_main.c |  97
++++---------------
> > >>>   3 files changed, 122 insertions(+), 153 deletions(-)
> > >>>
> > >>> --
> > >>> 2.39.1
> > >>>
> > >
> >

On Mon, Apr 24, 2023 at 12:53?PM Michael S. Tsirkin <mst at redhat.com>
wrote:
>
> On Mon, Apr 24, 2023 at 11:50:20AM +0800, Jason Wang wrote:
> > On Thu, Apr 20, 2023 at 5:17?PM Zhu, Lingshan <lingshan.zhu at
intel.com> wrote:
> > >
> > >
> > >
> > > On 4/3/2023 6:10 PM, Zhu, Lingshan wrote:
> > > >
> > > >
> > > > On 4/3/2023 1:28 PM, Jason Wang wrote:
> > > >> On Fri, Mar 31, 2023 at 8:49?PM Zhu Lingshan
<lingshan.zhu at intel.com>
> > > >> 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 process, the virtio operations
like vq ops
> > > >>> would take immediate actions by access the virtio
registers.
> > > >> Is there any chance that ifcvf can use
virtio_pci_modern_dev library?
> > > >>
> > > >> Then we don't need to duplicate the codes.
> > > >>
> > > >> Note that pds_vdpa will be the second user for
virtio_pci_modern_dev
> > > >> library (and the first vDPA parent to use that library).
> > > > Yes I agree this library can help a lot for a standard
virtio pci device.
> > > > But this change would be huge, its like require to change
every line of
> > > > the driver. For example current driver functions work on the
adapter and
> > > > ifcvf_hw, if we wants to reuse the lib, we need the driver
work on
> > > > struct virtio_pci_modern_device.
> > > > Almost need to re-write the driver.
> > > >
> > > > Can we plan this huge change in following series?
> > > ping
> >
> > Will go through this this week.
> >
> > Thanks
>
> why do you expect it to go through, you didn't ack?
I meant I will have a look at it this week,

(Google told me "go through" meant "to look at or examine
something carefully")

Thanks
>
> > > >
> > > > Thanks,
> > > > Zhu Lingshan
> > > >>
> > > >> Thanks
> > > >>
> > > >>> This series also implement irq synchronization in
the reset
> > > >>> routine
> > > >>>
> > > >>> Zhu Lingshan (5):
> > > >>>    virt queue ops take immediate actions
> > > >>>    get_driver_features from virito registers
> > > >>>    retire ifcvf_start_datapath and ifcvf_add_status
> > > >>>    synchronize irqs in the reset routine
> > > >>>    a vendor driver should not set _CONFIG_S_FAILED
> > > >>>
> > > >>>   drivers/vdpa/ifcvf/ifcvf_base.c | 162
> > > >>> +++++++++++++++++++-------------
> > > >>>   drivers/vdpa/ifcvf/ifcvf_base.h |  16 ++--
> > > >>>   drivers/vdpa/ifcvf/ifcvf_main.c |  97
++++---------------
> > > >>>   3 files changed, 122 insertions(+), 153
deletions(-)
> > > >>>
> > > >>> --
> > > >>> 2.39.1
> > > >>>
> > > >
> > >
>