Re: [RFC 7/7] migration: call qemu_savevm_state_pending_exact() with the guest stopped

[Joao Martins]

On 14/10/2022 12:28, Juan Quintela wrote:
> Joao Martins <joao.m.martins@oracle.com> wrote:
>> On 13/10/2022 17:08, Juan Quintela wrote:
>>> Oops.  My understanding was that once the guest is stopped you can say
>>> how big is it. 
> 
> Hi
> 
>> It's worth keeping in mind that conceptually a VF won't stop (e.g. DMA) until
>> really told through VFIO. So, stopping CPUs (guest) just means that guest 
>> code
>> does not arm the VF for more I/O but still is a weak guarantee as VF still 
>> has
>> outstanding I/O to deal with until VFIO tells it to quiesce DMA (for devices
>> that support it).
> 
> How can we make sure about that?
> 
> i.e. I know I have a vfio device.  I need two things:
> - in the iterative stage, I eed to check the size, but a estimate is ok.
>   for example with RAM, we use whatever is the size of the dirty bitmap
>   at that moment.
>   If the estimated size is smaller than the theshold, we
>    * stop the guest
>    * sync dirty bitmap
>    * now we test the (real) dirty bitmap size
> 
> How can we do something like that with a vfio device.
> 
You would have an extra intermediate step that stops the VF prior to asking
the device state length. What I am not sure is whether stopping
vCPUs can be skipped as an optimization. In theory you could, but perhaps
is best to be conservative and handling with same assumptions as any other guest
related state.

> 
>>> That is a deal breaker.  We can't continue if we don't
>>> know the size.  Copying the whole state to know the size looks too much.
>>>
>>
>> It's fair to say that the kernel could know the size of the state once the 
>> VF is
>> stopped but right now it is only on the STOP -> STOP_COPY arc (which is when 
>> it
>> is saved to kernel pages, regardless of userspace reading it). And it will 
>> block
>> read() until device has finished transferring it (unless you do a nonblocking
>> read ofc). Knowing the device state would need to be reflected in the vfio 
>> UAPI
>> and needs that adjustment. Providing total length ahead of device transfer 
>> might
>> depend on the hardware, but current vfio vendor drivers look capable of that
>> (from looking at the code).
> 
> I have no clue about vfio, so I need help here.  I can only provide
> hooks.  But I expect that we should be able to convince firmware to give
> us that information.
> 
The above was me talking about kernel interface.

>>>> It would need a @data_size in addition to @data_fd in
>>>> vfio_device_feature_mig_state, or getting fseek supported over the fd
>>>
>>> Ok, we can decided how to do it, but I think that putting fseek into it
>>> will only make things more complicated.
>>>
>>
>> fseek() was just a suggestion as a way to calculate file length (device state
>> length) with current file APIs:
>>
>>      fseek(data_fd, 0L, SEEK_END);
>>      size = ftell(data_fd);
>>
>> @data_size way is likely better (or simpler), but it would need to get an 
>> extra
>> u64 added into  VFIO_DEVICE_FEATURE_MIG_DEVICE_STATE ioctl
>>
>> I am sure there are other alternatives
> 
> My understanding from NVidia folks was that newer firmware have an ioctl
> to return than information.
> 

Maybe there's something new. I was thinking from this here:

https://github.com/torvalds/linux/blob/master/drivers/vfio/pci/mlx5/cmd.c#L47

mlx5vf_cmd_query_vhca_migration_state()

The hisilicon one looks to be always the same size

What both probably assume is that the device has been suspended prior to making
this call. We would use those interface to return this @data_size as said above
or whatever reasonable alternative folks had discussed.

>>>>> So we need to stop the vm "before" we
>>>>> cal the functions.
>>>>>
>>>>> It is a hack because:
>>>>> - we are "starting" the guest again to stop it in migration_complete()
>>>>>   I know, I know, but it is not trivial to get all the information
>>>>>   easily to migration_complete(), so this hack.
>>>>>
>>>>
>>>> Could you expand on that? Naively, I was assuming that by 'all 
>>>> information' the
>>>> locally stored counters in migration_iteration_run() that aren't present in
>>>> MigrateState?
>>>
>>> This is not related to vfio at all.
>>>> The problem is that current code assumes that the guest is still
>>> running, and then do qemu_mutex_lock_iothread() and unlock() inside the
>>> pending handlers.  To stop the guest, we need to lock the iothread
>>> first.  So this was going to hang.  I fixed it doing the lock/unlock
>>> twice.  That is the hack.  I will change the callers once that we decide
>>> what is the right path ahead.  This is not a problem related to vfio. it
>>> is a problem related about how we can stop/resume guests programatically
>>> in the middle of qemu code.
>>>
>> /me nods
>>>> Couldn't we just have an extra patch that just stores pend_pre and 
>>>> pending_size
>>>> in MigrateState, which would allow all this check to be moved into
>>>> migration_completion(). Or maybe that wasn't an option for some other 
>>>> reason?
>>>
>>> This is not an option, because we don't have a way to get back from
>>> migration_completion() to migrate_iteration_run() if there is not enough
>>> space to send all the state.
>>>
>>>> Additionally what about having a migration helper function that
>>>> vfio_save_complete_precopy() callback needs to use into to check if the
>>>> expected-device state size meets the threshold/downtime as it is saving the
>>>> device state and otherwise fail earlier accordingly when saving beyond the
>>>> threshold?
>>>
>>> That is what I tried to do with the code.
>>> See patch 4. ram.c
>>>
>> So what I was saying earlier was to have something like a:
>>
>>      migration_check_pending(ms, device_state_size)
>>
>> Which would call into migration core to check the SLA is still met. But 
>> callable
>> from the client (hw/vfio/migration) as opposed to the core calling into the
>> client. This allows that the client controls when to stop the VF
>>
>> The copy to userspace one could probably be amortized via pread() at
>> at an arbritary offset to read 1 byte, and get an estimate size. Say you 
>> could
>> check that the size is readable with a @threshold_size + 1 offset without
>> necessarily copying the whole thing to userspace. If it reads succesfully it
>> would bailing off earlier (failing the migration) -- and it would avoid doing
>> the full copy to userspace.
>>
>> But the one gotcha is the STOP -> STOP_COPY needs to
>> happen and that is what triggers the transfer the device state into
>> kernel-managed pages before userspace decides to do anything to access/copy 
>> said
>> state.
>>
>>> How I have two functions:
>>> - ram_state_pending_estimate()
>>> - ram_state_pending_exact()
>>>
>>> 1st should work without any locking, i.e. just best estimation without
>>> too much work, second should give the real value.
>>>
>> Right -- I did notice that
>>
>>> What we had discussed before for vfio is that the device will "cache"
>>> the value returned from previous ram_state_pending_exact().
>>>
>>
>> A concern I see is that if we stop and resume the VF on a regular basis to
>> accommodate a calculation just to be made available throughout all migration
>> flow -- it is going to be a little invasive from guest performance/behaviour 
>> PoV?
> 
> It is *kind* of invasive (make things slower), but we already have the
> problem that current code, we are not counting the size of the devices
> state on calculation, and we should.  This adds a hook for all devices
> to include this information.
> 
I think one difference here is that the vmstate is all self-contained in
Qemu/VMM (except for accel-related state obtained from KVM). Here we are making
calls into hardware, stopping the VF, get the state to resume it again.

> I see two options:
> - we stop the guest for the calculations (it makes the last iteration
>   downtime faster), but it makes the rest of the end of iterations
>   slower.  Notice that we should not have so many iterations to start with.
> 
>> Perhaps this check ought to be amortized at different major stage 
>> transitions of
>> migration (as opposed to any iteration) as this can end up happening very 
>> often
>> as soon as non-VFIO state + dirty pages get to a small enough threshold?
> 
> This is the reason why we add the estimate size for the vfio.  if the
> estimate is good enough, we shouldn't stop so many times.
> 
I suppose, yes

>>>> It would allow supporting both the (current UAPI) case where you need to
>>>> transfer the state to get device state size (so checking against 
>>>> threshold_size
>>>> pending_pre constantly would allow to not violate the SLA) as well as any 
>>>> other
>>>> UAPI improvement to fseek()/data_size that lets you fail even earlier.
>>>>
>>>> Seems like at least it keeps some of the rules (both under iothread lock) 
>>>> as
>>>> this patch
>>>
>>> Coming to worse thing, you need to read the state into a local buffer
>>> and then calculate the size in exact?  Looks overkill, but in your case,
>>> I can't see other way to do it.
>>>
>>> My understanding was that for new hardware you have an easy way to
>>> calculate this value "if the guest was stopped".
>>>
>> s/guest/VF
> 
> The use case that I was discussing the whole card was assigned to the
> guest, not a VF.  I have no clue if that makes the problem easier of
> more difficult.
> 
>>> My next series are a way to do in parallel the read/send of the state
>>> with respect to the migration_thread(), but that is a different
>>> problem. 
>>
>> There's also non-blocking reads not sure it helps towards the asynchronous 
>> transfer?
> 
> My current "cunning" plan is to create a new channel for each vfio
> device, hat allow the device to do whatever they want, and using a
> blocking interface.
> 
Looks sensible

>>> I need a way to calculate sizes to start with, 
>>> otherwise  I
>>> have no way to decide if I can enter the completion stage (or for old
>>> devices one can lie and assume than size is zero, 
>>
>> to be fair that's what happens right now with migration v1 protocol -- it's 
>> not
>> unprecedented IIUC
> 
> Ok, thanks for the comments.
> 
Likewise

It would be nice if we could still move forward with v2 support, while newfound
gaps are addressed towards the road of turning it into a non experimental
feature. It would allow exercising a lot of the new interface, as the ecosystem
is a bit limiting :(