> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Thursday, July 28, 2022 8:06 PM > > On Thu, Jul 28, 2022 at 04:05:04AM +0000, Tian, Kevin wrote: > > > > I think this is not correct, just because we made it discoverable does > > > not absolve the kernel of compatibility. If we change the limit, eg to > > > 1, and a real userspace stops working then we still broke userspace. > > > > iiuc Alex's suggestion doesn't conflict with the 'try and fail' model. > > By using the reserved field of vfio_device_feature_dma_logging_control > > to return the limit of the specified page_size from a given tracker, > > the user can quickly retry and adapt to that limit if workable. > > Again, no it can't. The marshalling limit is not the device limit and > it will still potentially fail. Userspace does not gain much > additional API certainty by knowing this internal limit. Why cannot the tracker return device limit here? > > > Otherwise what would be an efficient policy for user to retry after > > a failure? Say initially user requests 100 ranges with 4K page size > > but the tracker can only support 10 ranges. w/o a hint returned > > from the tracker then the user just blindly try 100, 90, 80, ... or > > using a bisect algorithm? > > With what I just said the minimum is PAGE_SIZE, so if some userspace > is using a huge range list it should try the huge list first (assuming > the kernel has been updated because someone justified a use case > here), then try to narrow to PAGE_SIZE, then give up. Then probably it's good to document above as a guidance to userspace. > > The main point is there is nothing for current qemu to do - we do not > want to duplicate the kernel narrowing algorithm into qemu - the idea > is to define the interface in a way that accomodates what qemu needs. > > The only issue is the bounding the memory allocation. > > Jason
