> From: Tian, Kevin > Sent: Tuesday, February 15, 2022 6:42 PM > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Wednesday, February 9, 2022 10:37 AM > > > > > > /* -------- API for Type1 VFIO IOMMU -------- */ > > > > > > > > /** > > > > > > Otherwise, I'm still not sure how userspace handles the fact that it > > > can't know how much data will be read from the device and how > important > > > that is. There's no replacement of that feature from the v1 protocol > > > here. > > > > I'm not sure this was part of the v1 protocol either. Yes it had a > > pending_bytes, but I don't think it was actually expected to be 100% > > accurate. Computing this value accurately is potentially quite > > expensive, I would prefer we not enforce this on an implementation > > without a reason, and qemu currently doesn't make use of it. > > > > The ioctl from the precopy patch is probably the best approach, I > > think it would be fine to allow that for stop copy as well, but also > > don't see a usage right now. > > > > It is not something that needs decision now, it is very easy to detect > > if an ioctl is supported on the data_fd at runtime to add new things > > here when needed. > > > > Another interesting thing (not an immediate concern on this series) > is how to handle devices which may have long time (e.g. due to > draining outstanding requests, even w/o vPRI) to enter the STOP > state. that time is not as deterministic as pending bytes thus cannot > be reported back to the user before the operation is actually done. > > Similarly to what we discussed for vPRI an eventfd will be beneficial > so the user can timeout-wait on it, but it also needs an arc to create > the eventfd between RUNNING->STOP... > type too fast. it doesn’t need a new arc. Just a new capability to say that STOP returns an event fd for the user to wait for completion, when supporting such devices is required. 😊 Thanks Kevin
