On Fri, Jun 30, 2017 at 03:57:23PM +0200, Max Reitz wrote:
> On 2017-06-30 15:05, Eric Blake wrote:
> > On 06/30/2017 07:33 AM, Max Reitz wrote:
> >
> >>> The assertion is caused by migrate_add_blocker() called before
> >>> initialization of migration object. I'll fix it.
> >>
> >> Thanks!
On 2017-06-30 15:05, Eric Blake wrote:
> On 06/30/2017 07:33 AM, Max Reitz wrote:
>
>>> The assertion is caused by migrate_add_blocker() called before
>>> initialization of migration object. I'll fix it.
>>
>> Thanks!
>>
>>> But even with a fix (so I can pass 055 now), I still cannot pass some
On 06/30/2017 07:33 AM, Max Reitz wrote:
>> The assertion is caused by migrate_add_blocker() called before
>> initialization of migration object. I'll fix it.
>
> Thanks!
>
>> But even with a fix (so I can pass 055 now), I still cannot pass some
>> of the other tests. Errors I got:
>>
>>
On 2017-06-30 09:11, Peter Xu wrote:
> On Fri, Jun 30, 2017 at 11:03:21AM +0800, Peter Xu wrote:
>> On Fri, Jun 30, 2017 at 04:18:56AM +0200, Max Reitz wrote:
>>> On 2017-06-27 06:10, Peter Xu wrote:
Let the old man "MigrationState" join the object family. Direct benefit
is that we can
On Fri, Jun 30, 2017 at 11:03:21AM +0800, Peter Xu wrote:
> On Fri, Jun 30, 2017 at 04:18:56AM +0200, Max Reitz wrote:
> > On 2017-06-27 06:10, Peter Xu wrote:
> > > Let the old man "MigrationState" join the object family. Direct benefit
> > > is that we can start to use all the property features
On Fri, Jun 30, 2017 at 04:18:56AM +0200, Max Reitz wrote:
> On 2017-06-27 06:10, Peter Xu wrote:
> > Let the old man "MigrationState" join the object family. Direct benefit
> > is that we can start to use all the property features derived from
> > current QDev, like: HW_COMPAT_* bits, command
On 2017-06-27 06:10, Peter Xu wrote:
> Let the old man "MigrationState" join the object family. Direct benefit
> is that we can start to use all the property features derived from
> current QDev, like: HW_COMPAT_* bits, command line setup for migration
> parameters (so will never need to set them
On Tue, Jun 27, 2017 at 11:47:18AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 27, 2017 at 12:10:13PM +0800, Peter Xu wrote:
> [...]
> > +
> > +static const TypeInfo migration_type = {
> > +.name = TYPE_MIGRATION,
> > +.parent = TYPE_DEVICE,
>
> As TYPE_MIGRATION isn't really a device and
On Tue, Jun 27, 2017 at 12:10:13PM +0800, Peter Xu wrote:
> Let the old man "MigrationState" join the object family. Direct benefit
> is that we can start to use all the property features derived from
> current QDev, like: HW_COMPAT_* bits, command line setup for migration
> parameters (so will
On Tue, Jun 27, 2017 at 12:10:13PM +0800, Peter Xu wrote:
[...]
> +
> +static const TypeInfo migration_type = {
> +.name = TYPE_MIGRATION,
> +.parent = TYPE_DEVICE,
As TYPE_MIGRATION isn't really a device and we're using TYPE_DEVICE just
to reuse the global property system, maybe we
Let the old man "MigrationState" join the object family. Direct benefit
is that we can start to use all the property features derived from
current QDev, like: HW_COMPAT_* bits, command line setup for migration
parameters (so will never need to set them up each time using HMP/QMP,
this is really,
11 matches
Mail list logo
