> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Monday, July 25, 2022 10:37 PM > > On Mon, Jul 25, 2022 at 07:38:52AM +0000, Tian, Kevin wrote: > > > > Yes. qemu has to select a static aperture at start. > > > > > > The entire aperture is best, if that fails > > > > > > A smaller aperture and hope the guest doesn't use the whole space, if > > > that fails, > > > > > > The entire guest physical map and hope the guest is in PT mode > > > > That sounds a bit hacky... does it instead suggest that an interface > > for reporting the supported ranges on a tracker could be helpful once > > trying the entire aperture fails? > > It is the "try and fail" approach. It gives the driver the most > flexability in processing the ranges to try and make them work. If we > attempt to describe all the device constraints that might exist we > will be here forever. Usually the caller of a 'try and fail' interface knows exactly what to be tried and then call the interface to see whether the callee can meet its requirement. Now above turns out to be a 'guess and fail' approach with which the caller doesn't know exactly what should be tried. In this case even if the attempt succeeds it's a question how helpful it is. But I can see why a reporting mechanism doesn't fit well with your example below. In the worst case probably the user has to decide between using vIOMMU vs. vfio DMA logging if a simple policy of using the entire aperture doesn't work... > > Eg the driver might be able to do the entire aperture, but it has to > use 2M pages or something. >
