All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, Programmingkid <programmingkidx@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Phil Dennis-Jordan <lists@philjordan.eu>
Subject: Re: [Qemu-devel] [PATCH] pc: acpi: force FADT rev1 for old i440fx machine types
Date: Fri, 21 Jul 2017 11:16:23 +0100	[thread overview]
Message-ID: <20170721101623.GI17693@redhat.com> (raw)
In-Reply-To: <20170721121048.44d617ea@nial.brq.redhat.com>

On Fri, Jul 21, 2017 at 12:10:48PM +0200, Igor Mammedov wrote:
> On Fri, 21 Jul 2017 10:49:55 +0100
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
> 
> > On Fri, Jul 21, 2017 at 11:32:11AM +0200, Igor Mammedov wrote:
> > > w2k used to boot on QEMU until we bumped revision of FADT to rev3
> > > (commit 77af8a2b hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.)
> > > 
> > > Considering that w2k is ancient and long time EOLed, leave default
> > > rev3 but make pc-i440fx-2.9 and older machine types to force rev1
> > > so old setups won't break (w2k could boot).  
> > 
> > There needs to be a machine type property added to control this
> > feature. When provisioning new VMs, management apps need to be
> > able to set the property explicitly - having them rely on picking
> > particular machine type name+versions is not viable, because
> > downstream vendors replace the machine types with their own
> > names + versions.
> having property doesn't really help here and we don't do it for every
> compat tweak /ex: save_tsc_khz, linuxboot_dma_enabled/.

If those compat tweaks affect compatibility with particular guest
OS then they should definitely be exposed as properties too.

> Management would not benefit much from having property vs machine version
> as it would have to encode somewhere that for w2k it should set
> some machine property or pick a particular machine type.

It *would* be a significant benefit - property names are stable, machine
type versions are not stable becasue downstream vendors change them.

> Also with new machine type deprecation policy we would be able
> easily to phase out rev1 support along with 2.9 machine,
> but if you expose property then removing it would break
> CLI not only for 2.9 but possible later machines if it's set there.

We have the freedom to deprecate properties too if they become a significant
burden.  If removing machine types prevents us running certain guest OS,
because we don't have a property to override, that would be a mark against
removing the machine types at all IMHO. 

> So I'm against adding properties/CLI options for unless we have to in this
> case, and I'm not convinced that w2k deserves it.

w2k is just one OS that we happen to know of that breaks - who knows how
many others suffer the same fate. So making decisions based on whether
you care about a specific OS is flawed IMHO.

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	other threads:[~2017-07-21 10:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21  9:32 [Qemu-devel] [PATCH] pc: acpi: force FADT rev1 for old i440fx machine types Igor Mammedov
2017-07-21  9:49 ` Daniel P. Berrange
2017-07-21 10:10   ` Igor Mammedov
2017-07-21 10:16     ` Daniel P. Berrange [this message]
2017-07-21 23:40     ` Michael S. Tsirkin
2017-07-22  1:42       ` Programmingkid
2017-07-24  6:48       ` Igor Mammedov
2017-07-25 13:26         ` Michael S. Tsirkin
2017-07-26  7:39           ` Ladi Prosek
2017-07-26  7:45             ` Phil Dennis-Jordan
2017-07-21  9:54 ` Ladi Prosek
2017-07-21 10:12   ` Igor Mammedov
2017-07-24 10:07     ` Ladi Prosek
2017-07-21 17:33 ` Programmingkid
2017-07-27 13:01 ` no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170721101623.GI17693@redhat.com \
    --to=berrange@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lists@philjordan.eu \
    --cc=mst@redhat.com \
    --cc=programmingkidx@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.