From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cole Robinson Subject: Re: [PATCH 0/3] VFIO-based PCI device assignment for QEMU 1.2 Date: Tue, 14 Aug 2012 10:53:29 -0400 Message-ID: <502A6669.90200@redhat.com> References: <20120801050241.22163.78549.stgit@bling.home> <87pq6uvs52.fsf@codemonkey.ws> <502907EA.9030606@redhat.com> <5029097B.8050706@siemens.com> <87393qmvwe.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Avi Kivity , Alex Williamson , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "aik@ozlabs.ru" , Benjamin Herrenschmidt , Alex Graf To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55420 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911Ab2HNOxo (ORCPT ); Tue, 14 Aug 2012 10:53:44 -0400 In-Reply-To: <87393qmvwe.fsf@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 08/13/2012 03:31 PM, Anthony Liguori wrote: > Jan Kiszka 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? > > 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? > Speaking as a Fedora maintainer, compatibility with old kernels isn't that important to us, provided the functionality of the new way is comparable to the old way. As far as switching over to qemu.git, I assume there will eventually be a day when the fork would 'end' and qemu-kvm would stop getting its own releases, which is when we'd switch. Maybe that assumption is wrong or over simplifying the trade offs, but if merge work is ongoing I don't see a very compelling reason to switch. - Cole