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

[Max Gurtovoy <mgurtovoy@nvidia.com>]

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/
>
>