On Fri, 29 Apr 2022 05:45:20 +0000 "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > From: Joao Martins <joao.m.martins@xxxxxxxxxx> > > 3) Unmapping an IOVA range while returning its dirty bit prior to > > unmap. This case is specific for non-nested vIOMMU case where an > > erronous guest (or device) DMAing to an address being unmapped at the > > same time. > > an erroneous attempt like above cannot anticipate which DMAs can > succeed in that window thus the end behavior is undefined. For an > undefined behavior nothing will be broken by losing some bits dirtied > in the window between reading back dirty bits of the range and > actually calling unmap. From guest p.o.v. all those are black-box > hardware logic to serve a virtual iotlb invalidation request which just > cannot be completed in one cycle. > > Hence in reality probably this is not required except to meet vfio > compat requirement. Just in concept returning dirty bits at unmap > is more accurate. > > I'm slightly inclined to abandon it in iommufd uAPI. Sorry, I'm not following why an unmap with returned dirty bitmap operation is specific to a vIOMMU case, or in fact indicative of some sort of erroneous, racy behavior of guest or device. We need the flexibility to support memory hot-unplug operations during migration, but even in the vIOMMU case, isn't it fair for the VMM to ask whether a device dirtied the range being unmapped? This was implemented as a single operation specifically to avoid races where ongoing access may be available after retrieving a snapshot of the bitmap. Thanks, Alex
