Messages in this thread | | | Subject | Re: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio | From | Max Gurtovoy <> | Date | Thu, 27 May 2021 13:30:40 +0300 |
| |
On 5/27/2021 1:11 PM, Shameerali Kolothum Thodi wrote: > [+] > > 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.
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@nvidia.com/T/ > >
| |