qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine
Date: Thu, 21 Jun 2018 08:39:02 +0100
User-agent: Mutt/1.9.5 (2018-04-13)

On Wed, Jun 20, 2018 at 02:28:24PM -0300, Eduardo Habkost wrote:
> On Mon, Jun 18, 2018 at 08:18:16PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 18, 2018 at 02:14:31PM -0300, Eduardo Habkost wrote:
> > > > Sure if someone does that, we'll have no choice, but as long as 'pc' is
> > > > shipped we shouldn't gratuitously break apps by changing the default.
> > > 
> > > Right.  I just want to make sure "omitting the machine-type may
> > > stop working in the future" is documented somehow.
> > 
> > I still think we should just add links to the qemu binary and
> > use ARGV to detect the machine type.
> > 
> > qemu-pc-i386
> > qemu-q35-x86_64
> 
> Why having separate QEMU binaries would help?  We still need to
> define and document what will happen when both the machine-type
> and the QEMU binary are omitted in the domain XML.

It would not help libvirt at all, and in fact it would cause extra pain
for applications, because we don't have ability to associated separate
QEMU binaries with machine types in our capabilities design. So not
only would libvirt need changing, but apps using libvirt too.

> Personally I prefer to document this as "we recommend you always
> specify the machine-type" instead of "we recommend you always
> specify the QEMU binary path".

Indeed, the former is something apps already do in many cases.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

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