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: Mon, 4 Jun 2018 17:56:37 +0100
User-agent: Mutt/1.9.5 (2018-04-13)

On Mon, Jun 04, 2018 at 07:48:51PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> > On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > > 
> > > > > I440FX is really old and does not support modern features like IOMMU.
> > > > > Q35's SATA emulation is faster than pc's IDE, native PCI express 
> > > > > hotplug
> > > > > is cleaner than ACPI based one and so on...
> > > > > 
> > > > > Also the libvirt guys added very good support for the Q35 machine 
> > > > > (thanks!).
> > > > > 
> > > > > Management software should always specify the machine type and for the
> > > > > current setups, adding '-machine pc' to the command line is not such a
> > > > > big deal.
> > > > > 
> > > > > In time the pc machine will fade out and we will probably stop adding
> > > > > new versions at some point.
> > > > > 
> > > > > Signed-off-by: Marcel Apfelbaum <address@hidden>
> > > > 
> > > > For command line users, I think changing the default isn't nice.
> > > > 
> > > > Yes it's easy to add -machine pc but there's no documentation
> > > > that tells you to do so. Add to that shortcuts like -cdrom
> > > > stop working, hotplug needs extra bridges to work, and one
> > > > can see that while management tool users benefit from q35,
> > > > command line users will suffer.
> > > > 
> > > > Can't we add a tag for management without changing the command line
> > > > default? How about "management-default"? "recommended"? "latest"?
> > > 
> > > We could add new aliases if they are useful for management
> > > software, but we would need a well-defined use case and set of
> > > requirements+expectations for the new alias.
> > 
> > I'm not convinced by the idea of adding a distinct default "for mgmt". All
> > the problems described wrt 'q35' vs 'pc' apply equally to management apps
> > as they do to humans. It just happens that one common mgmt layer (libvirt)
> > knows how to handle some of the complexity of q35. Other mgmt apps though
> > are just as likely to be hurt by the change as humans are. So effectively
> > the proposed "for mgmt" is actually  "for libvirt >= some version", which
> > feels like a layering violation to me.
> 
> Is libvirt happy to just hard-code q35 for now then?

I'm pretty wary of doing that, as I feel 'pc' has broader OS compatibility
than 'q35', so we'd be likely to cause breakage for users.

IMHO, defaults are something better expressed in libosinfo, so if there's
guests where we think q35 is a better choice, we can record it there and
leave everything else on pc to avoid risk of breakage.

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]