From patchwork Thu May 13 21:38:51 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Nicholas A. Bellinger" X-Patchwork-Id: 52522 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E9AF5B7E4C for ; Fri, 14 May 2010 07:39:42 +1000 (EST) Received: from localhost ([127.0.0.1]:38422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCg82-00010X-Qa for incoming@patchwork.ozlabs.org; Thu, 13 May 2010 17:39:38 -0400 Received: from [140.186.70.92] (port=46573 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCg7T-000104-6Y for qemu-devel@nongnu.org; Thu, 13 May 2010 17:39:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCg7R-0003aK-4H for qemu-devel@nongnu.org; Thu, 13 May 2010 17:39:02 -0400 Received: from smtp106.sbc.mail.gq1.yahoo.com ([67.195.14.109]:27885) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OCg7Q-0003a9-Rn for qemu-devel@nongnu.org; Thu, 13 May 2010 17:39:01 -0400 Received: (qmail 89216 invoked from network); 13 May 2010 21:38:59 -0000 Received: from adsl-70-231-246-220.dsl.snfc21.sbcglobal.net (nab@70.231.246.220 with plain) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 13 May 2010 14:38:58 -0700 PDT X-Yahoo-SMTP: fzDSGlOswBCWnIOrNw7KwwK1j9PqyNbe5PtLKiS4dDU.UNl_t6bdEZu9tTLW X-YMail-OSG: IdA1EfIVM1nUNYZNYqxQTiSW.uMlJ3NlMhuLeWhBbVDmmG6ZytW5rn0PKVs.MUwNwdOt_TwRXxP5wk4FwN4KnBUoiIJplhzdsE93pGKHVqfRX7PTmH5YvPWwZDeiaTIi29AV1IGhrJ8IIsOwYJaUMxbjsMdW152dIg4bN40H1VEpyBwRI4ixYBp7xj0DmH_mFtVRRcQKFp.GRx0kAUjsaS09lk6fbMGUoJFyaVsD2QuvUbXjzO7scZATGiTCkEgp1KPD_.RXc2deN4LHlOricQ7ZUEY3Iu4DKdXacVYcadlDUxVfMpq0Dya1gXhktLalhUwjy2hCzJR6ZYkLR72qnDRP7zqO6kDndqUE2dPuYulse_WHvu4oSPtxDBMTr9c6e.YW76ZNbaDlCg3E_n8RXmRMjyA06kuRUA-- X-Yahoo-Newman-Property: ymail-3 From: "Nicholas A. Bellinger" To: Hannes Reinecke , Gerd Hoffmann , Christoph Hellwig , FUJITA Tomonori , Mike Christie , Douglas Gilbert , James Bottomley Date: Thu, 13 May 2010 14:38:51 -0700 Message-Id: <1273786731.13658.49.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by eggs.gnu.org: FreeBSD 6.x (1) Cc: qemu-devel , kvm-devel , linux-scsi Subject: [Qemu-devel] [QEMU-KVM]: Megasas + TCM_Loop + SG_IO into Windows XP guests X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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. 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 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. 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..? Best, --nab 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; }