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
