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 :|
next prev parent 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.