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

[Parav Pandit <parav@nvidia.com>]

> From: Parav Pandit <parav@nvidia.com>
> Sent: Friday, November 17, 2023 3:12 PM
> 
> 
> > 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.

Clicked little early,
I agree that,
And if the dynamic host memory by the owner device, an extension could be have request/event queue from the owner device depending on the algorithm and size of VM it runs.