On Thu, Mar 11, 2021 at 06:53:16PM -0800, Alexander Duyck wrote: > On Thu, Mar 11, 2021 at 3:21 PM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > > On Thu, Mar 11, 2021 at 01:49:24PM -0800, Alexander Duyck wrote: > > > > We don't need to invent new locks and new complexity for something > > > > that is trivially solved already. > > > > > > I am not wanting a new lock. What I am wanting is a way to mark the VF > > > as being stale/offline while we are performing the update. With that > > > we would be able to apply similar logic to any changes in the future. > > > > I think we should hold off doing this until someone comes up with HW > > that needs it. The response time here is microseconds, it is not worth > > any complexity <...> > Another way to think of this is that we are essentially pulling a > device back after we have already allocated the VFs and we are > reconfiguring it before pushing it back out for usage. Having a flag > that we could set on the VF device to say it is "under > construction"/modification/"not ready for use" would be quite useful I > would think. It is not simple flag change, but change of PCI state machine, which is far more complex than holding two locks or call to sysfs_create_file in the loop that made Bjorn nervous. I want to remind again that the suggestion here has nothing to do with the real use case of SR-IOV capable devices in the Linux. The flow is: 1. Disable SR-IOV driver autoprobe 2. Create as much as possible VFs 3. Wait for request from the user to get VM 4. Change MSI-X table according to requested in item #3 5. Bind ready to go VF to VM 6. Inform user about VM readiness The destroy flow includes VM destroy and unbind. Let's focus on solutions for real problems instead of trying to solve theoretical cases that are not going to be tested and deployed. Thanks
