RE: [PATCH v3 6/8] admin: Add theory of operation for write recording commands

[Parav Pandit <parav@nvidia.com>]

> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Friday, November 17, 2023 3:23 PM
> 
> 
> On 11/17/2023 5:41 PM, Parav Pandit wrote:
> >
> >> From: Michael S. Tsirkin <mst@redhat.com>
> >> Sent: Friday, November 17, 2023 3:08 PM
> >>
> >> On Fri, Nov 17, 2023 at 09:14:21AM +0000, Parav Pandit wrote:
> >>>
> >>>> From: Michael S. Tsirkin <mst@redhat.com>
> >>>> Sent: Friday, November 17, 2023 2:16 PM In any case you can safely
> >>>> assume that many users will have migration that takes seconds and
> >>>> minutes.
> >>> Strange, but ok. I don't see any problem with current method.
> >>> 8MB is used for very large VM of 1TB takes minutes. Should be fine.
> >> The problem is simple: vendors selling devices have no idea how large
> >> the VM will be. So you have to over-provision for the max VM size.
> >> If there was a way to instead allocate that in host memory, that
> >> would improve on this.
> > Not sure what to over provision for max VM size.
> > Vendor does not know how many vcpus will be needed. It is no different
> problem.
> >
> > When the VM migration is started, the individual tracking range is supplied by
> the hypervisor to device.
> > Device allocates necessary memory on this instruction.
> >
> > When the VM with certain size is provisioned, the member device can be
> provisioned for the VM size.
> > And if it cannot be provisioned, possibly this may not the right member device
> to use at that point in time.
> I think Michael means the guest memory can be large, and the device may DMA
> anywhere, so the device should prepare for the worst case, that could be U64
> size which can be over-provision.

No. that is not true. 
The hypervisor supplies the range of addresses on which to track the dirty pages.
So for sure it is not u64.