On Mi, 2017-03-29 at 18:58 +0200, Paolo Bonzini wrote:
>
> On 29/03/2017 18:46, Dr. David Alan Gilbert wrote:
> >> By the way, what about old machine types like "pc-0.10" ? Do we want to
> >> carry them along forever (e.g. since it is not too complicated to
> >> maintain?), or shall we get rid of those one day (e.g. with QEMU 3.0), too?
> > It seems reasonable to slowly deprecate them.
> > I'm just not sure how slowly.
>
> Some data:
>
> - dropping 0.12, 0.13 _and_ isapc would let us kill the code for
> rombar=0 (i.e. where QEMU copies ROM BARs directly to low memory).
>
> - the oldest versions in use are probably 0.12 (CentOS 6) and 1.0
> (Ubuntu 12.04)
>
> - migration from old versions is broken in various ways from at least
> QEMU 1.2 and older.
Maybe it is useful to discuss this more in terms of code we want drop
instead of version numbers ...
So, here is my (x86-centric) wishlist:
* Drop support for isapc (already added that to the wiki a few days
ago). Also isa-* devices where we have pci variants (isa-vga,
isa-cirrus-vga, ne2k_isa).
Any old guests without pci support (such as ms-dos) should be
happy with "pc" having vga and ide ioports on the standard isa
locations for backward compatibility and seabios handing all pci
stuff. Plugging isa devices (soundblaster for example) into "pc"
works too. So I can't see a compelling use case for isapc. IIRC
we even had a release with broken isapc with nobody noticing during
the -rc phase ...
* Drop support for rombar, and also the code for the linear vbe
framebuffer magically showing up at 0xe0000000.
* Drop backward-compatibility with pre-memory-api qemu versions.
I guess the memory api switch is one of the big reasons why live
migration to older versions is broken.
The memory api was merged in 1.0, so the above would imply dropping
support for all pc-0.x machine types and isapc.
The 1.0 release was tagged on Dec 1st 2011, more than five years ago.
cheers,
Gerd
