On Thu, Oct 28 2021, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Thu, Oct 28, 2021 at 09:30:35AM -0600, Alex Williamson wrote: >> On Wed, 27 Oct 2021 16:23:45 -0300 >> Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: >> >> > On Wed, Oct 27, 2021 at 01:05:20PM -0600, Alex Williamson wrote: >> > >> > > > As far as the actual issue, if you hadn't just discovered it now >> > > > nobody would have known we have this gap - much like how the very >> > > > similar reset issue was present in VFIO for so many years until you >> > > > plugged it. >> > > >> > > But the fact that we did discover it is hugely important. We've >> > > identified that the potential use case is significantly limited and >> > > that userspace doesn't have a good mechanism to determine when to >> > > expose that limitation to the user. >> > >> > Huh? >> > >> > We've identified that, depending on device behavior, the kernel may >> > need to revoke MMIO access to protect itself from hostile userspace >> > triggering TLP Errors or something. >> > >> > Well behaved userspace must already stop touching the MMIO on the >> > device when !RUNNING - I see no compelling argument against that >> > position. >> >> Not touching MMIO is not specified in our uAPI protocol, > > To be frank, not much is specified in the uAPI comment, certainly not > a detailed meaning of RUNNING. Yes! And I think that means we need to improve that comment before the first in-tree driver to use it is merged, just to make sure we all agree on the protocol, and future drivers can rely on that understanding as well.
