docs/specs/tpm.rst | 2 +- docs/system/deprecated.rst | 13 --- docs/pci_expander_bridge.txt | 2 +- hw/block/virtio-blk.c | 192 +---------------------------------- hw/core/machine.c | 2 - 5 files changed, 3 insertions(+), 208 deletions(-)
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.
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...
I have tested that libvirt still works when the property is absent. It
no longer adds scsi=on|off to the command-line.
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Peter Krempa <pkrempa@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
docs/specs/tpm.rst | 2 +-
docs/system/deprecated.rst | 13 ---
docs/pci_expander_bridge.txt | 2 +-
hw/block/virtio-blk.c | 192 +----------------------------------
hw/core/machine.c | 2 -
5 files changed, 3 insertions(+), 208 deletions(-)
diff --git a/docs/specs/tpm.rst b/docs/specs/tpm.rst
index 3be190343a..0ec017ab95 100644
--- a/docs/specs/tpm.rst
+++ b/docs/specs/tpm.rst
@@ -328,7 +328,7 @@ In case a pSeries machine is emulated, use the following command line:
-tpmdev emulator,id=tpm0,chardev=chrtpm \
-device tpm-spapr,tpmdev=tpm0 \
-device spapr-vscsi,id=scsi0,reg=0x00002000 \
- -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0 \
+ -device virtio-blk-pci,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0 \
-drive file=test.img,format=raw,if=none,id=drive-virtio-disk0
In case an Arm virt machine is emulated, use the following command line:
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 80cae86252..1abb64b669 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -248,19 +248,6 @@ machines have been renamed ``raspi2b`` and ``raspi3b``.
Device options
--------------
-Emulated device options
-'''''''''''''''''''''''
-
-``-device virtio-blk,scsi=on|off`` (since 5.0.0)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature. VIRTIO 1.0
-and later do not support it because the virtio-scsi device was introduced for
-full SCSI support. Use virtio-scsi instead when SCSI passthrough is required.
-
-Note this also applies to ``-device virtio-blk-pci,scsi=on|off``, which is an
-alias.
-
Block device options
''''''''''''''''''''
diff --git a/docs/pci_expander_bridge.txt b/docs/pci_expander_bridge.txt
index 36750273bb..540191f5e0 100644
--- a/docs/pci_expander_bridge.txt
+++ b/docs/pci_expander_bridge.txt
@@ -25,7 +25,7 @@ A detailed command line would be:
-object memory-backend-ram,size=1024M,policy=bind,host-nodes=1,id=ram-node1 -numa node,nodeid=1,cpus=1,memdev=ram-node1
-device pxb,id=bridge1,bus=pci.0,numa_node=1,bus_nr=4 -netdev user,id=nd -device e1000,bus=bridge1,addr=0x4,netdev=nd
-device pxb,id=bridge2,bus=pci.0,numa_node=0,bus_nr=8 -device e1000,bus=bridge2,addr=0x3
--device pxb,id=bridge3,bus=pci.0,bus_nr=40 -drive if=none,id=drive0,file=[img] -device virtio-blk-pci,drive=drive0,scsi=off,bus=bridge3,addr=1
+-device pxb,id=bridge3,bus=pci.0,bus_nr=40 -drive if=none,id=drive0,file=[img] -device virtio-blk-pci,drive=drive0,bus=bridge3,addr=1
Here you have:
- 2 NUMA nodes for the guest, 0 and 1. (both mapped to the same NUMA node in host, but you can and should put it in different host NUMA nodes)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index d28979efb8..5023e046fc 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -25,10 +25,6 @@
#include "sysemu/runstate.h"
#include "hw/virtio/virtio-blk.h"
#include "dataplane/virtio-blk.h"
-#include "scsi/constants.h"
-#ifdef __linux__
-# include <scsi/sg.h>
-#endif
#include "hw/virtio/virtio-bus.h"
#include "migration/qemu-file-types.h"
#include "hw/virtio/virtio-access.h"
@@ -200,59 +196,6 @@ out:
aio_context_release(blk_get_aio_context(s->conf.conf.blk));
}
-#ifdef __linux__
-
-typedef struct {
- VirtIOBlockReq *req;
- struct sg_io_hdr hdr;
-} VirtIOBlockIoctlReq;
-
-static void virtio_blk_ioctl_complete(void *opaque, int status)
-{
- VirtIOBlockIoctlReq *ioctl_req = opaque;
- VirtIOBlockReq *req = ioctl_req->req;
- VirtIOBlock *s = req->dev;
- VirtIODevice *vdev = VIRTIO_DEVICE(s);
- struct virtio_scsi_inhdr *scsi;
- struct sg_io_hdr *hdr;
-
- scsi = (void *)req->elem.in_sg[req->elem.in_num - 2].iov_base;
-
- if (status) {
- status = VIRTIO_BLK_S_UNSUPP;
- virtio_stl_p(vdev, &scsi->errors, 255);
- goto out;
- }
-
- hdr = &ioctl_req->hdr;
- /*
- * From SCSI-Generic-HOWTO: "Some lower level drivers (e.g. ide-scsi)
- * clear the masked_status field [hence status gets cleared too, see
- * block/scsi_ioctl.c] even when a CHECK_CONDITION or COMMAND_TERMINATED
- * status has occurred. However they do set DRIVER_SENSE in driver_status
- * field. Also a (sb_len_wr > 0) indicates there is a sense buffer.
- */
- if (hdr->status == 0 && hdr->sb_len_wr > 0) {
- hdr->status = CHECK_CONDITION;
- }
-
- virtio_stl_p(vdev, &scsi->errors,
- hdr->status | (hdr->msg_status << 8) |
- (hdr->host_status << 16) | (hdr->driver_status << 24));
- virtio_stl_p(vdev, &scsi->residual, hdr->resid);
- virtio_stl_p(vdev, &scsi->sense_len, hdr->sb_len_wr);
- virtio_stl_p(vdev, &scsi->data_len, hdr->dxfer_len);
-
-out:
- aio_context_acquire(blk_get_aio_context(s->conf.conf.blk));
- virtio_blk_req_complete(req, status);
- virtio_blk_free_request(req);
- aio_context_release(blk_get_aio_context(s->conf.conf.blk));
- g_free(ioctl_req);
-}
-
-#endif
-
static VirtIOBlockReq *virtio_blk_get_request(VirtIOBlock *s, VirtQueue *vq)
{
VirtIOBlockReq *req = virtqueue_pop(vq, sizeof(VirtIOBlockReq));
@@ -263,126 +206,6 @@ static VirtIOBlockReq *virtio_blk_get_request(VirtIOBlock *s, VirtQueue *vq)
return req;
}
-static int virtio_blk_handle_scsi_req(VirtIOBlockReq *req)
-{
- int status = VIRTIO_BLK_S_OK;
- struct virtio_scsi_inhdr *scsi = NULL;
- VirtIOBlock *blk = req->dev;
- VirtIODevice *vdev = VIRTIO_DEVICE(blk);
- VirtQueueElement *elem = &req->elem;
-
-#ifdef __linux__
- int i;
- VirtIOBlockIoctlReq *ioctl_req;
- BlockAIOCB *acb;
-#endif
-
- /*
- * We require at least one output segment each for the virtio_blk_outhdr
- * and the SCSI command block.
- *
- * We also at least require the virtio_blk_inhdr, the virtio_scsi_inhdr
- * and the sense buffer pointer in the input segments.
- */
- if (elem->out_num < 2 || elem->in_num < 3) {
- status = VIRTIO_BLK_S_IOERR;
- goto fail;
- }
-
- /*
- * The scsi inhdr is placed in the second-to-last input segment, just
- * before the regular inhdr.
- */
- scsi = (void *)elem->in_sg[elem->in_num - 2].iov_base;
-
- if (!virtio_has_feature(blk->host_features, VIRTIO_BLK_F_SCSI)) {
- status = VIRTIO_BLK_S_UNSUPP;
- goto fail;
- }
-
- /*
- * No support for bidirection commands yet.
- */
- if (elem->out_num > 2 && elem->in_num > 3) {
- status = VIRTIO_BLK_S_UNSUPP;
- goto fail;
- }
-
-#ifdef __linux__
- ioctl_req = g_new0(VirtIOBlockIoctlReq, 1);
- ioctl_req->req = req;
- ioctl_req->hdr.interface_id = 'S';
- ioctl_req->hdr.cmd_len = elem->out_sg[1].iov_len;
- ioctl_req->hdr.cmdp = elem->out_sg[1].iov_base;
- ioctl_req->hdr.dxfer_len = 0;
-
- if (elem->out_num > 2) {
- /*
- * If there are more than the minimally required 2 output segments
- * there is write payload starting from the third iovec.
- */
- ioctl_req->hdr.dxfer_direction = SG_DXFER_TO_DEV;
- ioctl_req->hdr.iovec_count = elem->out_num - 2;
-
- for (i = 0; i < ioctl_req->hdr.iovec_count; i++) {
- ioctl_req->hdr.dxfer_len += elem->out_sg[i + 2].iov_len;
- }
-
- ioctl_req->hdr.dxferp = elem->out_sg + 2;
-
- } else if (elem->in_num > 3) {
- /*
- * If we have more than 3 input segments the guest wants to actually
- * read data.
- */
- ioctl_req->hdr.dxfer_direction = SG_DXFER_FROM_DEV;
- ioctl_req->hdr.iovec_count = elem->in_num - 3;
- for (i = 0; i < ioctl_req->hdr.iovec_count; i++) {
- ioctl_req->hdr.dxfer_len += elem->in_sg[i].iov_len;
- }
-
- ioctl_req->hdr.dxferp = elem->in_sg;
- } else {
- /*
- * Some SCSI commands don't actually transfer any data.
- */
- ioctl_req->hdr.dxfer_direction = SG_DXFER_NONE;
- }
-
- ioctl_req->hdr.sbp = elem->in_sg[elem->in_num - 3].iov_base;
- ioctl_req->hdr.mx_sb_len = elem->in_sg[elem->in_num - 3].iov_len;
-
- acb = blk_aio_ioctl(blk->blk, SG_IO, &ioctl_req->hdr,
- virtio_blk_ioctl_complete, ioctl_req);
- if (!acb) {
- g_free(ioctl_req);
- status = VIRTIO_BLK_S_UNSUPP;
- goto fail;
- }
- return -EINPROGRESS;
-#else
- abort();
-#endif
-
-fail:
- /* Just put anything nonzero so that the ioctl fails in the guest. */
- if (scsi) {
- virtio_stl_p(vdev, &scsi->errors, 255);
- }
- return status;
-}
-
-static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
-{
- int status;
-
- status = virtio_blk_handle_scsi_req(req);
- if (status != -EINPROGRESS) {
- virtio_blk_req_complete(req, status);
- virtio_blk_free_request(req);
- }
-}
-
static inline void submit_requests(BlockBackend *blk, MultiReqBuffer *mrb,
int start, int num_reqs, int niov)
{
@@ -699,9 +522,6 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
case VIRTIO_BLK_T_FLUSH:
virtio_blk_handle_flush(req, mrb);
break;
- case VIRTIO_BLK_T_SCSI_CMD:
- virtio_blk_handle_scsi(req);
- break;
case VIRTIO_BLK_T_GET_ID:
{
/*
@@ -1010,14 +830,8 @@ static uint64_t virtio_blk_get_features(VirtIODevice *vdev, uint64_t features,
virtio_add_feature(&features, VIRTIO_BLK_F_GEOMETRY);
virtio_add_feature(&features, VIRTIO_BLK_F_TOPOLOGY);
virtio_add_feature(&features, VIRTIO_BLK_F_BLK_SIZE);
- if (virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
- if (virtio_has_feature(s->host_features, VIRTIO_BLK_F_SCSI)) {
- error_setg(errp, "Please set scsi=off for virtio-blk devices in order to use virtio 1.0");
- return 0;
- }
- } else {
+ if (!virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
virtio_clear_feature(&features, VIRTIO_F_ANY_LAYOUT);
- virtio_add_feature(&features, VIRTIO_BLK_F_SCSI);
}
if (blk_enable_write_cache(s->blk) ||
@@ -1289,10 +1103,6 @@ static Property virtio_blk_properties[] = {
DEFINE_PROP_STRING("serial", VirtIOBlock, conf.serial),
DEFINE_PROP_BIT64("config-wce", VirtIOBlock, host_features,
VIRTIO_BLK_F_CONFIG_WCE, true),
-#ifdef __linux__
- DEFINE_PROP_BIT64("scsi", VirtIOBlock, host_features,
- VIRTIO_BLK_F_SCSI, false),
-#endif
DEFINE_PROP_BIT("request-merging", VirtIOBlock, conf.request_merging, 0,
true),
DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues,
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 40def78183..286f18ec6d 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -194,8 +194,6 @@ GlobalProperty hw_compat_2_5[] = {
const size_t hw_compat_2_5_len = G_N_ELEMENTS(hw_compat_2_5);
GlobalProperty hw_compat_2_4[] = {
- /* Optional because the 'scsi' property is Linux-only */
- { "virtio-blk-device", "scsi", "true", .optional = true },
{ "e1000", "extra_mac_registers", "off" },
{ "virtio-pci", "x-disable-pcie", "on" },
{ "virtio-pci", "migrate-extra", "off" },
--
2.30.2
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?
This looks like a sign we should have deprecated pc-2.4 a long
time ago.
> 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.
> I have tested that libvirt still works when the property is absent. It
> no longer adds scsi=on|off to the command-line.
>
> Cc: Markus Armbruster <armbru@redhat.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Peter Krempa <pkrempa@redhat.com>
> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
[...]
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 40def78183..286f18ec6d 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -194,8 +194,6 @@ GlobalProperty hw_compat_2_5[] = {
> const size_t hw_compat_2_5_len = G_N_ELEMENTS(hw_compat_2_5);
>
> GlobalProperty hw_compat_2_4[] = {
> - /* Optional because the 'scsi' property is Linux-only */
> - { "virtio-blk-device", "scsi", "true", .optional = true },
> { "e1000", "extra_mac_registers", "off" },
> { "virtio-pci", "x-disable-pcie", "on" },
> { "virtio-pci", "migrate-extra", "off" },
--
Eduardo
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
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? BTW Peter mentioned libvirt avoids the unnecessary scsi=off: https://gitlab.com/libvirt/libvirt/-/commit/ec69f0190be731d12faeac08dbf63325836509a9 Stefan
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
Eduardo Habkost <ehabkost@redhat.com> writes: > 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? > > This looks like a sign we should have deprecated pc-2.4 a long > time ago. The last batch of PC machine type retiring was pc-1.0 to pc-1.3: deprecated in 5.0 (commit 30d2a17b4, Dec 2019), dropped in 6.0 (commit f862ddbb1, just weeks ago). pc-1.3 was a bit over seven years old when we released 5.0. pc-2.4 will be six years old by the time we release 6.1. Fair game? >> 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. We've gotten better at documenting deprecations, but we're still bad at warning on use of deprecated features. [...]
On Fri, Apr 30, 2021 at 09:42:05 +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabkost@redhat.com> writes: > > > 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? > > > > This looks like a sign we should have deprecated pc-2.4 a long > > time ago. > > The last batch of PC machine type retiring was pc-1.0 to pc-1.3: > deprecated in 5.0 (commit 30d2a17b4, Dec 2019), dropped in 6.0 (commit > f862ddbb1, just weeks ago). pc-1.3 was a bit over seven years old when > we released 5.0. pc-2.4 will be six years old by the time we release > 6.1. Fair game? As a data-point, libvirt will be dropping support for <qemu-2.10 (release, not the machine type) in the upcomming release. I'm not sure whether that justifies more deprecation though.
* Peter Krempa (pkrempa@redhat.com) wrote: > On Fri, Apr 30, 2021 at 09:42:05 +0200, Markus Armbruster wrote: > > Eduardo Habkost <ehabkost@redhat.com> writes: > > > > > 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? > > > > > > This looks like a sign we should have deprecated pc-2.4 a long > > > time ago. > > > > The last batch of PC machine type retiring was pc-1.0 to pc-1.3: > > deprecated in 5.0 (commit 30d2a17b4, Dec 2019), dropped in 6.0 (commit > > f862ddbb1, just weeks ago). pc-1.3 was a bit over seven years old when > > we released 5.0. pc-2.4 will be six years old by the time we release > > 6.1. Fair game? > > As a data-point, libvirt will be dropping support for <qemu-2.10 > (release, not the machine type) in the upcomming release. I'm not sure > whether that justifies more deprecation though. What qemu features will you then be relying on? Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On 4/29/21 5:52 PM, 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. > > 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... > > I have tested that libvirt still works when the property is absent. It > no longer adds scsi=on|off to the command-line. > > Cc: Markus Armbruster <armbru@redhat.com> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Peter Krempa <pkrempa@redhat.com> > Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > --- > docs/specs/tpm.rst | 2 +- > docs/system/deprecated.rst | 13 --- > docs/pci_expander_bridge.txt | 2 +- > hw/block/virtio-blk.c | 192 +---------------------------------- > hw/core/machine.c | 2 - > 5 files changed, 3 insertions(+), 208 deletions(-) Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Michal
On Thu, Apr 29, 2021 at 16:52:21 +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. Does this mean that qemu rejects it if it's explicitly enabled on the commandline? > 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... > > I have tested that libvirt still works when the property is absent. It > no longer adds scsi=on|off to the command-line. Yup, we deliberately don't format it unless the user requested it since: https://gitlab.com/libvirt/libvirt/-/commit/ec69f0190be731d12faeac08dbf63325836509a9 Depending on your answer above I might need to dig through the code again to see whether we do the correct thing if it's no longer available. > > Cc: Markus Armbruster <armbru@redhat.com> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Peter Krempa <pkrempa@redhat.com> > Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > --- > docs/specs/tpm.rst | 2 +- > docs/system/deprecated.rst | 13 --- > docs/pci_expander_bridge.txt | 2 +- > hw/block/virtio-blk.c | 192 +---------------------------------- > hw/core/machine.c | 2 - > 5 files changed, 3 insertions(+), 208 deletions(-)
© 2016 - 2024 Red Hat, Inc.