[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] virtio-blk: drop deprecated scsi=on|off property
From: |
Eduardo Habkost |
Subject: |
Re: [PATCH] virtio-blk: drop deprecated scsi=on|off property |
Date: |
Tue, 4 May 2021 11:26:23 -0400 |
On Tue, May 04, 2021 at 03:32:55PM +0100, Stefan Hajnoczi wrote:
> 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:
> > > 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?
>
> On second thought, do we really want to break pc-2.4 user's QEMU
> command-lines if they have a virtio-blk device?
It depends which command line you are talking about.
I believe we _must_ break the following:
"-machine pc-i440fx-2.4 -device virtio-blk", and
"-machine pc-i440fx-2.4 -device virtio-blk,scsi=on".
Your patch breaks only the latter.
Your patch also breaks the following:
"-machine pc-i440fx-2.4 -device virtio-blk,scsi=off",
which I don't think we should break.
>
> BTW Peter mentioned libvirt avoids the unnecessary scsi=off:
> https://gitlab.com/libvirt/libvirt/-/commit/ec69f0190be731d12faeac08dbf63325836509a9
>
> Stefan
--
Eduardo