Re: [PATCH RFC] vfio: Revise and update the migration uAPI description

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Jan 27, 2022 at 12:38:24AM +0000, Tian, Kevin wrote:
> > So.. this vPRI requirement is quite a big deviation. We can certainly
> > handle it inside the FSM framework, but it doesn't seem backward
> > compatible. I wouldn't worry too much about defining it now at least
> 
> Now I see your point. Yes, we have to do some incompatible way to
> support vPRI. In the end we need part of arc in FSM can run with 
> active vCPUs.

I still think the right answer is a new state that stops new PRIs from
coming, I'm just not sure what that means. If the device can't
actually stop PRIs until it has completed PRIs - that is pretty messed
up - but it means at least we have this weird PRI state that might
timeout on some devices, and better devices might immediately return.

This is even quite possibly the same HW function as NDMA..

Anyhow, due to this discussion I redid our v2 draft to use cap bits
instead of the arc_supported ioctl, as it seems like it is more robust
against the notion in future some devices won't even support the basic
mandatory transitions. So we'd turn off old bits and turn on new bits
for these devices..

Jason