> > It was the other proposal from long ago that created more regions. > > > > This is what I like and would prefer to stick with. REGION_INFO > > doesn't really change, we don't have two regions refering to the same > > physical memory, and we find some way to request NC/WC of a region at > > mmap time. > > "At mmap time" means that something in the vma needs to describe to us > to use the WC semantics, where I think you're proposing that the "mmap > cookie" provides a specific vm_pgoff which we already use to determine > the region index. Yes > So whether or not we want to call this a region, > it's effectively in the same address space as regions. Therefore "mmap > cookie" ~= "region offset". Well, that is just the current implementation. What we did in RDMA when we switched from hard coded mmap cookies to dynamic ones is use an xarray (today this should be a maple tree) to dynamically allocate mmap cookies whenever the driver returns something to userspace. During the mmap fop the pgoff is fed back through the maple tree to get the description of what the cookie represents. So the encoding of cookies is completely disjoint from whatever the underlying thing is. If you want the same region to be mapped with two or three different prot flags you just ask for two or three cookies and at mmap time you can recover the region pointer and the mmap flags. So VFIO could do several different things here to convay the mmap flags through the cookie, including somehow encoding it in a pgoff bit, or using a dynamic maple tree scheme. My point is to not confuse the pgoff encoding with the driver concept of a region. The region is a single peice of memory, the "mmap cookie"s are just handles to it. Adding more data to the handle is not the same as adding more regions. > > > At the limit they're the same. We could use a > > > DEVICE_FEATURE to ask vfio to selectively populate WC regions after > > > which the user could re-enumerate additional regions, or in fact to > > > switch on WC for a given region if we want to go that route. Thanks, > > > > This is still adding more regions and reporting more stuff from > > REGION_INFO, that is what I would like to avoid. > > Why? This reminds me of hidden registers outside of capability chains > in PCI config space. Thanks, The mmap offsets are not (supposed to be) ABI in the VFIO ioctls. The encoding is entirely opaque inside the kernel already. Apps are supposed to use REGION_INFO to learn the value to pass to mmap. ie things like VFIO_PCI_OFFSET_SHIFT are not in the uAPI header. Jason
