On Thu, Apr 29, 2021 at 02:03:52PM -0400, Eduardo Habkost wrote:
On Thu, Apr 29, 2021 at 04:52:21PM +0100, Stefan Hajnoczi wrote:
> The scsi=on|off property was deprecated in QEMU 5.0 and can be removed
> completely at this point.
>
> Drop the scsi=on|off option. It was only available on Legacy virtio-blk
> devices. Linux v5.6 already dropped support for it.
>
> Remove the hw_compat_2_4[] property assignment since scsi=on|off no
> longer exists. Old guests with Legacy virtio-blk devices no longer see
> the SCSI host features bit.
>
This means pc-2.4 will now break guest ABI if using virtio-blk
devices, correct?
Yes.
However, this feature was only enabled on Linux hosts, so cross-host OS
migration was always broken and no one noticed. Maybe that configuration
is too niche and QEMU never supported cross-host OS migration, but it
still means that the "pc-2.4" ABI was never solid to begin with :).
> Live migrating old guests from an old QEMU with the SCSI feature bit
> enabled will fail with "Features 0x... unsupported. Allowed features:
> 0x...". We've followed the QEMU deprecation policy so users have been
> warned...
>
Were they really warned, though? People running
"-machine pc-i440fx-2.4" might be completely unaware that it was
silently enabling a deprecated feature.
Can we have this documented in a more explicit way? Maybe just a
comment at hw_compat_2_4 would be enough, to warn people doing
backports and rebases downstream.
Can we make QEMU refuse to start if using pc-2.4 + virtio-blk
together, just to be sure?
An alternative would be keeping the property (and the
hw_compat_2_4 entry) just to keep pc-2.4 working (until pc-2.4 is
deprecated and removed), but refusing to realize the device if
the feature is enabled.
Yes, the least invasive approach is to leave the property in place but
refuse to realize the virtio-blk device when scsi=on. The cost is more
cruft, including a useless scsi=off command-line option that will
continue to show up in libvirt-generated QEMU command-lines.
The cautious approach makes sense to me and I'll send a new revision.
Stefan