Re: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio

[Max Gurtovoy]

On 5/27/2021 1:11 PM, Shameerali Kolothum Thodi wrote:
> [+]
>
> Hi,
>
> > -----Original Message-----
> > From: Jason Gunthorpe [mailto:jgg@xxxxxxxxxx]
> > Sent: 13 May 2021 19:24
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx>
> > Cc: Alex Williamson <alex.williamson@xxxxxxxxxx>; liulongfang
> > <liulongfang@xxxxxxxxxx>; cohuck@xxxxxxxxxx;
> > linux-kernel@xxxxxxxxxxxxxxx; linuxarm@xxxxxxxxxxxxx
> > Subject: Re: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to
> > vfio
> >
> > On Thu, May 13, 2021 at 05:52:56PM +0000, Shameerali Kolothum Thodi
> > wrote:
> >
> > > Since the devices we are concerned here are all integrated endpoints and if
> > the
> > > above quirk is an acceptable one, then we can use the uAPI as done in this
> > > series without overly complicating things here.
> > IMHO such a quirk in the core code should not be done. You need to
> > override this in your own driver like Max was showing.
> >
> > I think we are very close to having worked out a great solution to the
> > lingering questions on Max's last RFC, hopefully we can post an
> > updated version soon
> We have now integrated this HiSilicon ACC live migration driver into the
> proposed[0] vfio-pci-core subsystem framework. Basically now have
> a new vendor extension driver based on this framework. It indeed makes it
> easy to do the registration to vfio core and overriding of functions if required.
> Performed some basic sanity tests with the prototype and it seems to be
> working.

Great news.


> Also, we now managed to get rid of any access to Guest VF dev MMIO space
> during the (VFIO_DEVICE_STATE_SAVING | VFIO_DEVICE_STATE_RUNNING)
> state. However we still need to access the Guest VF MMIO space during
> few other device states eg; VFIO_DEVICE_STATE_SAVING, VFIO_DEVICE_STATE_STOP
> etc. These accesses are to save and restore device register states. As per our
> analysis the Guest vCPUs are in stopped state at these device states. So I
> hope we don't have any security related holes with these accesses.

We can start talking about more API's that are missing.

> Please let us know if we miss something or anything else to be taken care of with
> this approach.
>
> We are planning to send out a revised RFC soon, and if there is a plan to
> post an updated one to Max's series as mentioned above, will base
> it on that one. Please let us know.

I'll send a new version of the series soon with many improvements that 
we'll taken from previous discussion.

I'll add you as CC.


> Thanks,
> Shameer
> [0] https://lore.kernel.org/lkml/20210310123127.GT2356281@xxxxxxxxxx/T/