On Thu, Feb 11, 2016 at 06:33:14PM +0200, Michael S. Tsirkin wrote: > 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.
Really? Who is "we"? I believe some vendors support changing the machine-type when necessary. I'm sure most OSes are capable of handling a hardware upgrade. > > > 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? Because (AFAICS) most developers involved in that code don't want to waste time supporting it, and we already provide better alternatives. > > > > > > > > > > > > > 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. Testing and reviewing code is costly. > > > 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? The fact that nobody declared it as fully supported. -- Eduardo
