Re: [PATCH RFC v2] vfio: Documentation for the migration region

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Dec 07, 2021 at 05:30:29PM +0100, Cornelia Huck wrote:
> On Tue, Dec 07 2021, Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> > On Tue, Dec 07, 2021 at 12:16:32PM +0100, Cornelia Huck wrote:
> >> On Mon, Dec 06 2021, Jason Gunthorpe <jgg@nvidia.com> wrote:
> >> 
> >> > On Mon, Dec 06, 2021 at 07:06:35PM +0100, Cornelia Huck wrote:
> >> >
> >> >> We're discussing a complex topic here, and we really don't want to
> >> >> perpetuate an unclear uAPI. This is where my push for more precise
> >> >> statements is coming from.
> >> >
> >> > I appreciate that, and I think we've made a big effort toward that
> >> > direction.
> >> >
> >> > Can we have some crisp feedback which statements need SHOULD/MUST/MUST
> >> > NOT and come to something?
> >> 
> >> I'm not sure what I should actually comment on, some general remarks:
> >
> > You should comment on the paragraphs that prevent you from adding a
> > reviewed-by.
> 
> On which copy? There have been updates, and I haven't found a conchise
> email to reply to.

I'll send a v3

> >> - If we consider a possible vfio-ccw implementation that will quiesce
> >>   the device and not rely on tracking I/O, we need to make the parts
> >>   that talk about tracking non-mandatory.
> >
> > I'm not sure what you mean by 'tracking I/O'?
> 
> MMIO.

If there is no MMIO there is nothing to worry about, right?

S390 should define its own rules around quieting whatever non-MMIO
control path exists between the VM and the mdev.
 
> > The precedence follows the reference flow so that any conflicts
> > resolve along the path that already has defined behaviors.
> 
> Well, yes. I'm just wondering where bit groups are coming in
> then. That's where I'm confused (by the discussion).

Bit groups are things like "SAVING | RUNNING". Bit SAVING does not
have any meaning on its own, it is always qualified by running.

> >> 6 weeks is already blazingly fast in any vfio migration discussion. /s
> >
> > We've invested a lot of engineer months in this project, it is
> > disrespectful to all of this effort to leave us hanging with no clear
> > path forward and no actionable review comments after so much
> > time. This is another kernel cycle lost.
> 
> Well... it's not only you who are spending time on this. I'm trying to
> follow the discussion, which is not easy, and try to come up with
> feedback, which is not easy, either. This is using up a huge chunk of my
> time. Compared with the long and tedious discussions that led to the
> initial code being merged, we're really going very fast. 

Well, yes, we are serious about getting this merged and we are fully
committed to upstream quality and good design. 

In the end we all agree - we are only working through all the edges
and special cases that always existed here but were never fully
discussed.

> And expecting people to drop everything and make a definite desicion
> quickly when there are still open questions on a complex topic does
> not strike me as particularly respectful, either.

I don't even know what is the list open questions anymore! As far as I
know everything in the etherpad is addressed by the documentation I
prepared.

> >> Remember that we have other things to do as well, not all of which will
> >> be visible to you.
> >
> > As do we all, but your name is in the maintainer file, and that comes
> > with some responsibility.
> 
> It, however, does not mean that someone listed in MAINTAINERS must
> immediately deal with anything that is thrown at them to the detriment
> of everything else. 

I don't see this as immediately at all, please don't take it as such a
demand.

We posted v1 in September, it is now Decemeber, we want to know what
we need to do to get this merged. I've asked several times now, and
I'm not seeing a clear answer :(

My suggestion is we agree on the document I wrote as a general
understanding what we are doing (not so much a spec) and we proceed.

We now have a lot of experience with physical device migration here, I
think it is reasonable to extend some trust that we are implementing
something that is reasonable as a uAPI.

> [There is a reason why I have dropped out of some maintainership entries
> recently, the asymmetry of people requiring feedback and merging and
> people actually giving feedback and merging seems to have gotten worse
> over the last years. I can certainly delist myself as a vfio reviewer as
> well, and while that would certainly help my wellbeing, I'm not sure
> whether that is what you want.]

No, I do not want that, and am not suggesting that.

Regards,
Jason