Re: [Qemu-devel] [PATCH v2 0/5] q35: Remove old machines and unused compat code

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Feb 04, 2016 at 05:09:44PM -0200, Eduardo Habkost wrote:
> On Thu, Feb 04, 2016 at 08:02:30PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Feb 04, 2016 at 03:16:17PM -0200, Eduardo Habkost wrote:
> > > On Thu, Feb 04, 2016 at 06:01:50PM +0200, Michael S. Tsirkin wrote:
> > > > On Sat, Jan 23, 2016 at 02:02:08PM -0200, Eduardo Habkost wrote:
> > > > > This is another attempt to remove old q35 machine code. Now I am
> > > > > also removing unused compat code to demonstrate the benefit of
> > > > > throwing away the old code that nobody uses.
> > > > 
> > > > The same thing I said applies - we don't know that nobody uses old q35
> > > > machine types.
> > > > We do know we don't need to migrate to/from them,
> > > > so we can drop compat code.
> > > > But please add aliases so people can still start these machines.
> > > 
> > > If people use them, they can easily update their configurations.
> > > I will copy and paste the reply Markus sent 4 months ago below.
> > > 
> > > On Mon, Sep 14, 2015 at 09:18:47AM +0200, Markus Armbruster wrote:
> > > > We've been through this before, but we can go through it once more.
> > > > Choices:
> > > > 
> > > > A. Remove old machine type
> > > > 
> > > >    A guest using it can't be started.  Easy to understand on the host.
> > > >    An error message advising to switch to a newer machine type would be
> > > >    a nice touch.
> > > > 
> > > >    This is a clean break in backward compatibility.  To be mentioned in
> > > >    release notes, obviously.
> > > > 
> > > > B. Change old machine type in a guest-visible way
> > > > 
> > > >    Depending on the nature of the change and the guest, a guest using it
> > > >    either doesn't notice, copes with it successfully, or fails in
> > > >    guest-specific ways.  If the latter, the failure can be "guest
> > > >    hangs", which is much harder to figure out than A.
> > > > 
> > > >    Unless we can *demonstrate* that nothing bad happens for all the
> > > >    guests people actually use with the old machine types, this is a
> > > >    different kind of backward compatibility break.
> > > > 
> > > >    Demonstrating this is feels infeasible to me, but you're welcome to
> > > >    try.
> > > > 
> > > > I could call the difference between the two a tradeoff, but since we've
> > > > been through this before, I'll be more blunt: choosing B robs Peter (the
> > > > guy with guests where badness happens) to pay Paul (the guy with guests
> > > > that cope).  Paul is saved the inconvenience of having to read release
> > > > notes or his logs, and change machine types.  Peter pays for that with
> > > > figuring out WTF his guests are doing now.
> > > > 
> > > > As a user, I'd pick a clean break in backward compatibility over a hack
> > > > that preserves effective compatibility when it works, but breaks it
> > > > uncleanly when it doesn't.
> > > > 
> > > > As a developer, I'm insisting on it.
> > > > 
> > > > So, if you want B, the onus is on *you* to show us why nothing bad will
> > > > happen.
> > > > 
> > 
> > I agree with the conclusion for option B.  But I think the correct
> > solution is not A, it is to analyse changes, maybe even test, and show
> > that nothing bad can happen.
> 
> Do you volunteer for that work?

Nope, sorry. It's your idea, your patchset.  I am saying, look for some
low-hanging fruit.  Find some compat options we can drop without
breaking guests, drop just these.  Are there options we need for piix
anyway? No point in dropping them at all.

For example, the builtin AML can be dropped since we
always use a bios with acpi support now.
It is also trivial to test.

Memory layout is probably ok to change.

Maybe more.

> > 
> > Because A suffers from exactly the same problem if people just blindly
> > switch to a new machine type.
> 
> Anything can happen if people change their configurations
> blindly.
> 
> Nobody should change configuration blindly, and that's also why
> we shouldn't run a different machine when the user is asking for
> an old one. We don't know why the user is asking for an old
> machine and we can't make decisions for the user. Management
> software might know why an old machine is being used and might be
> able to help update the config, but QEMU doesn't.

What guidance do we provide? Try it and see if it works?  What exactly
do we ask user to test? If QEMU developers can't find out whether
switching a machine type is safe, what hope is there that management
developers can?

> -- 
> Eduardo