On 5/3/22 00:02, Jason Gunthorpe wrote: > On Mon, May 02, 2022 at 07:04:47PM -0300, Jason Gunthorpe wrote: >>> Ah great, implicit limitations not reported to the user that I hadn't >>> even guessed! How does a user learn about any limitations in the >>> number of ranges or size of each range? >> >> There is some limit of number of ranges and total aggregate address >> space, you think we should report rather than try-and-fail? >> >> I guess total address space and total number of ranges is easy to >> report, but I don't quite know what userspace will do with it? > > Actually, I recall now, the idea was that the driver would sort this > out. > > So, userspace would pass in whatever ranges it wanted and if the > device could do only. say 4, then the driver would merge adjacent > ranges till there were only 4 - and limit each range to any device > limit there may be and so on and so forth. > > If the result was unfittable then it fails and the only thing > userspace can do is try with less. > > So, if userspace wants to do 'minimal + extra for hotplug' then on > failure it should try 'minimal' and on failure of that give up > completely. > Is it worth classifying the range as present or not, say a ::flags of vfio_device_feature_dma_logging_range to help choosing what to aggregate or not? Provided the number of calls might be undeterministic? > Then we don't have to try and catalog all the weird device choices we > might need into some query function. > > Yishahi, this concept should be called out in the documentation, and > we probably need some core code to pull the ranges into an interval > tree and validate they are non-overlapping and so forth > > Jason
