RE: KVM Call for 2022-10-18

[Shameerali Kolothum Thodi]

> -----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 <kvm@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.
>