From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucas Meneghel Rodrigues Subject: Re: qemu-kvm: remove "boot=on|off" drive parameter compatibility Date: Wed, 03 Oct 2012 07:57:33 -0300 Message-ID: <506C1A1D.4020209@redhat.com> References: <20120930191146.GA20012@amt.cnet> <50694EC1.8060006@siemens.com> <20121001093102.GA14797@amt.cnet> <50696E9E.7030302@siemens.com> <87zk468h3y.fsf@codemonkey.ws> <506999ED.6010409@siemens.com> <20121003095532.GO23096@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm , Scott Moser , Jan Kiszka , Marcelo Tosatti , Michael Tokarev , qemu-devel , Anthony Liguori , Cole Robinson , =?ISO-8859-1?Q?Andreas_F=E4rber?= To: Gleb Natapov Return-path: In-Reply-To: <20121003095532.GO23096@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 10/03/2012 06:55 AM, Gleb Natapov wrote: > On Mon, Oct 01, 2012 at 03:26:05PM +0200, Jan Kiszka wrote: >> On 2012-10-01 15:19, Anthony Liguori wrote: >>> Jan Kiszka writes: >>> >>>> On 2012-10-01 11:31, Marcelo Tosatti wrote: >>>> >>>> It's not just about default configs. We need to validate if the >>>> migration formats are truly compatible (qemu-kvm -> QEMU, the other way >>>> around definitely not). For the command line switches, we could provide >>>> a wrapper script that translates them into upstream format or simply >>>> ignores them. That should be harmless to carry upstream. >>> >>> qemu-kvm has: >>> >>> -no-kvm >>> -no-kvm-irqchip >>> -no-kvm-pit >>> -no-kvm-pit-reinjection >>> -tdf <- does nothing >>> >>> There are replacements for all of the above. If we need to add them to >>> qemu.git, it's not big deal to add them. >> >> But I don't think we should add them to the source code. This can >> perfectly be handled my a (disposable) script layer on top of >> qemu-system-x86_64 - the namespace (qemu-kvm in most cases) is also free. >> >>> >>> -drive ...,boot= <- this is ignored >>> >>> cpu_set command for CPU hotplug which is known broken in qemu-kvm. >> >> Right, so nothing is lost when migrating to QEMU. >> >>> >>> testdev which is nice but only used for development >>> > Jan, do you have a plan for testdev device? It would be a pity to have > qemu-kvm just for that. Yep, I did send patches with the testdev device present on qemu-kvm.git to qemu.git a while ago, but there were many comments on the review, I ended up not implementing everything that was asked and the patches were archived. If nobody wants to step up to port it, I'll re-read the original thread and will spin up new patches (and try to go through the end with it). Executing the KVM unittests is something that we can't afford to lose, so I'd say it's important on this last mile effort to get rid of qemu-kvm. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJMeA-0006L4-9s for qemu-devel@nongnu.org; Wed, 03 Oct 2012 06:57:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJMe4-0005L2-CG for qemu-devel@nongnu.org; Wed, 03 Oct 2012 06:57:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJMe4-0005Ki-3u for qemu-devel@nongnu.org; Wed, 03 Oct 2012 06:57:40 -0400 Message-ID: <506C1A1D.4020209@redhat.com> Date: Wed, 03 Oct 2012 07:57:33 -0300 From: Lucas Meneghel Rodrigues MIME-Version: 1.0 References: <20120930191146.GA20012@amt.cnet> <50694EC1.8060006@siemens.com> <20121001093102.GA14797@amt.cnet> <50696E9E.7030302@siemens.com> <87zk468h3y.fsf@codemonkey.ws> <506999ED.6010409@siemens.com> <20121003095532.GO23096@redhat.com> In-Reply-To: <20121003095532.GO23096@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: kvm , Scott Moser , Jan Kiszka , Marcelo Tosatti , Michael Tokarev , qemu-devel , Anthony Liguori , Cole Robinson , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 10/03/2012 06:55 AM, Gleb Natapov wrote: > On Mon, Oct 01, 2012 at 03:26:05PM +0200, Jan Kiszka wrote: >> On 2012-10-01 15:19, Anthony Liguori wrote: >>> Jan Kiszka writes: >>> >>>> On 2012-10-01 11:31, Marcelo Tosatti wrote: >>>> >>>> It's not just about default configs. We need to validate if the >>>> migration formats are truly compatible (qemu-kvm -> QEMU, the other way >>>> around definitely not). For the command line switches, we could provide >>>> a wrapper script that translates them into upstream format or simply >>>> ignores them. That should be harmless to carry upstream. >>> >>> qemu-kvm has: >>> >>> -no-kvm >>> -no-kvm-irqchip >>> -no-kvm-pit >>> -no-kvm-pit-reinjection >>> -tdf <- does nothing >>> >>> There are replacements for all of the above. If we need to add them to >>> qemu.git, it's not big deal to add them. >> >> But I don't think we should add them to the source code. This can >> perfectly be handled my a (disposable) script layer on top of >> qemu-system-x86_64 - the namespace (qemu-kvm in most cases) is also free. >> >>> >>> -drive ...,boot= <- this is ignored >>> >>> cpu_set command for CPU hotplug which is known broken in qemu-kvm. >> >> Right, so nothing is lost when migrating to QEMU. >> >>> >>> testdev which is nice but only used for development >>> > Jan, do you have a plan for testdev device? It would be a pity to have > qemu-kvm just for that. Yep, I did send patches with the testdev device present on qemu-kvm.git to qemu.git a while ago, but there were many comments on the review, I ended up not implementing everything that was asked and the patches were archived. If nobody wants to step up to port it, I'll re-read the original thread and will spin up new patches (and try to go through the end with it). Executing the KVM unittests is something that we can't afford to lose, so I'd say it's important on this last mile effort to get rid of qemu-kvm.