qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] xen: make xen-platform a default device


From: Stefano Stabellini
Subject: Re: [Qemu-devel] [PATCH] xen: make xen-platform a default device
Date: Fri, 23 May 2014 15:30:55 +0100
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

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 <address@hidden>
> > 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. 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]