> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Thursday, July 21, 2022 7:51 PM > > On Thu, Jul 21, 2022 at 08:54:39AM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > Sent: Wednesday, July 20, 2022 4:08 AM > > > > > > On Tue, Jul 19, 2022 at 01:25:14PM -0600, Alex Williamson wrote: > > > > > > > > We don't really expect user space to hit this limit, the RAM in QEMU is > > > > > divided today to around ~12 ranges as we saw so far in our evaluation. > > > > > > > > There can be far more for vIOMMU use cases or non-QEMU drivers. > > > > > > Not really, it isn't dynamic so vIOMMU has to decide what it wants to > > > track up front. It would never make sense to track based on what is > > > currently mapped. So it will be some small list, probably a big linear > > > chunk of the IOVA space. > > > > How would vIOMMU make such decision when the address space > > is managed by the guest? it is dynamic and could be sparse. I'm > > curious about any example a vIOMMU can use to generate such small > > list. Would it be a single range based on aperture reported from the > > kernel? > > 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? > > All of these options are small lists. > > Any vIOMMU maps that are created outside of what was asked to be > tracked have to be made permanently dirty by qemu. > > Jason
