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

[Michael S. Tsirkin]

On Thu, Feb 11, 2016 at 01:51:30PM -0200, Eduardo Habkost wrote:
> On Sat, Feb 06, 2016 at 08:34:07PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Feb 05, 2016 at 12:46:11PM -0200, Eduardo Habkost wrote:
> > > 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.
> > 
> > What will happen with installed VMs? Will they break?
> 
> They won't start unless the QEMU command-line is changed, because
> they are using a feature QEMU won't support anymore. Why is that
> a problem?

We don't support installing one machine type, then switching.
So they won't start unless guest is re-installed.
Not nice.

> Why do you want to waste so much time keeping a feature that
> people are not even supposed to be using?

Why aren't people supposed to use this feature?

> > 
> > > 
> > > > 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.
> > 
> > AFAIK that's basically "don't do it".
> 
> So, are you saying that changing a machine is a risky thing, but
> at the same time you are proposing that QEMU does that silently
> for the user?

We do this all the time. Any change in qemu changes something.
Compatibility is a question of testing.

> Really, just because you believe somebody out there is using an
> experimental machine-type and is too afraid to change to a newer
> one, you want to make QEMU developers waste their time testing
> and maintaing old compat code and old machine-types forever?

What exactly made it experimental?

> -- 
> Eduardo