KVM Call for 2022-10-18

KVM Call for 2022-10-18

[Juan Quintela]

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=ZWdlZDdja2kwNWxtdTF0bmd2a2wzdGhpZHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

(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).

If you need phone number details,  contact me privately

Thanks, Juan.

RE: KVM Call for 2022-10-18

[Shameerali Kolothum Thodi via]

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