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