qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v2 0/5] q35: Remove old machines and unused compat code
Date: Sun, 7 Feb 2016 12:17:53 +0200

On Fri, Feb 05, 2016 at 09:55:08AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" <address@hidden> writes:
> 
> > 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.
> 
> What exactly are you proposing to do?

I'm not sure. But if someone says "we drop machine X, people can use
machine Y instead" then clearly, there should be some data
included about how well does Y function in place of X:
based on code analysis, testing, or both.


Some ideas for things that seem rather safe based on code analysis:

1. We should be able to explicitly disable migration for old machine
types that could not migrate historically so users don't try to migrate
them now that they can.

2. Drop stuff that isn't guest OS visible, that we
keep around for migration or old bios support.
has_acpi_build - old bios support will allow removing the dsdt AML.
option_rom_has_mr - not guest visible.


Nothing is 100% safe - e.g. people that use their own bios will get
bitten by removal of AML.


>  Who should be doing it?

Whoever's interested.

>  And what
>  other work are you willing to sacrifice to get this task done?

I don't much care about getting this done - most stuff has to
be there for piix anyway.

> > Because A suffers from exactly the same problem if people just blindly
> > switch to a new machine type.
> 
> PEBKAC
> 
> Users switch machine types for any number of reasons, good and bad.  You
> can't stop the ones switching for bad reasons by keeping some barely
> working machine type around forever.

If you tell people to switch to a new machine type, then switching is
not PEBKAC and you need a tested migration path that does not involve
reinstalling the gust OS for most users.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]