From patchwork Wed Nov 23 11:44:59 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Hajnoczi X-Patchwork-Id: 127274 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 8AAEF1007D2 for ; Wed, 23 Nov 2011 22:47:02 +1100 (EST) Received: from localhost ([::1]:52030 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTBHx-0005pa-9a for incoming@patchwork.ozlabs.org; Wed, 23 Nov 2011 06:46:53 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTBHn-0005ki-SO for qemu-devel@nongnu.org; Wed, 23 Nov 2011 06:46:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTBHm-0001wm-8e for qemu-devel@nongnu.org; Wed, 23 Nov 2011 06:46:43 -0500 Received: from mtagate7.uk.ibm.com ([194.196.100.167]:36000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTBHl-0001wb-VU for qemu-devel@nongnu.org; Wed, 23 Nov 2011 06:46:42 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id pANBkfpY008720 for ; Wed, 23 Nov 2011 11:46:41 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pANBkfCO2666592 for ; Wed, 23 Nov 2011 11:46:41 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pANBkePo029994 for ; Wed, 23 Nov 2011 04:46:40 -0700 Received: from localhost (sig-9-79-13-177.uk.ibm.com [9.79.13.177]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pANBke1P029989; Wed, 23 Nov 2011 04:46:40 -0700 From: Stefan Hajnoczi To: Date: Wed, 23 Nov 2011 11:44:59 +0000 Message-Id: <1322048728-26061-10-git-send-email-stefanha@linux.vnet.ibm.com> X-Mailer: git-send-email 1.7.7.1 In-Reply-To: <1322048728-26061-1-git-send-email-stefanha@linux.vnet.ibm.com> References: <1322048728-26061-1-git-send-email-stefanha@linux.vnet.ibm.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 194.196.100.167 Cc: Kevin Wolf , Paolo Bonzini , Marcelo Tosatti Subject: [Qemu-devel] [PATCH v3 09/38] scsi-block: always use SG_IO for MMC devices X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org From: Paolo Bonzini CD burning messes up the state of the host page cache and host block device. Just pass all operations down to the device, even though that might have slightly worse performance. Everything else just is not reliable in combination with burning. Reported-by: Thomas Schmitt Signed-off-by: Paolo Bonzini Signed-off-by: Kevin Wolf --- hw/scsi-disk.c | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-) diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c index e3690ec..673948c 100644 --- a/hw/scsi-disk.c +++ b/hw/scsi-disk.c @@ -1703,8 +1703,20 @@ static SCSIRequest *scsi_block_new_request(SCSIDevice *d, uint32_t tag, case WRITE_VERIFY_10: case WRITE_VERIFY_12: case WRITE_VERIFY_16: - return scsi_req_alloc(&scsi_disk_reqops, &s->qdev, tag, lun, - hba_private); + /* MMC writing cannot be done via pread/pwrite, because it sometimes + * involves writing beyond the maximum LBA or to negative LBA (lead-in). + * And once you do these writes, reading from the block device is + * unreliable, too. It is even possible that reads deliver random data + * from the host page cache (this is probably a Linux bug). + * + * We might use scsi_disk_reqops as long as no writing commands are + * seen, but performance usually isn't paramount on optical media. So, + * just make scsi-block operate the same as scsi-generic for them. + */ + if (s->qdev.type != TYPE_ROM) { + return scsi_req_alloc(&scsi_disk_reqops, &s->qdev, tag, lun, + hba_private); + } } return scsi_req_alloc(&scsi_generic_req_ops, &s->qdev, tag, lun,