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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 16, 2016 at 04:20:55PM +0200, Peter Krempa wrote:
On Fri, Sep 16, 2016 at 15:17:34 +0200, Martin Kletzander wrote:
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.

Okay than that fact is not clearly stated in this series and nor in the
qemu documentation. Please add docs that explain which device is
necessary in which case and what are the limits.

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

^^ this is bs, I don't know where I got that from, my mistake, sorry.


If migration with the old device won't ever work shouldn't we just use
the same config and internally deal with the differences rather than
exposing the different device types?


I forgot the old one is actually able to migrate currently.  I wanted to
have the models hidden and just keep exposing the same device, but I
just remembered that the reason for me not to do that was due to the old
device being migrated.

But one idea comes to my mind.  We could add a migration cookie flag
that will be set if source is using the new ivshmem-*.  Then we could
effectively forbid migrating the old device.  Newer libvirt on the
source would do that automatically, for old libvirt on the source it
would be checked for on destination.

That could actually work.  I still haven't thought of all the scenarios,
I need to get some caffeine into my veins for that, but that could
actually solve a bunch of problems.  It would also mean getting back
like three non-posted versions of this series :'(

Martin

Peter

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]