On 08/13/2012 10:31 PM, Anthony Liguori wrote: > Jan Kiszka <jan.kiszka@xxxxxxxxxxx> writes: > >> On 2012-08-13 15:58, Avi Kivity wrote: >>> On 08/13/2012 04:27 PM, Anthony Liguori wrote: >>> >>>> Thanks for pushing this forward! Hopefully this will finally kill off >>>> qemu-kvm.git for good. >>> >>> No, it won't. vfio requires a 3.6 kernel, which we cannot assume anyone >>> has. We'll need the original device assignment code side-by-side. >> >> ...which is on my to-do list for 1.3. > > Is there a deprecation plan for the old device assignment code? Not yet. I would say 2-3 years from the release that has full support (3.7, since we need more support for INTx in kvm). This feature is user visible, all the way up to scripts and management tools. It's not a plug-in replacement (though I tried). Even with a new kernel, we can't just drop it and point users to vfio. > > I'm not really against the idea of requiring a new kernel for new > features. > > From a Fedora/OpenSUSE point of view, would supporting old kernels be a > requirement to stop shipping qemu-kvm.git over qemu.git? > > Since distros ship new kernels and new userspaces, I don't think distros > would care so I'm not sure who we're trying to support old kernels for. People do all sort of wierd things. qemu and the kernel are not just for fedora/opensuse consumers who have someone to take care of the entire stack for them, when we deprecate an ABI we need to give them plenty of time to adjust. I think this is even more relevant for device assignment which is sometimes used with unusual use cases. -- error compiling committee.c: too many arguments to function -- 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
