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

[Eduardo Habkost]

On Fri, Feb 05, 2016 at 12:14:16AM +0200, Michael S. Tsirkin wrote:
> 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.

It's your idea. You are the one proposing to waste resources
keeping an old machine-type name "working" just because you don't
want users (who we don't even know if they actually exist) to
update their configurations on a QEMU upgrade.

I am proposing the opposite: dropping support to a feature that
people are unlikely to be using, in a very clear way.


> 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?

Exactly the same guidance vendors already provide for people that
want to change machine types today. It depends on who wrote the
config files and why, and we can't and shouldn't make any
guesses.

-- 
Eduardo