> -----Original Message-----
> From: Qemu-devel
> [mailto:qemu-devel-bounces+shameerali.kolothum.thodi=huawei.com@nong
> nu.org] On Behalf Of Juan Quintela
> Sent: 14 October 2022 11:11
> To: kvm-devel <k...@vger.kernel.org>; qemu-devel@nongnu.org
> Subject: KVM Call for 2022-10-18
>
>
>
> Hi
>
> Please, send any topic that you are interested in covering.
>
> For next week, we have a topic:
>
> - VFIO and migration
>
> We are going to discuss what to do with vfio devices that support
> migration. See my RFC on the list, so far we are discussing:
>
> - we need a way to know the size of the vfio device state
> (In the cases we are discussing, they require that the guest is
> stopped, so I am redoing how we calculate pending state).
>
> - We need an estimate/exact sizes.
> Estimate can be the one calculated last time. This is supposed to be
> fast, and needs to work with the guest running.
> Exact size is just that, we have stopped the guest, and we want to
> know how big is the state for this device, to know if we can complete
> migration ore we will continue in iterative stage.
>
> - We need to send the state asynchronously.
> VFIO devices are very fast at doing whatever they are designed to do.
> But copying its state to memory is not one of the things that they do
> fast. So I am working in an asynchronous way to copy that state in
> parallel. The particular setup that caused this problem was using 4
> network vfio cards in the guest. Current code will:
>
> for i in network cards:
> copy the state from card i into memory
> send the state from memory from card i to destination
>
> what we want is something like:
>
> for i in network cards:
> start asyrchronous copy the state from card i into memory
>
> for i in network cards:
> wait for copy the state from card i into memory to finish
> send the state from memory from card i to destination
>
> So the cards can tranfer its state to memory in parallel.
>
>
> At the end of Monday I will send an email with the agenda or the
> cancellation of the call, so hurry up.
>
> After discussions on the QEMU Summit, we are going to have always open a
> KVM call where you can add topics.
>
> Call details:
>
> By popular demand, a google calendar public entry with it
>
>
> https://calendar.google.com/calendar/u/0?cid=ZWdlZDdja2kwNWxtdTF0bm
> d2a2wzdGhpZHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
>
> (Let me know if you have any problems with the calendar entry. I just
> gave up about getting right at the same time CEST, CET, EDT and DST).
Hi,
Just wondering did this call happen? Tried joining in as it was showing
14:00-15:00 in my google calendar(BST), but no luck.
Thanks,
Shameer
>
> If you need phone number details, contact me privately
>
> Thanks, Juan.
>
