From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MutfP-0007xZ-Fq for qemu-devel@nongnu.org; Mon, 05 Oct 2009 15:56:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MutfL-0007wm-I0 for qemu-devel@nongnu.org; Mon, 05 Oct 2009 15:56:19 -0400 Received: from [199.232.76.173] (port=55395 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MutfL-0007wj-C4 for qemu-devel@nongnu.org; Mon, 05 Oct 2009 15:56:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38900) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MutfK-0008Br-Ov for qemu-devel@nongnu.org; Mon, 05 Oct 2009 15:56:15 -0400 Date: Mon, 5 Oct 2009 21:54:09 +0200 From: "Michael S. Tsirkin" Message-ID: <20091005195409.GB3399@redhat.com> References: <200909212039.01126.rusty@rustcorp.com.au> <4AB7A01A.3000206@redhat.com> <4AB8992B.7070709@redhat.com> <4AB8DD53.7070806@redhat.com> <4AB8DECA.3090908@redhat.com> <4AB8E88C.4040103@redhat.com> <4AB980E6.2070203@codemonkey.ws> <4AB9AA8E.7060800@third-harmonic.com> <4AC1A4AD.10509@redhat.com> <4ACA1527.9050305@third-harmonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ACA1527.9050305@third-harmonic.com> Subject: [Qemu-devel] Re: [PATCH] fix virtio_blk serial pci config breakage, v2 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: john cooper Cc: john cooper , Rusty Russell , qemu-devel@nongnu.org, Avi Kivity , jens.axboe@oracle.com, Vadim Rozenfeld On Mon, Oct 05, 2009 at 11:47:51AM -0400, john cooper wrote: > This is a re-work of the previous version where the > associated data was being funneled through a free > PCI BAR mapping. Here a request for the identify > information results in a virtqueue command utilizing > the scaffolding introduced by Rusty's recent patch. > > Signed-off-by: john cooper good stuff. A couple of comments below. Also, what's going on with text alignment here? > --- > > > diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c > index dad4ef0..e754277 100644 > --- a/hw/virtio-blk.c > +++ b/hw/virtio-blk.c > @@ -25,6 +25,7 @@ typedef struct VirtIOBlock > BlockDriverState *bs; > VirtQueue *vq; > void *rq; > + uint16_t identify[VIRTIO_BLK_ID_LEN]; > } VirtIOBlock; > > static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev) > @@ -32,6 +33,48 @@ static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev) > return (VirtIOBlock *)vdev; > } > > +/* store identify data in little endian format > + */ > +static inline void put_le16(uint16_t *p, unsigned int v) > +{ > + *p = cpu_to_le16(v); > +} > + > +/* copy to *dst from *src, nul pad dst tail as needed to len bytes > + */ > +static inline void padstr(char *dst, const char *src, int len) > +{ > + while (len--) > + *dst++ = *src ? *src++ : '\0'; > +} > + > +/* setup simulated identify data as appropriate for virtio block device > + * > + * ref: AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS) > + */ > +static inline void virtio_identify_template(VirtIOBlock *s) > +{ > + uint16_t *p = s->identify; > + uint64_t lba_sectors; > + > + memset(p, 0, sizeof(uint16_t) * VIRTIO_BLK_ID_LEN); better as sizeof s->identity > + put_le16(p + 0, 0x0); /* ATA device */ > + padstr((char *)(p + 23), QEMU_VERSION, 8); /* firmware revision */ QEMU version is currently a string like "0.11.50" which is exactly 8 bytes. What if someone makes it longer? padstr will not 0 terminate string, and only partial data will be there. Maybe put compile assert here? Also, identify is pre-initialized to 0, isn't it? So just strcpy should be enough, here and elsewhere, no need to roll our own padstr. > + padstr((char *)(p + 27), "QEMU VIRT_BLK", 40); /* model# */ > + put_le16(p + 47, 0x80ff); /* max xfer 255 sectors */ > + put_le16(p + 49, 0x0b00); /* support IORDY/LBA/DMA */ > + put_le16(p + 59, 0x1ff); /* cur xfer 255 sectors */ > + put_le16(p + 80, 0x1f0); /* support ATA8/7/6/5/4 */ > + put_le16(p + 81, 0x16); > + put_le16(p + 82, 0x400); > + put_le16(p + 83, 0x400); > + bdrv_get_geometry(s->bs, &lba_sectors); > + put_le16(p + 100, lba_sectors); > + put_le16(p + 101, lba_sectors >> 16); > + put_le16(p + 102, lba_sectors >> 32); > + put_le16(p + 103, lba_sectors >> 48); > +} > + > typedef struct VirtIOBlockReq > { > VirtIOBlock *dev; > @@ -243,6 +286,11 @@ static void virtio_blk_handle_output(VirtIODevice *vdev, VirtQueue *vq) > > if (req->out->type & VIRTIO_BLK_T_SCSI_CMD) { > virtio_blk_handle_scsi(req); > + } > + else if (req->out->type & VIRTIO_BLK_T_GET_ID) { Pls put } and else on the same line > + memcpy(req->elem.in_sg[0].iov_base, s->identify, > + req->elem.in_sg[0].iov_len); Is this safe? Can guest make iov_len bigger than size of s->identity? > + virtio_blk_req_complete(req, VIRTIO_BLK_S_OK); > } else if (req->out->type & VIRTIO_BLK_T_OUT) { > qemu_iovec_init_external(&req->qiov, &req->elem.out_sg[1], > req->elem.out_num - 1); > @@ -304,6 +352,7 @@ static void virtio_blk_update_config(VirtIODevice *vdev, uint8_t *config) > > static uint32_t virtio_blk_get_features(VirtIODevice *vdev) > { > + VirtIOBlock *s = to_virtio_blk(vdev); > uint32_t features = 0; > > features |= (1 << VIRTIO_BLK_F_SEG_MAX); > @@ -311,6 +360,8 @@ static uint32_t virtio_blk_get_features(VirtIODevice *vdev) > #ifdef __linux__ > features |= (1 << VIRTIO_BLK_F_SCSI); > #endif > + if (*(char *)&s->identify[VIRTIO_BLK_ID_SN]) > + features |= 1 << VIRTIO_BLK_F_GET_ID; > return features; > } > @@ -360,7 +411,8 @@ void *virtio_blk_init(PCIBus *bus, BlockDriverState *bs) > PCI_VENDOR_ID_REDHAT_QUMRANET, > VIRTIO_ID_BLOCK, > PCI_CLASS_STORAGE_OTHER, 0x00, > - sizeof(struct virtio_blk_config), sizeof(VirtIOBlock)); > + sizeof(struct virtio_blk_config), > + sizeof(VirtIOBlock)); > if (!s) > return NULL; > > @@ -373,6 +425,10 @@ void *virtio_blk_init(PCIBus *bus, BlockDriverState *bs) > bdrv_guess_geometry(s->bs, &cylinders, &heads, &secs); > bdrv_set_geometry_hint(s->bs, cylinders, heads, secs); > > + virtio_identify_template(s); > + strncpy((char *)&s->identify[VIRTIO_BLK_ID_SN], > + (char *)drive_get_serial(bs), VIRTIO_BLK_ID_SN_BYTES); This can silently truncate the serial, can't it? Maybe check and error out? > + > s->vq = virtio_add_queue(&s->vdev, 128, virtio_blk_handle_output); > > qemu_add_vm_change_state_handler(virtio_blk_dma_restart_cb, s); > diff --git a/hw/virtio-blk.h b/hw/virtio-blk.h > index 5ef6c36..f508f20 100644 > --- a/hw/virtio-blk.h > +++ b/hw/virtio-blk.h > @@ -31,6 +31,12 @@ > #define VIRTIO_BLK_F_RO 5 /* Disk is read-only */ > #define VIRTIO_BLK_F_BLK_SIZE 6 /* Block size of disk is available*/ > #define VIRTIO_BLK_F_SCSI 7 /* Supports scsi command passthru */ > +#define _VIRTIO_BLK_F_IDENTIFY 8 /* obsolete */ Let's just put it in comment? It should not be used anywhere. > +#define VIRTIO_BLK_F_GET_ID 10 /* ATA IDENTIFY supported */ > + > +#define VIRTIO_BLK_ID_LEN 256 /* length of identify u16 array */ > +#define VIRTIO_BLK_ID_SN 10 /* start of char * serial# */ > +#define VIRTIO_BLK_ID_SN_BYTES 20 /* length in bytes of serial# */ > > struct virtio_blk_config > { > @@ -48,6 +54,8 @@ struct virtio_blk_config > > /* This bit says it's a scsi command, not an actual read or write. */ > #define VIRTIO_BLK_T_SCSI_CMD 2 > +#define _VIRTIO_BLK_T_FLUSH 4 > +#define VIRTIO_BLK_T_GET_ID 8 > > /* Barrier before this op. */ > #define VIRTIO_BLK_T_BARRIER 0x80000000 > diff --git a/hw/virtio.c b/hw/virtio.c > index 78c7637..dc38f59 100644 > --- a/hw/virtio.c > +++ b/hw/virtio.c > @@ -44,6 +44,8 @@ > * a read-and-acknowledge. */ > #define VIRTIO_PCI_ISR 19 > > +/* The remaining space is defined by each driver as the per-driver > + * configuration space */ > #define VIRTIO_PCI_CONFIG 20 > > /* Virtio ABI version, if we increment this, we break the guest driver. */ > diff --git a/sysemu.h b/sysemu.h > index 1f45fd6..185b4e3 100644 > --- a/sysemu.h > +++ b/sysemu.h > @@ -141,6 +141,8 @@ typedef enum { > BLOCK_ERR_STOP_ANY > } BlockInterfaceErrorAction; > > +#define BLOCK_SERIAL_STRLEN 20 > + > typedef struct DriveInfo { > BlockDriverState *bdrv; > BlockInterfaceType type; > @@ -149,7 +151,7 @@ typedef struct DriveInfo { > int used; > int drive_opt_idx; > BlockInterfaceErrorAction onerror; > - char serial[21]; > + char serial[BLOCK_SERIAL_STRLEN + 1]; > } DriveInfo; > > #define MAX_IDE_DEVS 2 > > > -- > john.cooper@third-harmonic.com