qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
Date: Mon, 29 Sep 2014 09:02:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Alex Bligh <address@hidden> writes:

[...]
>>> +/* NB cirrus-vga default value is 8MB anyway, save if we
>>> + * monkey patch it to change the default when the qemu-kvm-migration
>>> + * machine parameter is selected
>>> + */
>>> +
>> 
>> This is too hacky for my taste.
>> How about creating a new machine e.g. pc-qemu-kvm-1.0 and in
>> pc_early_init_pci_1_0, changing compat_props for pc-1.0 to point to the
>> compat_props of pc-qemu-kvm-1.0?
>
> Hang on a second! v2 of this patch DID use a new virtual machine,
> called exactly that. I thought you were objecting to that and
> wanting a machine parameter instead! It's far easier with a new
> machine type, and I'd far prefer a new machine type.
>
> If you were just objecting to the fact that pc-1.0 was made to
> be an alias of either one or the other at compile time, simply
> drop the second patch of the v2 patchset.
>
> If we have a new machine type, I don't /think/ I need the early_init
> thing at all (I may be wrong about that).

I also prefer a new machine type.

Ideally, the management application understands that there are two
incompatibile versions QEMU (upstream and old qemu-kvm), and how to map
their machine types to current QEMU's.

If that's not practical, then downstream can still alias the machine
types around to make things just work in the most important downstream
scenarios.  The most important upstream scenario is QEMU <-> QEMU, of
course.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]