On Mon, Jul 25, 2022 at 07:20:16AM +0000, Tian, Kevin wrote: > 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 you multi-thread the tracker reads it will be efficient to populate a single bitmap and then copy that single bitmapt to the dirty transfer. In this case you want the page size conversion. If qemu is just going to read sequentially then perhaps it doesn't. But forcing a fixed page size just denies userspace this choice, and it doesn't make the kernel any simpler because the kernel always must have this code to adapt different page sizes to support the real iommu with huge pages/etc. Jason
