Re: [PATCH 2/2] scsi-disk: Fix crash for VM configured with USB CDROM after live migration

[Yong Huang]

On Fri, May 24, 2024 at 6:01 PM Prasad Pandit <ppandit@redhat.com> wrote:

Hello Hyman,

* Is this the same patch series as sent before..?
  -> https://lists.nongnu.org/archive/html/qemu-devel/2024-04/msg00816.html

Yes, exactly the same, I just refine the comment

 

On Fri, 24 May 2024 at 12:02, Hyman Huang <yong.huang@smartx.com> wrote:
> For VMs configured with the USB CDROM device:
>
> -drive file=/path/to/local/file,id=drive-usb-disk0,media=cdrom,readonly=on...
> -device usb-storage,drive=drive-usb-disk0,id=usb-disk0...
>
> QEMU process may crash after live migration,
> Do the live migration repeatedly, crash may happen after live migratoin,

* Does live migration work many times before QEMU crashes on the
destination side? OR QEMU crashes at the very first migration?

>    at /usr/src/debug/qemu-6-6.2.0-75.7.oe1.smartx.git.40.x86_64/include/qemu/iov.h:49

* This qemu version looks quite old. Is the issue reproducible with
the latest QEMU version 9.0?

I'm not testing the latest QEMU version while theoretically it is

reproducible, I'll check it and give a conclusion.  

 

> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> +static void scsi_disk_emulate_save_request(QEMUFile *f, SCSIRequest *req)
> +{
> +    SCSIDiskReq *r = DO_UPCAST(SCSIDiskReq, req, req);
> +    SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, r->req.dev);
> +
> +    if (s->migrate_emulate_scsi_request) {
> +        scsi_disk_save_request(f, req);
> +    }
> +}
> +
>  static void scsi_disk_load_request(QEMUFile *f, SCSIRequest *req)
>  {
>      SCSIDiskReq *r = DO_UPCAST(SCSIDiskReq, req, req);
> @@ -183,6 +193,16 @@ static void scsi_disk_load_request(QEMUFile *f, SCSIRequest *req)
>      qemu_iovec_init_external(&r->qiov, &r->iov, 1);
>  }
>
> +static void scsi_disk_emulate_load_request(QEMUFile *f, SCSIRequest *req)
> +{
> +    SCSIDiskReq *r = DO_UPCAST(SCSIDiskReq, req, req);
> +    SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, r->req.dev);
> +
> +    if (s->migrate_emulate_scsi_request) {
> +        scsi_disk_load_request(f, req);
> +    }
> +}
> +
>  /*
>   * scsi_handle_rw_error has two return values.  False means that the error
>   * must be ignored, true means that the error has been processed and the
> @@ -2593,6 +2613,8 @@ static const SCSIReqOps scsi_disk_emulate_reqops = {
>      .read_data    = scsi_disk_emulate_read_data,
>      .write_data   = scsi_disk_emulate_write_data,
>      .get_buf      = scsi_get_buf,
> +    .load_request = scsi_disk_emulate_load_request,
> +    .save_request = scsi_disk_emulate_save_request,
>  };
>
>  static const SCSIReqOps scsi_disk_dma_reqops = {
> @@ -3137,7 +3159,7 @@ static Property scsi_hd_properties[] = {
>  static int scsi_disk_pre_save(void *opaque)
>  {
>      SCSIDiskState *dev = opaque;
> -    dev->migrate_emulate_scsi_request = false;
> +    dev->migrate_emulate_scsi_request = true;
>

* This patch seems to add support for migrating SCSI requests. While
it looks okay, not sure if it is required, how likely is someone to
configure a VM to use CDROM?

I'm not sure this usage is common but in our production environment, 

it is used.

 

*  Should the CDROM device be reset on the destination if no requests
are found? ie. if (scsi_req_get_buf -> scsi_get_buf() returns NULL)?

IMHO, resetting the CDROM device may be a work around because

the request SHOULD not be lost. No requests are found may be

caused by other reasons, resetting the CD ROM seems crude.

The path that executes the scsi_get_buf() is in a USB mass storage

device,  and it called by the UHCI controller originally, which just

handles the Frame List blindly, reset solution is kind of complicated

in implementation

Migrating the requests may be a graceful solution.

Thanks for the comments,

Yong

Thank you.
---
  - Prasad

--

Best regards