From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnqz2-0000s1-0a for qemu-devel@nongnu.org; Fri, 23 May 2014 11:02:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wnqyu-00066t-Hr for qemu-devel@nongnu.org; Fri, 23 May 2014 11:02:07 -0400 Received: from mail-ee0-f54.google.com ([74.125.83.54]:47677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnqyu-00066h-Ct for qemu-devel@nongnu.org; Fri, 23 May 2014 11:02:00 -0400 Received: by mail-ee0-f54.google.com with SMTP id b57so3619112eek.41 for ; Fri, 23 May 2014 08:01:58 -0700 (PDT) Message-ID: <537F62F0.70606@m2r.biz> Date: Fri, 23 May 2014 17:02:08 +0200 From: Fabio Fantoni MIME-Version: 1.0 References: alpine.DEB.2.02.1405231122140.14596@kaball.uk.xensource.com <537F4731.20702@m2r.biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] xen: make xen-platform a default device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Anthony PERARD , xen-devel , "qemu-devel@nongnu.org" Il 23/05/2014 16:30, Stefano Stabellini ha scritto: > On Fri, 23 May 2014, Fabio Fantoni wrote: >>> One issue is that -M pc didn't always work with Xen. Now it does and we >>> are already relying on it in libxl since >>> 2bc047635b51abd41c917aa2b813211ee0de2c38. It is safe because all QEMU >>> releases from 1.6 onward work well with Xen and -M pc. Older QEMU >>> releases are considered ancient and unmaintained. This is what I was >>> referring to in my last reply. I really meant "we should move away from >>> xenfv and use a pc.* machine that does not create xen-platform by >>> default". >>> >>> As you say the other issue is the version of the pc machine, especially >>> in relation to save/restore. However since: >>> >>> commit 2bc047635b51abd41c917aa2b813211ee0de2c38 >>> Author: Anthony PERARD >>> Date: Wed Nov 27 18:21:34 2013 +0000 >>> >>> libxl: Handle xen_platform_pci=0 case with qemu-xen. >>> >>> we are simply calling QEMU with -M pc if xen_platform_pci=0. I think we >>> should change that too and backport the patch to 4.4. pc-i440fx-1.6 >>> seems like a good choice to me. >> Use "-M pc" as default seems a good idea. >> Use specific version maybe too. >> This way the base hardware should stay the same even if updating qemu, is >> right? > Yep > > >> If yes, this should also solve possible problem like windows >> reactivation request for different hardware, right? > Right > > >> How about create also xl parameter to select the "pc" model? > Having a VM config parameter for it is OK. In the past I argued against > relying on such a parameter to solve all compatibility issues with QEMU > because I would like libxl to be able to select the right QEMU machine > automatically, without user intervention. But the option could still be > useful for debugging. > Excellent From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Fantoni Subject: Re: [PATCH] xen: make xen-platform a default device Date: Fri, 23 May 2014 17:02:08 +0200 Message-ID: <537F62F0.70606@m2r.biz> References: alpine.DEB.2.02.1405231122140.14596@kaball.uk.xensource.com <537F4731.20702@m2r.biz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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 To: Stefano Stabellini Cc: Anthony PERARD , xen-devel , "qemu-devel@nongnu.org" List-Id: xen-devel@lists.xenproject.org Il 23/05/2014 16:30, Stefano Stabellini ha scritto: > On Fri, 23 May 2014, Fabio Fantoni wrote: >>> One issue is that -M pc didn't always work with Xen. Now it does and we >>> are already relying on it in libxl since >>> 2bc047635b51abd41c917aa2b813211ee0de2c38. It is safe because all QEMU >>> releases from 1.6 onward work well with Xen and -M pc. Older QEMU >>> releases are considered ancient and unmaintained. This is what I was >>> referring to in my last reply. I really meant "we should move away from >>> xenfv and use a pc.* machine that does not create xen-platform by >>> default". >>> >>> As you say the other issue is the version of the pc machine, especially >>> in relation to save/restore. However since: >>> >>> commit 2bc047635b51abd41c917aa2b813211ee0de2c38 >>> Author: Anthony PERARD >>> Date: Wed Nov 27 18:21:34 2013 +0000 >>> >>> libxl: Handle xen_platform_pci=0 case with qemu-xen. >>> >>> we are simply calling QEMU with -M pc if xen_platform_pci=0. I think we >>> should change that too and backport the patch to 4.4. pc-i440fx-1.6 >>> seems like a good choice to me. >> Use "-M pc" as default seems a good idea. >> Use specific version maybe too. >> This way the base hardware should stay the same even if updating qemu, is >> right? > Yep > > >> If yes, this should also solve possible problem like windows >> reactivation request for different hardware, right? > Right > > >> How about create also xl parameter to select the "pc" model? > Having a VM config parameter for it is OK. In the past I argued against > relying on such a parameter to solve all compatibility issues with QEMU > because I would like libxl to be able to select the right QEMU machine > automatically, without user intervention. But the option could still be > useful for debugging. > Excellent