Peter Xu <pet...@redhat.com> writes: > On Thu, Aug 26, 2021 at 09:43:59AM -0400, Peter Xu wrote: >> > > A simple state machine can track "has IOMMU" state. It has three states >> > > "no so far", "yes", and "no", and two events "add IOMMU" and "add device >> > > that needs to know". State diagram: >> > > >> > > no so far >> > > +--- (start state) ---+ >> > > | | >> > > add IOMMU | | add device that >> > > | | needs to know >> > > v v >> > > +--> yes no <--+ >> > > | | add device that | | >> > > +-----+ needs to know +-----+ >> > > >> > > "Add IOMMU" in state "no" is an error. >> > >> > question is how we distinguish "device that needs to know" >> > from device that doesn't need to know, and then recently >> > added feature 'bypass IOMMU' adds more fun to this. >> >> Maybe we can start from "no device needs to know"? Then add more into it when >> the list expands. >> >> vfio-pci should be a natural fit because we're sure it won't break any valid >> old configurations. However we may need to be careful on adding more >> devices, >> e.g. when some old configuration might work on old binaries, but I'm not >> sure. > > Btw, I think this state machine is indeed bringing some complexity on even > understanding it - it is definitely working but it's not obvious to anyone at > the first glance, and it's only solving problem for vIOMMU. E.g., do we need > yet another state machine for some other ordering constraints? > > From that POV, I don't like this solution more than the simple "assign > priority > for device realization" idea..
I wouldn't worry about other ordering constraints until we have them. If you do, please tell! I'm hoping you can't, because such implicit constraints are commonly signs of oversimplified / screwed up machine modeling.
