Re: [PATCH V2 6/6] virtio-pci: implement dirty page tracking

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 11/3/2023 7:35 PM, Parav Pandit wrote:
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Friday, November 3, 2023 4:20 PM
> >
> > On Fri, Nov 03, 2023 at 06:34:37PM +0800, Zhu Lingshan wrote:
> > > +\item[\field{bitmap_addr}]
> > > +	The driver use this to set the address of the bitmap which records the
> > dirty pages
> > > +	caused by the device.
> > > +	Each bit in the bitmap represents one memory page, bit 0 in the bitmap
> > > +	reprsents page 0 at address 0, bit 1 represents page 1, and so on in a
> > linear manner.
> > > +	When \field{enable} is set to 1 and the device writes to a memory page,
> > > +	the device MUST set the corresponding bit to 1 which indicating the
> > page is dirty.
> > > +\item[\field{bitmap_length}]
> > > +	The driver use this to set the length in bytes of the bitmap.
> > > +\end{description}
> > > +
> > > +\devicenormative{\subsubsection}{Memory Dirty Pages Tracker
> > > +Capability}{Virtio Transport Options / Virtio Over PCI Bus / Memory
> > > +Dirty Pages Tracker Capability}
> > > +
> > > +The device MUST NOT set any bits beyond bitmap_length when reporting
> > dirty pages.
> > > +
> > > +To prevent a read-modify-write procedure, if a memory page is dirty,
> It is not to prevent; it is just not possible to do racy RMW. ð
if you understand what is a atomic routine, you will not call it racy.
> Hence to work around you propose to mark all pages dirty. Too bad.
> This just does not work.
why? and this is optional.
> Secondly the bitmap array is function is for full guest memory size, while there is lot of sparce region now and also in future.
> This is the second problem.
did you see gra_power and its comments?
> This is exactly why I asked you to review the page write recording series of admin commands and comment.
> And you never commented with sheer ignorance.
>
> So clearly the start stop method for specific range and without bandwidth explosion, admin commands of [1] stands better.
>
> If you do [1] on the member device also using its AQ in future, it will work for non-passthrough case.
> If you build non-passthrough live migration using [1], also it will work.
> So I donât see any point of this series anymore.
As Jason pointed out, there are many problems in your proposal,
you should answer there. I don't need to repeat his words and duplicate 
the discussions.
> [1] https://lists.oasis-open.org/archives/virtio-comment/202310/msg00475.html
you still need to explain why this does not work for pass-through. And I 
remember this is a point-less topic as MST ever wants to mute
another "pass-through" thread.
> > > +optionally the device is permitted to set the entire byte, which encompasses
> > the relevant bit, to 1.
> > > +
> > > +The device MAY increase \field{gra_power} to reduce \field{bitmap_length}.
> > > +
> > > +The device must ignore any writes to \field{pasid} if PASID Extended
> > > +Capability is absent or the PASID functionality is disabled in PASID
> > > +Extended Capability
> >
> > I have to say this is going to work very badly when the number of dirty pages is
> > small: you will end up scanning and re-scanning all of bitmap.
> > And the resolution is apparently 8 pages? You have just multiplied the migration
> > bandwidth by a factor of 8.
> Yeah.
> And device does not even know previously reported pages are read by driver or not. All guess work game for driver and device.
see my reply to him