Re: [libvirt] [PATCH 00/20] 20 crazy IVSHMEM patches you won't believe compile

On Fri, Sep 16, 2016 at 02:22:19PM +0200, Peter Krempa wrote: >On Thu, Sep 15, 2016 at 18:14:25 +0200, Martin Kletzander wrote: >> Let's see if the subject works if one is in need of reviews =) >> >> Yet another qemu device, right? We even have an existing device for >> that, right? That should be pretty straight-forward and easy, right? >> Well, let's see... I, at least, tried splitting the patches for you >> to be as easy to review as possible. >> >> Just in case you're trying out the hot-(un)plug on an upstream QEMU, >> make sure you do it on i440fx machine, not on q35 one, otherwise it >> will not work nicely (or rather at all). >> >> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1347049 > >Few notes to add to the craziness: > >1) According to the qemu documentation the old 'ivshmem' device is >deprecated and should not be used and should be sensibly replaced with >the new devices relevant to the configuration. This is not happening in >this series so the above mentioned bugzilla is actually not resolved by >this series. > It should be used, but it's not the same thing. The only thing ivshmem and ivshmem-(plain|doorbell) have in common is the Guest ABI.

>2) If we are going to allow migration for the few certain configs that >should work you'll need to add migration flags to support this. The need >comes from the fact that previously we did not parse the model and thus >you will either need to convert previously working configs to the old >device or just to forbid the new definitions. > Sure, I'll add the flag and just forbid it. >3) Adding support for the 'role' stuff for the legacy code will add more >fun into making point 2 properly. > Old will just not be able to migrate, ever. Nobody wants to support that.