Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

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

 



2010/11/29 Paul Brook <paul@xxxxxxxxxxxxxxxx>:
>> >> To answer Stefan's question, there shouldn't be any requirement
>> >> for a device, but must be tested with Kemari.  If it doesn't work
>> >> correctly, the problems must be fixed before adding to the list.
>> >
>> > What exactly are the problems? Is this a device bus of a Kemari bug?
>> > If it's the former then that implies you're imposing additional
>> > requirements that weren't previously part of the API.  If the latter,
>> > then it's a bug like any other.
>>
>> It's a problem if devices don't continue correctly upon failover.
>> I would say it's a bug of live migration (not all of course)
>> because Kemari is just live migrating at specific points.
>
> Ah, now we're getting somewhere.  So you're saying that these devices are
> broken anyway, and Kemari happens to trigger that brokenness more frequently?
>
> If the requirement is that a device must support live migration, then that
> should be the criteria for enabling Kemari, not some arbitrary whitelist.

Sorry, I though that criteria to be obvious one and didn't think
to clarify.  The whitelist is a guard not to let users get into
trouble with arbitrary devices.

> If devices incorrectly claim support for live migration, then that should also
> be fixed, either by removing the broken code or by making it work.

I totally agree with you.

> AFAICT your current proposal is just feeding back the results of some fairly
> specific QA testing.  I'd rather not get into that game.  The correct response
> in the context of upstream development is to file a bug and/or fix the code.
> We already have config files that allow third party packagers to remove
> devices they don't want to support.

Sorry, I didn't get what you're trying to tell me.  My plan would
be to initially start from a subset of devices, and gradually
grow the number of devices that Kemari works with.  While this
process, it'll include what you said above, file a but and/or fix
the code.  Am I missing what you're saying?

Yoshi

>
> Paul
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux