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
Jason
-----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.
Ok. Sure, will take a look at that.
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
Cool. If possible kindly CC us when it happens.
Thanks, Shameer
[+]
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/
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/
-
Jason Gunthorpe -
Max Gurtovoy -
Shameerali Kolothum Thodi