From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QliTX-0002xU-DA for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:19:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QliTV-00025G-Sm for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:19:11 -0400 Received: from cantor2.suse.de ([195.135.220.15]:40488 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QliTV-00024x-HQ for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:19:09 -0400 Message-ID: <4E2ECCDB.4080904@suse.de> Date: Tue, 26 Jul 2011 16:19:07 +0200 From: Hannes Reinecke MIME-Version: 1.0 References: <1311346277-32329-1-git-send-email-hare@suse.de> <1311346277-32329-7-git-send-email-hare@suse.de> <4E2EC54C.5090208@redhat.com> In-Reply-To: <4E2EC54C.5090208@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 6/6] scsi-disk: Check for supported commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Alexander Graf , qemu-devel@nongnu.org, kvm@vger.kernel.org, Markus Armbruster On 07/26/2011 03:46 PM, Kevin Wolf wrote: > Am 22.07.2011 16:51, schrieb Hannes Reinecke: >> Not every command is support for any device type. This patch adds >> a check for rejecting unsupported commands. >> >> Signed-off-by: Hannes Reinecke > > We do emulate SEEK (6), but it's not in your scsi_cmd_table at all. > Hmm. >> --- >> hw/scsi-disk.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++= +++++++++- >> 1 files changed, 103 insertions(+), 1 deletions(-) >> >> diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c >> index ae2c157..8ad90c0 100644 >> --- a/hw/scsi-disk.c >> +++ b/hw/scsi-disk.c >> @@ -361,13 +361,107 @@ static int scsi_get_sense(SCSIRequest *req, uin= t8_t *outbuf, int len) >> return scsi_build_sense(s->sense, outbuf, len, len> 14); >> } >> >> +#define GENERIC_CMD (uint32_t)0xFFFFFFFF >> +#define DISK_CMD (1u<< TYPE_DISK) >> +#define TAPE_CMD (1u<< TYPE_TAPE) >> +#define PRINTER_CMD (1u<< TYPE_PRINTER) >> +#define PROCESSOR_CMD (1u<< TYPE_PROCESSOR) >> +#define WORM_CMD (1u<< TYPE_WORM) >> +#define ROM_CMD (1u<< TYPE_ROM) >> +#define SCANNER_CMD (1u<< TYPE_SCANNER) >> +#define MOD_CMD (1u<< TYPE_MOD) >> +#define MEDIUM_CHANGER_CMD (1u<< TYPE_MEDIUM_CHANGER) >> +#define ARRAY_CMD (1u<< TYPE_STORAGE_ARRAY) >> +#define ENCLOSURE_CMD (1u<< TYPE_ENCLOSURE) >> +#define RBC_CMD (1u<< TYPE_RBC) >> +#define OSD_CMD (1u<< TYPE_OSD) >> + >> +#define NO_ROM_CMD (GENERIC_CMD | ~ROM_CMD) >> + >> +uint32_t scsi_cmd_table[0x100] =3D { >> + [TEST_UNIT_READY] =3D GENERIC_CMD, >> + [REWIND] =3D TAPE_CMD, >> + [REQUEST_SENSE] =3D GENERIC_CMD, >> + [FORMAT_UNIT] =3D DISK_CMD|ROM_CMD, >> + [READ_BLOCK_LIMITS] =3D TAPE_CMD, >> + [REASSIGN_BLOCKS] =3D DISK_CMD|WORM_CMD|MOD_CMD, >> + [READ_6] =3D DISK_CMD|TAPE_CMD|WORM_CMD|ROM_CM= D|MOD_CMD, > > My spec says that MMC doesn't support READ(6) > But it does support 'RECEIVE(6)', with the same opcode. >> + [WRITE_6] =3D DISK_CMD|TAPE_CMD|WORM_CMD|MOD_CM= D, >> + [READ_REVERSE] =3D TAPE_CMD, >> + [WRITE_FILEMARKS] =3D TAPE_CMD, >> + [SPACE] =3D TAPE_CMD, >> + [INQUIRY] =3D GENERIC_CMD, >> + [MODE_SELECT] =3D GENERIC_CMD, >> + [RESERVE] =3D TAPE_CMD|PRINTER_CMD, >> + [RELEASE] =3D TAPE_CMD|PRINTER_CMD, > > What's the reason for allowing this for tape, but not e.g. for disks? > It's marked as obsolete for both (and optional for quite a few other ty= pes) > Because it's mandatory for TAPE and PRINTER. But the implementation=20 details are horrible and we're not doing anything here (which in=20 itself is a violation of the spec), so I think it's better to not support it if we don't have to. >> + [ERASE] =3D TAPE_CMD, >> + [MODE_SENSE] =3D GENERIC_CMD, >> + [START_STOP] =3D GENERIC_CMD, >> + [RECEIVE_DIAGNOSTIC] =3D GENERIC_CMD, >> + [SEND_DIAGNOSTIC] =3D GENERIC_CMD, >> + [ALLOW_MEDIUM_REMOVAL] =3D GENERIC_CMD, >> + [READ_CAPACITY_10] =3D DISK_CMD|WORM_CMD|MOD_CMD, > > ROM_CMD, too > Ok. >> + [READ_10] =3D DISK_CMD|WORM_CMD|ROM_CMD|MOD_CMD= , >> + [WRITE_10] =3D DISK_CMD|WORM_CMD|ROM_CMD|MOD_CMD= , >> + [SEEK_10] =3D TAPE_CMD|WORM_CMD|ROM_CMD|MOD_CMD= , > > Tape doesn't have SEEK(10) in the spec. > But it does have 'LOCATE_10', which shares the same opcode. >> + [WRITE_VERIFY_10] =3D DISK_CMD|WORM_CMD|ROM_CMD|MOD_CMD= , >> + [VERIFY_10] =3D DISK_CMD|WORM_CMD|ROM_CMD|MOD_CMD= , >> + [READ_POSITION] =3D TAPE_CMD, >> + [SYNCHRONIZE_CACHE] =3D DISK_CMD|WORM_CMD|ROM_CMD|MOD_CMD= |RBC_CMD, >> + [WRITE_BUFFER] =3D GENERIC_CMD, >> + [READ_BUFFER] =3D GENERIC_CMD, >> + [READ_LONG_10] =3D DISK_CMD|WORM_CMD|MOD_CMD, >> + [WRITE_LONG_10] =3D DISK_CMD|WORM_CMD|MOD_CMD, >> + [WRITE_SAME_10] =3D DISK_CMD, >> + [UNMAP] =3D DISK_CMD, >> + [READ_TOC] =3D ROM_CMD, >> + [REPORT_DENSITY_SUPPORT] =3D TAPE_CMD, >> + [GET_CONFIGURATION] =3D ROM_CMD, >> + [LOG_SELECT] =3D GENERIC_CMD, >> + [LOG_SENSE] =3D GENERIC_CMD, >> + [MODE_SELECT_10] =3D GENERIC_CMD, >> + [RESERVE_10] =3D PRINTER_CMD, >> + [RELEASE_10] =3D PRINTER_CMD, >> + [MODE_SENSE_10] =3D GENERIC_CMD, >> + [PERSISTENT_RESERVE_IN] =3D GENERIC_CMD, >> + [PERSISTENT_RESERVE_OUT] =3D GENERIC_CMD, >> + [VARLENGTH_CDB] =3D OSD_CMD, >> + [WRITE_FILEMARKS_16] =3D TAPE_CMD, >> + [ATA_PASSTHROUGH] =3D DISK_CMD|ROM_CMD|RBC_CMD, >> + [READ_16] =3D DISK_CMD|TAPE_CMD|WORM_CMD|MOD_CM= D|RBC_CMD, >> + [WRITE_16] =3D DISK_CMD|TAPE_CMD|WORM_CMD|MOD_CM= D|RBC_CMD, >> + [WRITE_VERIFY_16] =3D DISK_CMD|WORM_CMD|MOD_CMD|RBC_CMD= , >> + [SYNCHRONIZE_CACHE_16] =3D DISK_CMD|TAPE_CMD|WORM_CMD|MOD_CM= D|RBC_CMD, > > Tape doesn't have this. > It's called 'SPACE(16)' for tapes. >> + [LOCATE_16] =3D TAPE_CMD, >> + [WRITE_SAME_16] =3D DISK_CMD|TAPE_CMD, > > Again not for tape in my spec. > But tape has 'ERASE(16)', again with the same opcode. However, these duplicate opcodes are really awkward. Especially with=20 debugging enabled one wouldn't be able to print out the correct name for an opcode. I guess I take the approach suggested by hch and have different=20 tables for the individual device-types. Let's see ... Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: J. Hawn, J. Guild, F. Imend=F6rffer, HRB 16746 (AG N=FCrnberg)