> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Thursday, July 21, 2022 8:05 PM > > On Thu, Jul 21, 2022 at 08:45:10AM +0000, Tian, Kevin wrote: > > > > + * will format its internal logging to match the reporting page size, > possibly > > > + * by replicating bits if the internal page size is lower than requested. > > > > what's the purpose of this? I didn't quite get why an user would want to > > start tracking in one page size and then read back the dirty bitmap in > > another page size... > > There may be multiple kernel trackers that are working with different > underlying block sizes, so the concept is userspace decides what block > size it wants to work in and the kernel side transparently adapts. The > math is simple so putting it in the kernel is convenient. > > Effectively the general vision is that qemu would allocate one > reporting buffer and then invoke these IOCTLs in parallel on all the > trackers then process the single bitmap. Forcing qemu to allocate > bitmaps per tracker page size is just inefficient. > I got that point. But my question is slightly different. A practical flow would like below: 1) Qemu first requests to start dirty tracking in 4KB page size. Underlying trackers may start tracking in 4KB, 256KB, 2MB, etc. based on their own constraints. 2) Qemu then reads back dirty reports in a shared bitmap in 4KB page size. All trackers must update dirty bitmap in 4KB granular regardless of the actual size each tracker selects. Is there a real usage where Qemu would want to attempt different page sizes between above two steps? If not then I wonder whether a simpler design is to just have page size specified in the first step and then inherited by the 2nd step... Thanks Kevin
