On Sun, Oct 05, 2014 at 08:26:45AM -0400, Paolo Bonzini wrote:
> > > > 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.
> > >
> > > I was objecting to making pc-1.
> > > 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.
> >
> > I was objecting to making pc-1.0 special. There's nothing special in
> > pc-1.0, other machine types al
On 5 Oct 2014, at 08:00, Paolo Bonzini wrote:
> Il 29/09/2014 09:02, Markus Armbruster ha scritto:
>>> 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.
>
> I was object
Michael,
I'm about to post a nice simple v5 of this, but there are a couple of
your comments I am NOT addressing:
>>
>> diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
>> index b72b34e..3c9da23 100644
>> --- a/hw/acpi/piix4.c
>> +++ b/hw/acpi/piix4.c
>> @@ -200,12 +200,26 @@ static const VMStateD
Quoting Alex Bligh (a...@alex.org.uk):
>
> On 29 Sep 2014, at 11:08, Michael S. Tsirkin wrote:
>
> > On Sun, Sep 28, 2014 at 09:33:08PM +0100, Alex Bligh wrote:
> >> Hang on a second! v2 of this patch DID use a new virtual machine,
> >> called exactly that. I thought you were objecting to that a
On 29 Sep 2014, at 11:08, Michael S. Tsirkin wrote:
> On Sun, Sep 28, 2014 at 09:33:08PM +0100, Alex Bligh wrote:
>> 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
On Sun, Sep 28, 2014 at 09:33:08PM +0100, Alex Bligh wrote:
> 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
Alex Bligh 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-
Michael,
>> +static const VMStateDescription vmstate_acpi_compat = {
>> +.name = "piix4_pm",
>> +.version_id = 3,
>> +.minimum_version_id = 2,
>> +.minimum_version_id_old = 1,
>> +.load_state_old = NULL, /* to avoid recursion */
>> +.post_load = vmstate_acpi_post_load,
>> +
* Michael Tokarev (m...@tls.msk.ru) wrote:
> 22.09.2014 23:34, Alex Bligh wrote:
> > This patch series adds inbound migrate capability from qemu-kvm version
> > 1.0. [...]
>
> Isn't it quite a bit too late already? That's an old version by
> now, and supporting migration from it is interesting fo
22.09.2014 23:34, Alex Bligh wrote:
> This patch series adds inbound migrate capability from qemu-kvm version
> 1.0. [...]
Isn't it quite a bit too late already? That's an old version by
now, and supporting migration from it is interesting for long-term
support distributions - like redhat for exa
Markus,
On 24 Sep 2014, at 09:05, Markus Armbruster wrote:
> Alex Bligh writes:
>
>> This patch series adds inbound migrate capability from qemu-kvm version
>> 1.0. The main ideas are those set out in Cole Robinson's patch here:
>> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migr
Alex Bligh writes:
> This patch series adds inbound migrate capability from qemu-kvm version
> 1.0. The main ideas are those set out in Cole Robinson's patch here:
> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
> however, rather than patching stati
13 matches
Mail list logo
