From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXrUS-0003Kz-IU for qemu-devel@nongnu.org; Fri, 25 May 2012 06:11:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXrUM-0006eG-9k for qemu-devel@nongnu.org; Fri, 25 May 2012 06:11:24 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:48876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXrUM-0006e9-1D for qemu-devel@nongnu.org; Fri, 25 May 2012 06:11:18 -0400 Received: by dadv2 with SMTP id v2so1184666dad.4 for ; Fri, 25 May 2012 03:11:16 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4FBF5ABE.5050107@redhat.com> Date: Fri, 25 May 2012 12:11:10 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1337939061-13629-1-git-send-email-kraxel@redhat.com> <1337939061-13629-11-git-send-email-kraxel@redhat.com> In-Reply-To: <1337939061-13629-11-git-send-email-kraxel@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 10/10] usb-storage: migration support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Il 25/05/2012 11:44, Gerd Hoffmann ha scritto: > With all scsi migration support bits in place the > final step is pretty simple ;) > > Signed-off-by: Gerd Hoffmann > --- > hw/usb/dev-storage.c | 23 +++++++++++++++++++++-- > 1 files changed, 21 insertions(+), 2 deletions(-) > > diff --git a/hw/usb/dev-storage.c b/hw/usb/dev-storage.c > index 1975d26..7646a77 100644 > --- a/hw/usb/dev-storage.c > +++ b/hw/usb/dev-storage.c > @@ -506,6 +506,17 @@ static void usb_msd_password_cb(void *opaque, int err) > qdev_unplug(&s->dev.qdev, NULL); > } > > +static void *usb_msd_load_request(QEMUFile *f, SCSIRequest *req) > +{ > + MSDState *s = DO_UPCAST(MSDState, dev.qdev, req->bus->qbus.parent); > + > + /* nothing to load, just store req in our state struct */ > + assert(s->req == NULL); > + scsi_req_ref(req); > + s->req = req; > + return NULL; > +} > + > static const struct SCSIBusInfo usb_msd_scsi_info = { > .tcq = false, > .max_target = 0, > @@ -513,7 +524,8 @@ static const struct SCSIBusInfo usb_msd_scsi_info = { > > .transfer_data = usb_msd_transfer_data, > .complete = usb_msd_command_complete, > - .cancel = usb_msd_request_cancelled > + .cancel = usb_msd_request_cancelled, > + .load_request = usb_msd_load_request, > }; > > static int usb_msd_initfn(USBDevice *dev) > @@ -633,11 +645,18 @@ static USBDevice *usb_msd_init(USBBus *bus, const char *filename) > > static const VMStateDescription vmstate_usb_msd = { > .name = "usb-storage", > - .unmigratable = 1, /* FIXME: handle transactions which are in flight */ > .version_id = 1, > .minimum_version_id = 1, > .fields = (VMStateField []) { > VMSTATE_USB_DEVICE(dev, MSDState), > + VMSTATE_UINT32(mode, MSDState), > + VMSTATE_UINT32(scsi_len, MSDState), > + VMSTATE_UINT32(scsi_off, MSDState), > + VMSTATE_UINT32(data_len, MSDState), > + VMSTATE_UINT32(csw.sig, MSDState), > + VMSTATE_UINT32(csw.tag, MSDState), > + VMSTATE_UINT32(csw.residue, MSDState), > + VMSTATE_UINT8(csw.status, MSDState), > VMSTATE_END_OF_LIST() > } > }; Can usb-storage have multiple requests in flight (in principle, i.e. according to the USB protocol)? If so, it may be better if you save scsi_len/scsi_off in save_request/load_request. The migration format will be forward-compatible. Otherwise looks good! Paolo