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. > 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. 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
