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

[Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>]

[+]

Hi,

> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgg@nvidia.com]
> Sent: 13 May 2021 19:24
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>; liulongfang
> <liulongfang@huawei.com>; cohuck@redhat.com;
> linux-kernel@vger.kernel.org; linuxarm@openeuler.org
> 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.

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.

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.

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