On Wed, Dec 07, 2022 at 04:30:20AM +0200, Max Gurtovoy wrote: > I'm not sure how awkward is for migration driver to ask the controlling > device driver to operate a migration action. It can't. That's the whole point. The controlled function that is being migrate must be absolutely unaware of that (except for things like quiescing access or FLRs that could happen anyway), because otherwise your have a fundamental information leak. > The controlling device driver can expose limited API for that matter. No, it can't. It must be in charge. > Also the concept of primary controller that control it's secondary > controllers is already in the SPEC so we can use it. It's not introduced in > this RFC but we're here to fix it. Yes, it is as I've pointed out multiple times. But, that relationship is only visible to the primary controller. It also doesn't help with the general problem where the secondary controller must be able to completely change it's identify and thus the subsystem. > In our case the primary controller is the PF and the secondary controllers > are the VFs. Yes, that's your case, and probably a very common one. But also far from the only one, so there is no way Linux or the specification can rely on that dumb fact. Never mind that there are virtualization schemes (look at the s390 code) where the PF to VF relationship gets lost.
