On Wed, Nov 23, 2022 at 01:54:50PM +0000, John Levon wrote:
On Wed, Nov 23, 2022 at 01:45:37PM +0000, Daniel P. Berrangé wrote:
> Indeed, the very fact that libvirt exists and is widely used, is what
> allows QEMU to deprecated and rename stuff on a pretty aggressive
> schedule. If libvirt wasn't providing this isolation, then it is
> unlikely QEMU would have adopted its 2 release deprecated cycle,
> and would be locked into their mistakes for a much longer period.
My understanding was that qemu no longer change existing CPU model definitions,
but instead introduce new versions (like IcelakeServer-V6), and that's how they
can make changes as needed. Or are they still arbitrarily changing/breaking
*existing* definitions in incompatible ways?
The existing CPU model versions should not be getting changed
by machine types any more. It hsould be purely additive with
new versions being introduced, at least for x86. Other arches
handle CPUs differently in QEMU :-(
> IOW, libvirt is allowing QEMU to fix their own technical debt on
a
> more aggressive timeframe, albeit at some cost to libvirt maintainers.
I'd be interested in one or two specific examples so I can understand this
properly.
The poster child example of QEMU evolving is the block layer
which has many syntax versions
* -hda / -sda / etc
* -drive if=ide,.....
* -drive if=none,... -device virtio-blk
* -blockdev driver=... -device virtio-blk
* -blockdev json:{...} -device virtio-blk
though at the same time its a bad example, as QEMU has failed to
actually get around to deleting the old syntaxes so far.
There is a quite a long list of things where QEMU has actually
remove the old syntax though:
https://www.qemu.org/docs/master/about/removed-features.html
and libvirt has adapted to a great many of those.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|