Nicholas A. Bellinger wrote: > Greetings Hannes and co, > > I have been spending a bit of time trying Megasas HBA emulation + > TCM_Loop + SG_IO with a Windows XP SP2 KVM guests.. So far, I noticed > that hw/scsi-generic.c:execute_command_run() using bdev_aio_ioctl() > appears to be broken for XP guests, which causes the first 36-byte > INQUIRY sent via SG_IO to never make it back to QEMU and results in the > win32 LSI drive taking the LUN offline, et al. Note that everything > does appear to be functioning as expected in kernel space for the first > INQUIRY with the TCM_Loop LLD and Linux/SCSI code (AFAICT) and Linux KVM > guests using megasas emulation are still working. > Now that is really odd. Have you checked if it works with the 'normal' KVM disk backend? > So, I ended up needing requiring the following quick hack for > hw/scsi-generic.c:execute_command_run() to make SG_IO function > synchronously using bdrv_ioctl(), which at least gets LUN registration > and basic control path CDBs working for the XP guest. > > Here is how it looks in action on a v2.6.34-rc7 host so far: > > http://www.linux-iscsi.org/images/TCM-KVM-megasas-XP-05132010.png > > > diff --git a/hw/scsi-generic.c b/hw/scsi-generic.c > index 6c58742..aa1eb83 100644 > --- a/hw/scsi-generic.c > +++ b/hw/scsi-generic.c > @@ -140,6 +140,7 @@ static int execute_command_run(SCSIGenericReq *r, > { > BlockDriverState *bdrv = r->req.dev->conf.dinfo->bdrv; > SCSIGenericState *s = DO_UPCAST(SCSIGenericState, qdev, r->req.dev); > + int ret; > > r->io_header.interface_id = 'S'; > r->io_header.dxfer_direction = sgdir[r->req.cmd.mode]; > @@ -161,11 +162,16 @@ static int execute_command_run(SCSIGenericReq *r, > printf("\n"); > } > #endif > +#if 0 > r->req.aiocb = bdrv_aio_ioctl(bdrv, SG_IO, &r->io_header, complete, r); > if (r->req.aiocb == NULL) { > BADF("execute_command: read failed !\n"); > return -1; > } > +#else > + ret = bdrv_ioctl(bdrv, SG_IO, &r->io_header); > + complete((void *)r, ret); > +#endif > > * return 0; > } > > > Beyond the initial LUN registration and control CDB parts, doing bulk > DATA_SG_IO traffic is completing successfully (and everything looks sane > with TCM_Loop and Linux/SCSI) but it appears that the correct blocks are > not actually getting written/read by megasas. This appears to be the > case with both hw/scsi-generic.c and hw/scsi-disk.c modes of operation > for megasas with the win32 XP guest. > Oh. Hmm. > So I was wondering if anyone aware of known issues with QEMU > asynchronous SG_IO into MSFT KVM guests with virtio or hw/lsi53c895a.c, > or would this be something specific to megasas HBA emulation and XP > guests..? > > Hannes, which MSFT guest + driver did you get work stable with bulk > DATA_SG_IO and hw/scsi-disk.c..? > Well, I have two more patches for megasas. The one is just a cleanup to remove duplicate definitions, but the other contains a real issue with a misjudged cast in megasas_enqueue_frame(). Not sure if that helps here, but it's worth a try nevertheless. I'll be sending them with separate mails. Let's see if I can find some time working on the megasas emulation. Maybe I find something. Last time I checked it was with a Windows7 build, but I didn't do any real tests there. Basically just checking if the system boots up :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
