* [Qemu-devel] [PATCH 1/9] scsi: avoid assertion failure on VERIFY command
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device implementation Paolo Bonzini
` (10 subsequent siblings)
11 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: asias, nab
A verify command is not an actual read (we do not implement
compare mode) and thus does not have an AIOCB attached. Do
not crash in scsi_dma_complete.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/scsi/scsi-disk.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index f52bd11..c8d2a99 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -244,14 +244,15 @@ done:
}
}
-static void scsi_dma_complete(void *opaque, int ret)
+static void scsi_dma_complete_noio(void *opaque, int ret)
{
SCSIDiskReq *r = (SCSIDiskReq *)opaque;
SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, r->req.dev);
- assert(r->req.aiocb != NULL);
- r->req.aiocb = NULL;
- bdrv_acct_done(s->qdev.conf.bs, &r->acct);
+ if (r->req.aiocb != NULL) {
+ r->req.aiocb = NULL;
+ bdrv_acct_done(s->qdev.conf.bs, &r->acct);
+ }
if (r->req.io_canceled) {
goto done;
}
@@ -277,6 +278,14 @@ done:
}
}
+static void scsi_dma_complete(void *opaque, int ret)
+{
+ SCSIDiskReq *r = (SCSIDiskReq *)opaque;
+
+ assert(r->req.aiocb != NULL);
+ scsi_dma_complete_noio(opaque, ret);
+}
+
static void scsi_read_complete(void * opaque, int ret)
{
SCSIDiskReq *r = (SCSIDiskReq *)opaque;
@@ -496,7 +505,7 @@ static void scsi_write_data(SCSIRequest *req)
if (r->req.cmd.buf[0] == VERIFY_10 || r->req.cmd.buf[0] == VERIFY_12 ||
r->req.cmd.buf[0] == VERIFY_16) {
if (r->req.sg) {
- scsi_dma_complete(r, 0);
+ scsi_dma_complete_noio(r, 0);
} else {
scsi_write_complete(r, 0);
}
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device implementation
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 1/9] scsi: avoid assertion failure on VERIFY command Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-06-21 3:47 ` Libaiqing
2013-04-19 14:24 ` [Qemu-devel] [PATCH 3/9] vhost: Add vhost_commit callback for SeaBIOS ROM region re-mapping Paolo Bonzini
` (9 subsequent siblings)
11 siblings, 1 reply; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: Dmitry Fleytman, Yan Vugenfirer, asias, nab
From: Dmitry Fleytman <dmitry@daynix.com>
Signed-off-by: Dmitry Fleytman <dmitry@daynix.com>
Signed-off-by: Yan Vugenfirer <yan@daynix.com>
[ Rename files to vmw_pvscsi, fix setting of hostStatus in
pvscsi_request_cancelled - Paolo ]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
default-configs/pci.mak | 1 +
docs/specs/vmw_pvscsi-spec.txt | 92 +++
hw/scsi/Makefile.objs | 1 +
hw/scsi/vmw_pvscsi.c | 1216 ++++++++++++++++++++++++++++++++++++++++
hw/scsi/vmw_pvscsi.h | 434 ++++++++++++++
include/hw/pci/pci.h | 1 +
trace-events | 35 ++
7 files changed, 1780 insertions(+)
create mode 100644 docs/specs/vmw_pvscsi-spec.txt
create mode 100644 hw/scsi/vmw_pvscsi.c
create mode 100644 hw/scsi/vmw_pvscsi.h
diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index f5f100e..bf2cad7 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -10,6 +10,7 @@ CONFIG_EEPRO100_PCI=y
CONFIG_PCNET_PCI=y
CONFIG_PCNET_COMMON=y
CONFIG_LSI_SCSI_PCI=y
+CONFIG_VMW_PVSCSI_SCSI_PCI=y
CONFIG_MEGASAS_SCSI_PCI=y
CONFIG_RTL8139_PCI=y
CONFIG_E1000_PCI=y
diff --git a/docs/specs/vmw_pvscsi-spec.txt b/docs/specs/vmw_pvscsi-spec.txt
new file mode 100644
index 0000000..49affb2
--- /dev/null
+++ b/docs/specs/vmw_pvscsi-spec.txt
@@ -0,0 +1,92 @@
+General Description
+===================
+
+This document describes VMWare PVSCSI device interface specification.
+Created by Dmitry Fleytman (dmitry@daynix.com), Daynix Computing LTD.
+Based on source code of PVSCSI Linux driver from kernel 3.0.4
+
+PVSCSI Device Interface Overview
+================================
+
+The interface is based on memory area shared between hypervisor and VM.
+Memory area is obtained by driver as device IO memory resource of
+PVSCSI_MEM_SPACE_SIZE length.
+The shared memory consists of registers area and rings area.
+The registers area is used to raise hypervisor interrupts and issue device
+commands. The rings area is used to transfer data descriptors and SCSI
+commands from VM to hypervisor and to transfer messages produced by
+hypervisor to VM. Data itself is transferred via virtual scatter-gather DMA.
+
+PVSCSI Device Registers
+=======================
+
+The length of the registers area is 1 page (PVSCSI_MEM_SPACE_COMMAND_NUM_PAGES).
+The structure of the registers area is described by the PVSCSIRegOffset enum.
+There are registers to issue device command (with optional short data),
+issue device interrupt, control interrupts masking.
+
+PVSCSI Device Rings
+===================
+
+There are three rings in shared memory:
+
+ 1. Request ring (struct PVSCSIRingReqDesc *req_ring)
+ - ring for OS to device requests
+ 2. Completion ring (struct PVSCSIRingCmpDesc *cmp_ring)
+ - ring for device request completions
+ 3. Message ring (struct PVSCSIRingMsgDesc *msg_ring)
+ - ring for messages from device.
+ This ring is optional and the guest might not configure it.
+There is a control area (struct PVSCSIRingsState *rings_state) used to control
+rings operation.
+
+PVSCSI Device to Host Interrupts
+================================
+There are following interrupt types supported by PVSCSI device:
+ 1. Completion interrupts (completion ring notifications):
+ PVSCSI_INTR_CMPL_0
+ PVSCSI_INTR_CMPL_1
+ 2. Message interrupts (message ring notifications):
+ PVSCSI_INTR_MSG_0
+ PVSCSI_INTR_MSG_1
+
+Interrupts are controlled via PVSCSI_REG_OFFSET_INTR_MASK register
+Bit set means interrupt enabled, bit cleared - disabled
+
+Interrupt modes supported are legacy, MSI and MSI-X
+In case of legacy interrupts, register PVSCSI_REG_OFFSET_INTR_STATUS
+is used to check which interrupt has arrived. Interrupts are
+acknowledged when the corresponding bit is written to the interrupt
+status register.
+
+PVSCSI Device Operation Sequences
+=================================
+
+1. Startup sequence:
+ a. Issue PVSCSI_CMD_ADAPTER_RESET command;
+ aa. Windows driver reads interrupt status register here;
+ b. Issue PVSCSI_CMD_SETUP_MSG_RING command with no additional data,
+ check status and disable device messages if error returned;
+ (Omitted if device messages disabled by driver configuration)
+ c. Issue PVSCSI_CMD_SETUP_RINGS command, provide rings configuration
+ as struct PVSCSICmdDescSetupRings;
+ d. Issue PVSCSI_CMD_SETUP_MSG_RING command again, provide
+ rings configuration as struct PVSCSICmdDescSetupMsgRing;
+ e. Unmask completion and message (if device messages enabled) interrupts.
+
+2. Shutdown sequences
+ a. Mask interrupts;
+ b. Flush request ring using PVSCSI_REG_OFFSET_KICK_NON_RW_IO;
+ c. Issue PVSCSI_CMD_ADAPTER_RESET command.
+
+3. Send request
+ a. Fill next free request ring descriptor;
+ b. Issue PVSCSI_REG_OFFSET_KICK_RW_IO for R/W operations;
+ or PVSCSI_REG_OFFSET_KICK_NON_RW_IO for other operations.
+
+4. Abort command
+ a. Issue PVSCSI_CMD_ABORT_CMD command;
+
+5. Request completion processing
+ a. Upon completion interrupt arrival process completion
+ and message (if enabled) rings.
diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
index aab0e9b..eaec6c8 100644
--- a/hw/scsi/Makefile.objs
+++ b/hw/scsi/Makefile.objs
@@ -2,6 +2,7 @@ common-obj-y += scsi-disk.o
common-obj-y += scsi-generic.o scsi-bus.o
common-obj-$(CONFIG_LSI_SCSI_PCI) += lsi53c895a.o
common-obj-$(CONFIG_MEGASAS_SCSI_PCI) += megasas.o
+common-obj-$(CONFIG_VMW_PVSCSI_SCSI_PCI) += vmw_pvscsi.o
common-obj-$(CONFIG_ESP) += esp.o
common-obj-$(CONFIG_ESP_PCI) += esp-pci.o
obj-$(CONFIG_PSERIES) += spapr_vscsi.o
diff --git a/hw/scsi/vmw_pvscsi.c b/hw/scsi/vmw_pvscsi.c
new file mode 100644
index 0000000..4b4a58f
--- /dev/null
+++ b/hw/scsi/vmw_pvscsi.c
@@ -0,0 +1,1216 @@
+/*
+ * QEMU VMWARE PVSCSI paravirtual SCSI bus
+ *
+ * Copyright (c) 2012 Ravello Systems LTD (http://ravellosystems.com)
+ *
+ * Developed by Daynix Computing LTD (http://www.daynix.com)
+ *
+ * Based on implementation by Paolo Bonzini
+ * http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00729.html
+ *
+ * Authors:
+ * Paolo Bonzini <pbonzini@redhat.com>
+ * Dmitry Fleytman <dmitry@daynix.com>
+ * Yan Vugenfirer <yan@daynix.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.
+ * See the COPYING file in the top-level directory.
+ *
+ * NOTE about MSI-X:
+ * MSI-X support has been removed for the moment because it leads Windows OS
+ * to crash on startup. The crash happens because Windows driver requires
+ * MSI-X shared memory to be part of the same BAR used for rings state
+ * registers, etc. This is not supported by QEMU infrastructure so separate
+ * BAR created from MSI-X purposes. Windows driver fails to deal with 2 BARs.
+ *
+ */
+
+#include "hw/scsi/scsi.h"
+#include <block/scsi.h>
+#include "hw/pci/msi.h"
+#include "vmw_pvscsi.h"
+#include "trace.h"
+
+
+#define PVSCSI_MSI_OFFSET (0x50)
+#define PVSCSI_USE_64BIT (true)
+#define PVSCSI_PER_VECTOR_MASK (false)
+
+#define PVSCSI_MAX_DEVS (64)
+#define PVSCSI_MSIX_NUM_VECTORS (1)
+
+#define PVSCSI_MAX_CMD_DATA_WORDS \
+ (sizeof(PVSCSICmdDescSetupRings)/sizeof(uint32_t))
+
+#define RS_GET_FIELD(rs_pa, field) \
+ (ldl_le_phys(rs_pa + offsetof(struct PVSCSIRingsState, field)))
+#define RS_SET_FIELD(rs_pa, field, val) \
+ (stl_le_phys(rs_pa + offsetof(struct PVSCSIRingsState, field), val))
+
+#define TYPE_PVSCSI "pvscsi"
+#define PVSCSI(obj) OBJECT_CHECK(PVSCSIState, (obj), TYPE_PVSCSI)
+
+typedef struct PVSCSIRingInfo {
+ uint64_t rs_pa;
+ uint32_t txr_len_mask;
+ uint32_t rxr_len_mask;
+ uint32_t msg_len_mask;
+ uint64_t req_ring_pages_pa[PVSCSI_SETUP_RINGS_MAX_NUM_PAGES];
+ uint64_t cmp_ring_pages_pa[PVSCSI_SETUP_RINGS_MAX_NUM_PAGES];
+ uint64_t msg_ring_pages_pa[PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES];
+ uint64_t consumed_ptr;
+ uint64_t filled_cmp_ptr;
+ uint64_t filled_msg_ptr;
+} PVSCSIRingInfo;
+
+typedef struct PVSCSISGState {
+ hwaddr elemAddr;
+ hwaddr dataAddr;
+ uint32_t resid;
+} PVSCSISGState;
+
+typedef QTAILQ_HEAD(, PVSCSIRequest) PVSCSIRequestList;
+
+typedef struct {
+ PCIDevice parent_obj;
+ MemoryRegion io_space;
+ SCSIBus bus;
+ QEMUBH *completion_worker;
+ PVSCSIRequestList pending_queue;
+ PVSCSIRequestList completion_queue;
+
+ uint64_t reg_interrupt_status; /* Interrupt status register value */
+ uint64_t reg_interrupt_enabled; /* Interrupt mask register value */
+ uint64_t reg_command_status; /* Command status register value */
+
+ /* Command data adoption mechanism */
+ uint64_t curr_cmd; /* Last command arrived */
+ uint32_t curr_cmd_data_cntr; /* Amount of data for last command */
+
+ /* Collector for current command data */
+ uint32_t curr_cmd_data[PVSCSI_MAX_CMD_DATA_WORDS];
+
+ uint8_t rings_info_valid; /* Whether data rings initialized */
+ uint8_t msg_ring_info_valid; /* Whether message ring initialized */
+ uint8_t use_msg; /* Whether to use message ring */
+
+ uint8_t msi_used; /* Whether MSI support was installed successfully */
+
+ PVSCSIRingInfo rings; /* Data transfer rings manager */
+ uint32_t resetting; /* Reset in progress */
+} PVSCSIState;
+
+typedef struct PVSCSIRequest {
+ SCSIRequest *sreq;
+ PVSCSIState *dev;
+ uint8_t sense_key;
+ uint8_t completed;
+ int lun;
+ QEMUSGList sgl;
+ PVSCSISGState sg;
+ struct PVSCSIRingReqDesc req;
+ struct PVSCSIRingCmpDesc cmp;
+ QTAILQ_ENTRY(PVSCSIRequest) next;
+} PVSCSIRequest;
+
+/* Integer binary logarithm */
+static int
+pvscsi_log2(uint32_t input)
+{
+ int log = 0;
+ assert(input > 0);
+ while (input >> ++log) {
+ }
+ return log;
+}
+
+static void
+pvscsi_ring_init_data(PVSCSIRingInfo *m, PVSCSICmdDescSetupRings *ri)
+{
+ int i;
+ uint32_t txr_len_log2, rxr_len_log2;
+ uint32_t req_ring_size, cmp_ring_size;
+ m->rs_pa = ri->ringsStatePPN << VMW_PAGE_SHIFT;
+
+ req_ring_size = ri->reqRingNumPages * PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE;
+ cmp_ring_size = ri->cmpRingNumPages * PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE;
+ txr_len_log2 = pvscsi_log2(req_ring_size - 1);
+ rxr_len_log2 = pvscsi_log2(cmp_ring_size - 1);
+
+ m->txr_len_mask = MASK(txr_len_log2);
+ m->rxr_len_mask = MASK(rxr_len_log2);
+
+ m->consumed_ptr = 0;
+ m->filled_cmp_ptr = 0;
+
+ for (i = 0; i < ri->reqRingNumPages; i++) {
+ m->req_ring_pages_pa[i] = ri->reqRingPPNs[i] << VMW_PAGE_SHIFT;
+ }
+
+ for (i = 0; i < ri->cmpRingNumPages; i++) {
+ m->cmp_ring_pages_pa[i] = ri->cmpRingPPNs[i] << VMW_PAGE_SHIFT;
+ }
+
+ RS_SET_FIELD(m->rs_pa, reqProdIdx, 0);
+ RS_SET_FIELD(m->rs_pa, reqConsIdx, 0);
+ RS_SET_FIELD(m->rs_pa, reqNumEntriesLog2, txr_len_log2);
+
+ RS_SET_FIELD(m->rs_pa, cmpProdIdx, 0);
+ RS_SET_FIELD(m->rs_pa, cmpConsIdx, 0);
+ RS_SET_FIELD(m->rs_pa, cmpNumEntriesLog2, rxr_len_log2);
+
+ trace_pvscsi_ring_init_data(txr_len_log2, rxr_len_log2);
+
+ /* Flush ring state page changes */
+ smp_wmb();
+}
+
+static void
+pvscsi_ring_init_msg(PVSCSIRingInfo *m, PVSCSICmdDescSetupMsgRing *ri)
+{
+ int i;
+ uint32_t len_log2;
+ uint32_t ring_size;
+
+ ring_size = ri->numPages * PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE;
+ len_log2 = pvscsi_log2(ring_size - 1);
+
+ m->msg_len_mask = MASK(len_log2);
+
+ m->filled_msg_ptr = 0;
+
+ for (i = 0; i < ri->numPages; i++) {
+ m->msg_ring_pages_pa[i] = ri->ringPPNs[i] << VMW_PAGE_SHIFT;
+ }
+
+ RS_SET_FIELD(m->rs_pa, msgProdIdx, 0);
+ RS_SET_FIELD(m->rs_pa, msgConsIdx, 0);
+ RS_SET_FIELD(m->rs_pa, msgNumEntriesLog2, len_log2);
+
+ trace_pvscsi_ring_init_msg(len_log2);
+
+ /* Flush ring state page changes */
+ smp_wmb();
+}
+
+static void
+pvscsi_ring_cleanup(PVSCSIRingInfo *mgr)
+{
+ mgr->rs_pa = 0;
+ mgr->txr_len_mask = 0;
+ mgr->rxr_len_mask = 0;
+ mgr->msg_len_mask = 0;
+ mgr->consumed_ptr = 0;
+ mgr->filled_cmp_ptr = 0;
+ mgr->filled_msg_ptr = 0;
+ memset(mgr->req_ring_pages_pa, 0, sizeof(mgr->req_ring_pages_pa));
+ memset(mgr->cmp_ring_pages_pa, 0, sizeof(mgr->cmp_ring_pages_pa));
+ memset(mgr->msg_ring_pages_pa, 0, sizeof(mgr->msg_ring_pages_pa));
+}
+
+static hwaddr
+pvscsi_ring_pop_req_descr(PVSCSIRingInfo *mgr)
+{
+ uint32_t ready_ptr = RS_GET_FIELD(mgr->rs_pa, reqProdIdx);
+
+ if (ready_ptr != mgr->consumed_ptr) {
+ uint32_t next_ready_ptr =
+ mgr->consumed_ptr++ & mgr->txr_len_mask;
+ uint32_t next_ready_page =
+ next_ready_ptr / PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE;
+ uint32_t inpage_idx =
+ next_ready_ptr % PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE;
+
+ return mgr->req_ring_pages_pa[next_ready_page] +
+ inpage_idx * sizeof(PVSCSIRingReqDesc);
+ } else {
+ return 0;
+ }
+}
+
+static void
+pvscsi_ring_flush_req(PVSCSIRingInfo *mgr)
+{
+ RS_SET_FIELD(mgr->rs_pa, reqConsIdx, mgr->consumed_ptr);
+}
+
+static hwaddr
+pvscsi_ring_pop_cmp_descr(PVSCSIRingInfo *mgr)
+{
+ /*
+ * According to Linux driver code it explicitly verifies that number
+ * of requests being processed by device is less then the size of
+ * completion queue, so device may omit completion queue overflow
+ * conditions check. We assume that this is true for other (Windows)
+ * drivers as well.
+ */
+
+ uint32_t free_cmp_ptr =
+ mgr->filled_cmp_ptr++ & mgr->rxr_len_mask;
+ uint32_t free_cmp_page =
+ free_cmp_ptr / PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE;
+ uint32_t inpage_idx =
+ free_cmp_ptr % PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE;
+ return mgr->cmp_ring_pages_pa[free_cmp_page] +
+ inpage_idx * sizeof(PVSCSIRingCmpDesc);
+}
+
+static hwaddr
+pvscsi_ring_pop_msg_descr(PVSCSIRingInfo *mgr)
+{
+ uint32_t free_msg_ptr =
+ mgr->filled_msg_ptr++ & mgr->msg_len_mask;
+ uint32_t free_msg_page =
+ free_msg_ptr / PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE;
+ uint32_t inpage_idx =
+ free_msg_ptr % PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE;
+ return mgr->msg_ring_pages_pa[free_msg_page] +
+ inpage_idx * sizeof(PVSCSIRingMsgDesc);
+}
+
+static void
+pvscsi_ring_flush_cmp(PVSCSIRingInfo *mgr)
+{
+ /* Flush descriptor changes */
+ smp_wmb();
+
+ trace_pvscsi_ring_flush_cmp(mgr->filled_cmp_ptr);
+
+ RS_SET_FIELD(mgr->rs_pa, cmpProdIdx, mgr->filled_cmp_ptr);
+}
+
+static bool
+pvscsi_ring_msg_has_room(PVSCSIRingInfo *mgr)
+{
+ uint32_t prodIdx = RS_GET_FIELD(mgr->rs_pa, msgProdIdx);
+ uint32_t consIdx = RS_GET_FIELD(mgr->rs_pa, msgConsIdx);
+
+ return (prodIdx - consIdx) < (mgr->msg_len_mask + 1);
+}
+
+static void
+pvscsi_ring_flush_msg(PVSCSIRingInfo *mgr)
+{
+ /* Flush descriptor changes */
+ smp_wmb();
+
+ trace_pvscsi_ring_flush_msg(mgr->filled_msg_ptr);
+
+ RS_SET_FIELD(mgr->rs_pa, msgProdIdx, mgr->filled_msg_ptr);
+}
+
+static void
+pvscsi_reset_state(PVSCSIState *s)
+{
+ s->curr_cmd = PVSCSI_CMD_FIRST;
+ s->curr_cmd_data_cntr = 0;
+ s->reg_command_status = PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
+ s->reg_interrupt_status = 0;
+ pvscsi_ring_cleanup(&s->rings);
+ s->rings_info_valid = FALSE;
+ s->msg_ring_info_valid = FALSE;
+ QTAILQ_INIT(&s->pending_queue);
+ QTAILQ_INIT(&s->completion_queue);
+}
+
+static void
+pvscsi_update_irq_status(PVSCSIState *s)
+{
+ PCIDevice *d = PCI_DEVICE(s);
+ bool should_raise = s->reg_interrupt_enabled & s->reg_interrupt_status;
+
+ trace_pvscsi_update_irq_level(should_raise, s->reg_interrupt_enabled,
+ s->reg_interrupt_status);
+
+ if (s->msi_used && msi_enabled(d)) {
+ if (should_raise) {
+ trace_pvscsi_update_irq_msi();
+ msi_notify(d, PVSCSI_VECTOR_COMPLETION);
+ }
+ return;
+ }
+
+ qemu_set_irq(d->irq[0], !!should_raise);
+}
+
+static void
+pvscsi_raise_completion_interrupt(PVSCSIState *s)
+{
+ s->reg_interrupt_status |= PVSCSI_INTR_CMPL_0;
+
+ /* Memory barrier to flush interrupt status register changes*/
+ smp_wmb();
+
+ pvscsi_update_irq_status(s);
+}
+
+static void
+pvscsi_raise_message_interrupt(PVSCSIState *s)
+{
+ s->reg_interrupt_status |= PVSCSI_INTR_MSG_0;
+
+ /* Memory barrier to flush interrupt status register changes*/
+ smp_wmb();
+
+ pvscsi_update_irq_status(s);
+}
+
+static void
+pvscsi_cmp_ring_put(PVSCSIState *s, struct PVSCSIRingCmpDesc *cmp_desc)
+{
+ hwaddr cmp_descr_pa;
+
+ cmp_descr_pa = pvscsi_ring_pop_cmp_descr(&s->rings);
+ trace_pvscsi_cmp_ring_put(cmp_descr_pa);
+ cpu_physical_memory_write(cmp_descr_pa, (void *)cmp_desc,
+ sizeof(*cmp_desc));
+}
+
+static void
+pvscsi_msg_ring_put(PVSCSIState *s, struct PVSCSIRingMsgDesc *msg_desc)
+{
+ hwaddr msg_descr_pa;
+
+ msg_descr_pa = pvscsi_ring_pop_msg_descr(&s->rings);
+ trace_pvscsi_msg_ring_put(msg_descr_pa);
+ cpu_physical_memory_write(msg_descr_pa, (void *)msg_desc,
+ sizeof(*msg_desc));
+}
+
+static void
+pvscsi_process_completion_queue(void *opaque)
+{
+ PVSCSIState *s = opaque;
+ PVSCSIRequest *pvscsi_req;
+ bool has_completed = false;
+
+ while (!QTAILQ_EMPTY(&s->completion_queue)) {
+ pvscsi_req = QTAILQ_FIRST(&s->completion_queue);
+ QTAILQ_REMOVE(&s->completion_queue, pvscsi_req, next);
+ pvscsi_cmp_ring_put(s, &pvscsi_req->cmp);
+ g_free(pvscsi_req);
+ has_completed++;
+ }
+
+ if (has_completed) {
+ pvscsi_ring_flush_cmp(&s->rings);
+ pvscsi_raise_completion_interrupt(s);
+ }
+}
+
+static void
+pvscsi_reset_adapter(PVSCSIState *s)
+{
+ s->resetting++;
+ qbus_reset_all_fn(&s->bus);
+ s->resetting--;
+ pvscsi_process_completion_queue(s);
+ assert(QTAILQ_EMPTY(&s->pending_queue));
+ pvscsi_reset_state(s);
+}
+
+static void
+pvscsi_schedule_completion_processing(PVSCSIState *s)
+{
+ /* Try putting more complete requests on the ring. */
+ if (!QTAILQ_EMPTY(&s->completion_queue)) {
+ qemu_bh_schedule(s->completion_worker);
+ }
+}
+
+static void
+pvscsi_complete_request(PVSCSIState *s, PVSCSIRequest *r)
+{
+ assert(!r->completed);
+
+ trace_pvscsi_complete_request(r->cmp.context, r->cmp.dataLen,
+ r->sense_key);
+ if (r->sreq != NULL) {
+ scsi_req_unref(r->sreq);
+ r->sreq = NULL;
+ }
+ r->completed = 1;
+ QTAILQ_REMOVE(&s->pending_queue, r, next);
+ QTAILQ_INSERT_TAIL(&s->completion_queue, r, next);
+ pvscsi_schedule_completion_processing(s);
+}
+
+static QEMUSGList *pvscsi_get_sg_list(SCSIRequest *r)
+{
+ PVSCSIRequest *req = r->hba_private;
+
+ trace_pvscsi_get_sg_list(req->sgl.nsg, req->sgl.size);
+
+ return &req->sgl;
+}
+
+static void
+pvscsi_get_next_sg_elem(PVSCSISGState *sg)
+{
+ struct PVSCSISGElement elem;
+
+ cpu_physical_memory_read(sg->elemAddr, (void *)&elem, sizeof(elem));
+ if ((elem.flags & ~PVSCSI_KNOWN_FLAGS) != 0) {
+ /*
+ * There is PVSCSI_SGE_FLAG_CHAIN_ELEMENT flag described in
+ * header file but its value is unknown. This flag requires
+ * additional processing, so we put warning here to catch it
+ * some day and make proper implementation
+ */
+ trace_pvscsi_get_next_sg_elem(elem.flags);
+ }
+
+ sg->elemAddr += sizeof(elem);
+ sg->dataAddr = elem.addr;
+ sg->resid = elem.length;
+}
+
+static void
+pvscsi_write_sense(PVSCSIRequest *r, uint8_t *sense, int len)
+{
+ r->cmp.senseLen = MIN(r->req.senseLen, len);
+ r->sense_key = sense[(sense[0] & 2) ? 1 : 2];
+ cpu_physical_memory_write(r->req.senseAddr, sense, r->cmp.senseLen);
+}
+
+static void
+pvscsi_command_complete(SCSIRequest *req, uint32_t status, size_t resid)
+{
+ PVSCSIRequest *pvscsi_req = req->hba_private;
+ PVSCSIState *s = pvscsi_req->dev;
+
+ if (!pvscsi_req) {
+ trace_pvscsi_command_complete_not_found(req->tag);
+ return;
+ }
+
+ if (resid) {
+ /* Short transfer. */
+ trace_pvscsi_command_complete_data_run();
+ pvscsi_req->cmp.hostStatus = BTSTAT_DATARUN;
+ }
+
+ pvscsi_req->cmp.scsiStatus = status;
+ if (pvscsi_req->cmp.scsiStatus == CHECK_CONDITION) {
+ uint8_t sense[SCSI_SENSE_BUF_SIZE];
+ int sense_len =
+ scsi_req_get_sense(pvscsi_req->sreq, sense, sizeof(sense));
+
+ trace_pvscsi_command_complete_sense_len(sense_len);
+ pvscsi_write_sense(pvscsi_req, sense, sense_len);
+ }
+ qemu_sglist_destroy(&pvscsi_req->sgl);
+ pvscsi_complete_request(s, pvscsi_req);
+}
+
+static void
+pvscsi_send_msg(PVSCSIState *s, SCSIDevice *dev, uint32_t msg_type)
+{
+ if (s->msg_ring_info_valid && pvscsi_ring_msg_has_room(&s->rings)) {
+ PVSCSIMsgDescDevStatusChanged msg = {0};
+
+ msg.type = msg_type;
+ msg.bus = dev->channel;
+ msg.target = dev->id;
+ msg.lun[1] = dev->lun;
+
+ pvscsi_msg_ring_put(s, (PVSCSIRingMsgDesc *)&msg);
+ pvscsi_ring_flush_msg(&s->rings);
+ pvscsi_raise_message_interrupt(s);
+ }
+}
+
+static void
+pvscsi_hotplug(SCSIBus *bus, SCSIDevice *dev)
+{
+ PVSCSIState *s = container_of(bus, PVSCSIState, bus);
+ pvscsi_send_msg(s, dev, PVSCSI_MSG_DEV_ADDED);
+}
+
+static void
+pvscsi_hot_unplug(SCSIBus *bus, SCSIDevice *dev)
+{
+ PVSCSIState *s = container_of(bus, PVSCSIState, bus);
+ pvscsi_send_msg(s, dev, PVSCSI_MSG_DEV_REMOVED);
+}
+
+static void
+pvscsi_request_cancelled(SCSIRequest *req)
+{
+ PVSCSIRequest *pvscsi_req = req->hba_private;
+ PVSCSIState *s = pvscsi_req->dev;
+
+ if (pvscsi_req->completed) {
+ return;
+ }
+
+ if (pvscsi_req->dev->resetting) {
+ pvscsi_req->cmp.hostStatus = BTSTAT_BUSRESET;
+ } else {
+ pvscsi_req->cmp.hostStatus = BTSTAT_ABORTQUEUE;
+ }
+
+ pvscsi_complete_request(s, pvscsi_req);
+}
+
+static SCSIDevice*
+pvscsi_device_find(PVSCSIState *s, int channel, int target,
+ uint8_t *requested_lun, uint8_t *target_lun)
+{
+ if (requested_lun[0] || requested_lun[2] || requested_lun[3] ||
+ requested_lun[4] || requested_lun[5] || requested_lun[6] ||
+ requested_lun[7] || (target > PVSCSI_MAX_DEVS)) {
+ return NULL;
+ } else {
+ *target_lun = requested_lun[1];
+ return scsi_device_find(&s->bus, channel, target, *target_lun);
+ }
+}
+
+static PVSCSIRequest *
+pvscsi_queue_pending_descriptor(PVSCSIState *s, SCSIDevice **d,
+ struct PVSCSIRingReqDesc *descr)
+{
+ PVSCSIRequest *pvscsi_req;
+ uint8_t lun;
+
+ pvscsi_req = g_malloc0(sizeof(*pvscsi_req));
+ pvscsi_req->dev = s;
+ pvscsi_req->req = *descr;
+ pvscsi_req->cmp.context = pvscsi_req->req.context;
+ QTAILQ_INSERT_TAIL(&s->pending_queue, pvscsi_req, next);
+
+ *d = pvscsi_device_find(s, descr->bus, descr->target, descr->lun, &lun);
+ if (*d) {
+ pvscsi_req->lun = lun;
+ }
+
+ return pvscsi_req;
+}
+
+static void
+pvscsi_convert_sglist(PVSCSIRequest *r)
+{
+ int chunk_size;
+ uint64_t data_length = r->req.dataLen;
+ PVSCSISGState sg = r->sg;
+ while (data_length) {
+ while (!sg.resid) {
+ pvscsi_get_next_sg_elem(&sg);
+ trace_pvscsi_convert_sglist(r->req.context, r->sg.dataAddr,
+ r->sg.resid);
+ }
+ assert(data_length > 0);
+ chunk_size = MIN((unsigned) data_length, sg.resid);
+ if (chunk_size) {
+ qemu_sglist_add(&r->sgl, sg.dataAddr, chunk_size);
+ }
+
+ sg.dataAddr += chunk_size;
+ data_length -= chunk_size;
+ sg.resid -= chunk_size;
+ }
+}
+
+static void
+pvscsi_build_sglist(PVSCSIState *s, PVSCSIRequest *r)
+{
+ PCIDevice *d = PCI_DEVICE(s);
+
+ qemu_sglist_init(&r->sgl, 1, pci_dma_context(d));
+ if (r->req.flags & PVSCSI_FLAG_CMD_WITH_SG_LIST) {
+ pvscsi_convert_sglist(r);
+ } else {
+ qemu_sglist_add(&r->sgl, r->req.dataAddr, r->req.dataLen);
+ }
+}
+
+static void
+pvscsi_process_request_descriptor(PVSCSIState *s,
+ struct PVSCSIRingReqDesc *descr)
+{
+ SCSIDevice *d;
+ PVSCSIRequest *r = pvscsi_queue_pending_descriptor(s, &d, descr);
+ int64_t n;
+
+ trace_pvscsi_process_req_descr(descr->cdb[0], descr->context);
+
+ if (!d) {
+ r->cmp.hostStatus = BTSTAT_SELTIMEO;
+ trace_pvscsi_process_req_descr_unknown_device();
+ pvscsi_complete_request(s, r);
+ return;
+ }
+
+ if (descr->flags & PVSCSI_FLAG_CMD_WITH_SG_LIST) {
+ r->sg.elemAddr = descr->dataAddr;
+ }
+
+ r->sreq = scsi_req_new(d, descr->context, r->lun, descr->cdb, r);
+ if (r->sreq->cmd.mode == SCSI_XFER_FROM_DEV &&
+ (descr->flags & PVSCSI_FLAG_CMD_DIR_TODEVICE)) {
+ r->cmp.hostStatus = BTSTAT_BADMSG;
+ trace_pvscsi_process_req_descr_invalid_dir();
+ scsi_req_cancel(r->sreq);
+ return;
+ }
+ if (r->sreq->cmd.mode == SCSI_XFER_TO_DEV &&
+ (descr->flags & PVSCSI_FLAG_CMD_DIR_TOHOST)) {
+ r->cmp.hostStatus = BTSTAT_BADMSG;
+ trace_pvscsi_process_req_descr_invalid_dir();
+ scsi_req_cancel(r->sreq);
+ return;
+ }
+
+ pvscsi_build_sglist(s, r);
+ n = scsi_req_enqueue(r->sreq);
+
+ if (n) {
+ scsi_req_continue(r->sreq);
+ }
+}
+
+static void
+pvscsi_process_io(PVSCSIState *s)
+{
+ PVSCSIRingReqDesc descr;
+ hwaddr next_descr_pa;
+
+ assert(s->rings_info_valid);
+ while ((next_descr_pa = pvscsi_ring_pop_req_descr(&s->rings)) != 0) {
+
+ /* Only read after production index verification */
+ smp_rmb();
+
+ trace_pvscsi_process_io(next_descr_pa);
+ cpu_physical_memory_read(next_descr_pa, &descr, sizeof(descr));
+ pvscsi_process_request_descriptor(s, &descr);
+ }
+
+ pvscsi_ring_flush_req(&s->rings);
+}
+
+static void
+pvscsi_dbg_dump_tx_rings_config(PVSCSICmdDescSetupRings *rc)
+{
+ int i;
+ trace_pvscsi_tx_rings_ppn("Rings State", rc->ringsStatePPN);
+
+ trace_pvscsi_tx_rings_num_pages("Request Ring", rc->reqRingNumPages);
+ for (i = 0; i < rc->reqRingNumPages; i++) {
+ trace_pvscsi_tx_rings_ppn("Request Ring", rc->reqRingPPNs[i]);
+ }
+
+ trace_pvscsi_tx_rings_num_pages("Confirm Ring", rc->cmpRingNumPages);
+ for (i = 0; i < rc->cmpRingNumPages; i++) {
+ trace_pvscsi_tx_rings_ppn("Confirm Ring", rc->reqRingPPNs[i]);
+ }
+}
+
+static uint64_t
+pvscsi_on_cmd_config(PVSCSIState *s)
+{
+ trace_pvscsi_on_cmd_noimpl("PVSCSI_CMD_CONFIG");
+ return PVSCSI_COMMAND_PROCESSING_FAILED;
+}
+
+static uint64_t
+pvscsi_on_cmd_unplug(PVSCSIState *s)
+{
+ trace_pvscsi_on_cmd_noimpl("PVSCSI_CMD_DEVICE_UNPLUG");
+ return PVSCSI_COMMAND_PROCESSING_FAILED;
+}
+
+static uint64_t
+pvscsi_on_issue_scsi(PVSCSIState *s)
+{
+ trace_pvscsi_on_cmd_noimpl("PVSCSI_CMD_ISSUE_SCSI");
+ return PVSCSI_COMMAND_PROCESSING_FAILED;
+}
+
+static uint64_t
+pvscsi_on_cmd_setup_rings(PVSCSIState *s)
+{
+ PVSCSICmdDescSetupRings *rc =
+ (PVSCSICmdDescSetupRings *) s->curr_cmd_data;
+
+ trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_SETUP_RINGS");
+
+ pvscsi_dbg_dump_tx_rings_config(rc);
+ pvscsi_ring_init_data(&s->rings, rc);
+ s->rings_info_valid = TRUE;
+ return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
+}
+
+static uint64_t
+pvscsi_on_cmd_abort(PVSCSIState *s)
+{
+ PVSCSICmdDescAbortCmd *cmd = (PVSCSICmdDescAbortCmd *) s->curr_cmd_data;
+ PVSCSIRequest *r, *next;
+
+ trace_pvscsi_on_cmd_abort(cmd->context, cmd->target);
+
+ QTAILQ_FOREACH_SAFE(r, &s->pending_queue, next, next) {
+ if (r->req.context == cmd->context) {
+ break;
+ }
+ }
+ if (r) {
+ assert(!r->completed);
+ r->cmp.hostStatus = BTSTAT_ABORTQUEUE;
+ scsi_req_cancel(r->sreq);
+ }
+
+ return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
+}
+
+static uint64_t
+pvscsi_on_cmd_unknown(PVSCSIState *s)
+{
+ trace_pvscsi_on_cmd_unknown_data(s->curr_cmd_data[0]);
+ return PVSCSI_COMMAND_PROCESSING_FAILED;
+}
+
+static uint64_t
+pvscsi_on_cmd_reset_device(PVSCSIState *s)
+{
+ uint8_t target_lun = 0;
+ struct PVSCSICmdDescResetDevice *cmd =
+ (struct PVSCSICmdDescResetDevice *) s->curr_cmd_data;
+ SCSIDevice *sdev;
+
+ sdev = pvscsi_device_find(s, 0, cmd->target, cmd->lun, &target_lun);
+
+ trace_pvscsi_on_cmd_reset_dev(cmd->target, (int) target_lun, sdev);
+
+ if (sdev != NULL) {
+ s->resetting++;
+ device_reset(&sdev->qdev);
+ s->resetting--;
+ return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
+ }
+
+ return PVSCSI_COMMAND_PROCESSING_FAILED;
+}
+
+static uint64_t
+pvscsi_on_cmd_reset_bus(PVSCSIState *s)
+{
+ trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_RESET_BUS");
+
+ s->resetting++;
+ qbus_reset_all_fn(&s->bus);
+ s->resetting--;
+ return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
+}
+
+static uint64_t
+pvscsi_on_cmd_setup_msg_ring(PVSCSIState *s)
+{
+ PVSCSICmdDescSetupMsgRing *rc =
+ (PVSCSICmdDescSetupMsgRing *) s->curr_cmd_data;
+
+ trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_SETUP_MSG_RING");
+
+ if (!s->use_msg) {
+ return PVSCSI_COMMAND_PROCESSING_FAILED;
+ }
+
+ if (s->rings_info_valid) {
+ pvscsi_ring_init_msg(&s->rings, rc);
+ s->msg_ring_info_valid = TRUE;
+ }
+ return sizeof(PVSCSICmdDescSetupMsgRing) / sizeof(uint32_t);
+}
+
+static uint64_t
+pvscsi_on_cmd_adapter_reset(PVSCSIState *s)
+{
+ trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_ADAPTER_RESET");
+
+ pvscsi_reset_adapter(s);
+ return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
+}
+
+static const struct {
+ int data_size;
+ uint64_t (*handler_fn)(PVSCSIState *s);
+} pvscsi_commands[] = {
+ [PVSCSI_CMD_FIRST] = {
+ .data_size = 0,
+ .handler_fn = pvscsi_on_cmd_unknown,
+ },
+
+ /* Not implemented, data size defined based on what arrives on windows */
+ [PVSCSI_CMD_CONFIG] = {
+ .data_size = 6 * sizeof(uint32_t),
+ .handler_fn = pvscsi_on_cmd_config,
+ },
+
+ /* Command not implemented, data size is unknown */
+ [PVSCSI_CMD_ISSUE_SCSI] = {
+ .data_size = 0,
+ .handler_fn = pvscsi_on_issue_scsi,
+ },
+
+ /* Command not implemented, data size is unknown */
+ [PVSCSI_CMD_DEVICE_UNPLUG] = {
+ .data_size = 0,
+ .handler_fn = pvscsi_on_cmd_unplug,
+ },
+
+ [PVSCSI_CMD_SETUP_RINGS] = {
+ .data_size = sizeof(PVSCSICmdDescSetupRings),
+ .handler_fn = pvscsi_on_cmd_setup_rings,
+ },
+
+ [PVSCSI_CMD_RESET_DEVICE] = {
+ .data_size = sizeof(struct PVSCSICmdDescResetDevice),
+ .handler_fn = pvscsi_on_cmd_reset_device,
+ },
+
+ [PVSCSI_CMD_RESET_BUS] = {
+ .data_size = 0,
+ .handler_fn = pvscsi_on_cmd_reset_bus,
+ },
+
+ [PVSCSI_CMD_SETUP_MSG_RING] = {
+ .data_size = sizeof(PVSCSICmdDescSetupMsgRing),
+ .handler_fn = pvscsi_on_cmd_setup_msg_ring,
+ },
+
+ [PVSCSI_CMD_ADAPTER_RESET] = {
+ .data_size = 0,
+ .handler_fn = pvscsi_on_cmd_adapter_reset,
+ },
+
+ [PVSCSI_CMD_ABORT_CMD] = {
+ .data_size = sizeof(struct PVSCSICmdDescAbortCmd),
+ .handler_fn = pvscsi_on_cmd_abort,
+ },
+};
+
+static void
+pvscsi_do_command_processing(PVSCSIState *s)
+{
+ size_t bytes_arrived = s->curr_cmd_data_cntr * sizeof(uint32_t);
+
+ assert(s->curr_cmd < PVSCSI_CMD_LAST);
+ if (bytes_arrived >= pvscsi_commands[s->curr_cmd].data_size) {
+ s->reg_command_status = pvscsi_commands[s->curr_cmd].handler_fn(s);
+ s->curr_cmd = PVSCSI_CMD_FIRST;
+ s->curr_cmd_data_cntr = 0;
+ }
+}
+
+static void
+pvscsi_on_command_data(PVSCSIState *s, uint32_t value)
+{
+ size_t bytes_arrived = s->curr_cmd_data_cntr * sizeof(uint32_t);
+
+ assert(bytes_arrived < sizeof(s->curr_cmd_data));
+ s->curr_cmd_data[s->curr_cmd_data_cntr++] = value;
+
+ pvscsi_do_command_processing(s);
+}
+
+static void
+pvscsi_on_command(PVSCSIState *s, uint64_t cmd_id)
+{
+ if ((cmd_id > PVSCSI_CMD_FIRST) && (cmd_id < PVSCSI_CMD_LAST)) {
+ s->curr_cmd = cmd_id;
+ } else {
+ s->curr_cmd = PVSCSI_CMD_FIRST;
+ trace_pvscsi_on_cmd_unknown(cmd_id);
+ }
+
+ s->curr_cmd_data_cntr = 0;
+ s->reg_command_status = PVSCSI_COMMAND_NOT_ENOUGH_DATA;
+
+ pvscsi_do_command_processing(s);
+}
+
+static void
+pvscsi_io_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned size)
+{
+ PVSCSIState *s = opaque;
+
+ switch (addr) {
+ case PVSCSI_REG_OFFSET_COMMAND:
+ pvscsi_on_command(s, val);
+ break;
+
+ case PVSCSI_REG_OFFSET_COMMAND_DATA:
+ pvscsi_on_command_data(s, (uint32_t) val);
+ break;
+
+ case PVSCSI_REG_OFFSET_INTR_STATUS:
+ trace_pvscsi_io_write("PVSCSI_REG_OFFSET_INTR_STATUS", val);
+ s->reg_interrupt_status &= ~val;
+ pvscsi_update_irq_status(s);
+ pvscsi_schedule_completion_processing(s);
+ break;
+
+ case PVSCSI_REG_OFFSET_INTR_MASK:
+ trace_pvscsi_io_write("PVSCSI_REG_OFFSET_INTR_MASK", val);
+ s->reg_interrupt_enabled = val;
+ pvscsi_update_irq_status(s);
+ break;
+
+ case PVSCSI_REG_OFFSET_KICK_NON_RW_IO:
+ trace_pvscsi_io_write("PVSCSI_REG_OFFSET_KICK_NON_RW_IO", val);
+ pvscsi_process_io(s);
+ break;
+
+ case PVSCSI_REG_OFFSET_KICK_RW_IO:
+ trace_pvscsi_io_write("PVSCSI_REG_OFFSET_KICK_RW_IO", val);
+ pvscsi_process_io(s);
+ break;
+
+ case PVSCSI_REG_OFFSET_DEBUG:
+ trace_pvscsi_io_write("PVSCSI_REG_OFFSET_DEBUG", val);
+ break;
+
+ default:
+ trace_pvscsi_io_write_unknown(addr, size, val);
+ break;
+ }
+
+}
+
+static uint64_t
+pvscsi_io_read(void *opaque, hwaddr addr, unsigned size)
+{
+ PVSCSIState *s = opaque;
+
+ switch (addr) {
+ case PVSCSI_REG_OFFSET_INTR_STATUS:
+ trace_pvscsi_io_read("PVSCSI_REG_OFFSET_INTR_STATUS",
+ s->reg_interrupt_status);
+ return s->reg_interrupt_status;
+
+ case PVSCSI_REG_OFFSET_INTR_MASK:
+ trace_pvscsi_io_read("PVSCSI_REG_OFFSET_INTR_MASK",
+ s->reg_interrupt_status);
+ return s->reg_interrupt_enabled;
+
+ case PVSCSI_REG_OFFSET_COMMAND_STATUS:
+ trace_pvscsi_io_read("PVSCSI_REG_OFFSET_COMMAND_STATUS",
+ s->reg_interrupt_status);
+ return s->reg_command_status;
+
+ default:
+ trace_pvscsi_io_read_unknown(addr, size);
+ return 0;
+ }
+}
+
+
+static bool
+pvscsi_init_msi(PVSCSIState *s)
+{
+ int res;
+ PCIDevice *d = PCI_DEVICE(s);
+
+ res = msi_init(d, PVSCSI_MSI_OFFSET, PVSCSI_MSIX_NUM_VECTORS,
+ PVSCSI_USE_64BIT, PVSCSI_PER_VECTOR_MASK);
+ if (res < 0) {
+ trace_pvscsi_init_msi_fail(res);
+ s->msi_used = false;
+ } else {
+ s->msi_used = true;
+ }
+
+ return s->msi_used;
+}
+
+static void
+pvscsi_cleanup_msi(PVSCSIState *s)
+{
+ PCIDevice *d = PCI_DEVICE(s);
+
+ if (s->msi_used) {
+ msi_uninit(d);
+ }
+}
+
+static const MemoryRegionOps pvscsi_ops = {
+ .read = pvscsi_io_read,
+ .write = pvscsi_io_write,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+ .impl = {
+ .min_access_size = 4,
+ .max_access_size = 4,
+ },
+};
+
+static const struct SCSIBusInfo pvscsi_scsi_info = {
+ .tcq = true,
+ .max_target = PVSCSI_MAX_DEVS,
+ .max_channel = 0,
+ .max_lun = 0,
+
+ .get_sg_list = pvscsi_get_sg_list,
+ .complete = pvscsi_command_complete,
+ .cancel = pvscsi_request_cancelled,
+ .hotplug = pvscsi_hotplug,
+ .hot_unplug = pvscsi_hot_unplug,
+};
+
+static int
+pvscsi_init(PCIDevice *pci_dev)
+{
+ PVSCSIState *s = PVSCSI(pci_dev);
+
+ trace_pvscsi_state("init");
+
+ /* PCI subsystem ID */
+ pci_dev->config[PCI_SUBSYSTEM_ID] = 0x00;
+ pci_dev->config[PCI_SUBSYSTEM_ID + 1] = 0x10;
+
+ /* PCI latency timer = 255 */
+ pci_dev->config[PCI_LATENCY_TIMER] = 0xff;
+
+ /* Interrupt pin A */
+ pci_config_set_interrupt_pin(pci_dev->config, 1);
+
+ memory_region_init_io(&s->io_space, &pvscsi_ops, s,
+ "pvscsi-io", PVSCSI_MEM_SPACE_SIZE);
+ pci_register_bar(pci_dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->io_space);
+
+ pvscsi_init_msi(s);
+
+ s->completion_worker = qemu_bh_new(pvscsi_process_completion_queue, s);
+ if (!s->completion_worker) {
+ pvscsi_cleanup_msi(s);
+ memory_region_destroy(&s->io_space);
+ return -ENOMEM;
+ }
+
+ scsi_bus_new(&s->bus, &pci_dev->qdev, &pvscsi_scsi_info);
+ pvscsi_reset_state(s);
+
+ return 0;
+}
+
+static void
+pvscsi_uninit(PCIDevice *pci_dev)
+{
+ PVSCSIState *s = PVSCSI(pci_dev);
+
+ trace_pvscsi_state("uninit");
+ qemu_bh_delete(s->completion_worker);
+
+ pvscsi_cleanup_msi(s);
+
+ memory_region_destroy(&s->io_space);
+}
+
+static void
+pvscsi_reset(DeviceState *dev)
+{
+ PCIDevice *d = PCI_DEVICE(dev);
+ PVSCSIState *s = PVSCSI(d);
+
+ trace_pvscsi_state("reset");
+ pvscsi_reset_adapter(s);
+}
+
+static void
+pvscsi_pre_save(void *opaque)
+{
+ PVSCSIState *s = (PVSCSIState *) opaque;
+
+ trace_pvscsi_state("presave");
+
+ assert(QTAILQ_EMPTY(&s->pending_queue));
+ assert(QTAILQ_EMPTY(&s->completion_queue));
+}
+
+static int
+pvscsi_post_load(void *opaque, int version_id)
+{
+ trace_pvscsi_state("postload");
+ return 0;
+}
+
+static const VMStateDescription vmstate_pvscsi = {
+ .name = TYPE_PVSCSI,
+ .version_id = 0,
+ .minimum_version_id = 0,
+ .minimum_version_id_old = 0,
+ .pre_save = pvscsi_pre_save,
+ .post_load = pvscsi_post_load,
+ .fields = (VMStateField[]) {
+ VMSTATE_PCI_DEVICE(parent_obj, PVSCSIState),
+ VMSTATE_UINT8(msi_used, PVSCSIState),
+ VMSTATE_UINT32(resetting, PVSCSIState),
+ VMSTATE_UINT64(reg_interrupt_status, PVSCSIState),
+ VMSTATE_UINT64(reg_interrupt_enabled, PVSCSIState),
+ VMSTATE_UINT64(reg_command_status, PVSCSIState),
+ VMSTATE_UINT64(curr_cmd, PVSCSIState),
+ VMSTATE_UINT32(curr_cmd_data_cntr, PVSCSIState),
+ VMSTATE_UINT32_ARRAY(curr_cmd_data, PVSCSIState,
+ ARRAY_SIZE(((PVSCSIState *)NULL)->curr_cmd_data)),
+ VMSTATE_UINT8(rings_info_valid, PVSCSIState),
+ VMSTATE_UINT8(msg_ring_info_valid, PVSCSIState),
+ VMSTATE_UINT8(use_msg, PVSCSIState),
+
+ VMSTATE_UINT64(rings.rs_pa, PVSCSIState),
+ VMSTATE_UINT32(rings.txr_len_mask, PVSCSIState),
+ VMSTATE_UINT32(rings.rxr_len_mask, PVSCSIState),
+ VMSTATE_UINT64_ARRAY(rings.req_ring_pages_pa, PVSCSIState,
+ PVSCSI_SETUP_RINGS_MAX_NUM_PAGES),
+ VMSTATE_UINT64_ARRAY(rings.cmp_ring_pages_pa, PVSCSIState,
+ PVSCSI_SETUP_RINGS_MAX_NUM_PAGES),
+ VMSTATE_UINT64(rings.consumed_ptr, PVSCSIState),
+ VMSTATE_UINT64(rings.filled_cmp_ptr, PVSCSIState),
+
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static void
+pvscsi_write_config(PCIDevice *pci, uint32_t addr, uint32_t val, int len)
+{
+ pci_default_write_config(pci, addr, val, len);
+ msi_write_config(pci, addr, val, len);
+}
+
+static Property pvscsi_properties[] = {
+ DEFINE_PROP_UINT8("use_msg", PVSCSIState, use_msg, 1),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pvscsi_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+ k->init = pvscsi_init;
+ k->exit = pvscsi_uninit;
+ k->vendor_id = PCI_VENDOR_ID_VMWARE;
+ k->device_id = PCI_DEVICE_ID_VMWARE_PVSCSI;
+ k->class_id = PCI_CLASS_STORAGE_SCSI;
+ k->subsystem_id = 0x1000;
+ dc->reset = pvscsi_reset;
+ dc->vmsd = &vmstate_pvscsi;
+ dc->props = pvscsi_properties;
+ k->config_write = pvscsi_write_config;
+}
+
+static const TypeInfo pvscsi_info = {
+ .name = "pvscsi",
+ .parent = TYPE_PCI_DEVICE,
+ .instance_size = sizeof(PVSCSIState),
+ .class_init = pvscsi_class_init,
+};
+
+static void
+pvscsi_register_types(void)
+{
+ type_register_static(&pvscsi_info);
+}
+
+type_init(pvscsi_register_types);
diff --git a/hw/scsi/vmw_pvscsi.h b/hw/scsi/vmw_pvscsi.h
new file mode 100644
index 0000000..17fcf66
--- /dev/null
+++ b/hw/scsi/vmw_pvscsi.h
@@ -0,0 +1,434 @@
+/*
+ * VMware PVSCSI header file
+ *
+ * Copyright (C) 2008-2009, VMware, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; version 2 of the License and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Maintained by: Arvind Kumar <arvindkumar@vmware.com>
+ *
+ */
+
+#ifndef VMW_PVSCSI_H
+#define VMW_PVSCSI_H
+
+#define VMW_PAGE_SIZE (4096)
+#define VMW_PAGE_SHIFT (12)
+
+#define MASK(n) ((1 << (n)) - 1) /* make an n-bit mask */
+
+/*
+ * host adapter status/error codes
+ */
+enum HostBusAdapterStatus {
+ BTSTAT_SUCCESS = 0x00, /* CCB complete normally with no errors */
+ BTSTAT_LINKED_COMMAND_COMPLETED = 0x0a,
+ BTSTAT_LINKED_COMMAND_COMPLETED_WITH_FLAG = 0x0b,
+ BTSTAT_DATA_UNDERRUN = 0x0c,
+ BTSTAT_SELTIMEO = 0x11, /* SCSI selection timeout */
+ BTSTAT_DATARUN = 0x12, /* data overrun/underrun */
+ BTSTAT_BUSFREE = 0x13, /* unexpected bus free */
+ BTSTAT_INVPHASE = 0x14, /* invalid bus phase or sequence */
+ /* requested by target */
+ BTSTAT_LUNMISMATCH = 0x17, /* linked CCB has different LUN */
+ /* from first CCB */
+ BTSTAT_SENSFAILED = 0x1b, /* auto request sense failed */
+ BTSTAT_TAGREJECT = 0x1c, /* SCSI II tagged queueing message */
+ /* rejected by target */
+ BTSTAT_BADMSG = 0x1d, /* unsupported message received by */
+ /* the host adapter */
+ BTSTAT_HAHARDWARE = 0x20, /* host adapter hardware failed */
+ BTSTAT_NORESPONSE = 0x21, /* target did not respond to SCSI ATN, */
+ /* sent a SCSI RST */
+ BTSTAT_SENTRST = 0x22, /* host adapter asserted a SCSI RST */
+ BTSTAT_RECVRST = 0x23, /* other SCSI devices asserted a SCSI RST */
+ BTSTAT_DISCONNECT = 0x24, /* target device reconnected improperly */
+ /* (w/o tag) */
+ BTSTAT_BUSRESET = 0x25, /* host adapter issued BUS device reset */
+ BTSTAT_ABORTQUEUE = 0x26, /* abort queue generated */
+ BTSTAT_HASOFTWARE = 0x27, /* host adapter software error */
+ BTSTAT_HATIMEOUT = 0x30, /* host adapter hardware timeout error */
+ BTSTAT_SCSIPARITY = 0x34, /* SCSI parity error detected */
+};
+
+/*
+ * Register offsets.
+ *
+ * These registers are accessible both via i/o space and mm i/o.
+ */
+
+enum PVSCSIRegOffset {
+ PVSCSI_REG_OFFSET_COMMAND = 0x0,
+ PVSCSI_REG_OFFSET_COMMAND_DATA = 0x4,
+ PVSCSI_REG_OFFSET_COMMAND_STATUS = 0x8,
+ PVSCSI_REG_OFFSET_LAST_STS_0 = 0x100,
+ PVSCSI_REG_OFFSET_LAST_STS_1 = 0x104,
+ PVSCSI_REG_OFFSET_LAST_STS_2 = 0x108,
+ PVSCSI_REG_OFFSET_LAST_STS_3 = 0x10c,
+ PVSCSI_REG_OFFSET_INTR_STATUS = 0x100c,
+ PVSCSI_REG_OFFSET_INTR_MASK = 0x2010,
+ PVSCSI_REG_OFFSET_KICK_NON_RW_IO = 0x3014,
+ PVSCSI_REG_OFFSET_DEBUG = 0x3018,
+ PVSCSI_REG_OFFSET_KICK_RW_IO = 0x4018,
+};
+
+/*
+ * Virtual h/w commands.
+ */
+
+enum PVSCSICommands {
+ PVSCSI_CMD_FIRST = 0, /* has to be first */
+
+ PVSCSI_CMD_ADAPTER_RESET = 1,
+ PVSCSI_CMD_ISSUE_SCSI = 2,
+ PVSCSI_CMD_SETUP_RINGS = 3,
+ PVSCSI_CMD_RESET_BUS = 4,
+ PVSCSI_CMD_RESET_DEVICE = 5,
+ PVSCSI_CMD_ABORT_CMD = 6,
+ PVSCSI_CMD_CONFIG = 7,
+ PVSCSI_CMD_SETUP_MSG_RING = 8,
+ PVSCSI_CMD_DEVICE_UNPLUG = 9,
+
+ PVSCSI_CMD_LAST = 10 /* has to be last */
+};
+
+#define PVSCSI_COMMAND_PROCESSING_SUCCEEDED (0)
+#define PVSCSI_COMMAND_PROCESSING_FAILED (-1)
+#define PVSCSI_COMMAND_NOT_ENOUGH_DATA (-2)
+
+/*
+ * Command descriptor for PVSCSI_CMD_RESET_DEVICE --
+ */
+
+struct PVSCSICmdDescResetDevice {
+ uint32_t target;
+ uint8_t lun[8];
+} QEMU_PACKED;
+
+typedef struct PVSCSICmdDescResetDevice PVSCSICmdDescResetDevice;
+
+/*
+ * Command descriptor for PVSCSI_CMD_ABORT_CMD --
+ *
+ * - currently does not support specifying the LUN.
+ * - pad should be 0.
+ */
+
+struct PVSCSICmdDescAbortCmd {
+ uint64_t context;
+ uint32_t target;
+ uint32_t pad;
+} QEMU_PACKED;
+
+typedef struct PVSCSICmdDescAbortCmd PVSCSICmdDescAbortCmd;
+
+/*
+ * Command descriptor for PVSCSI_CMD_SETUP_RINGS --
+ *
+ * Notes:
+ * - reqRingNumPages and cmpRingNumPages need to be power of two.
+ * - reqRingNumPages and cmpRingNumPages need to be different from 0,
+ * - reqRingNumPages and cmpRingNumPages need to be inferior to
+ * PVSCSI_SETUP_RINGS_MAX_NUM_PAGES.
+ */
+
+#define PVSCSI_SETUP_RINGS_MAX_NUM_PAGES 32
+struct PVSCSICmdDescSetupRings {
+ uint32_t reqRingNumPages;
+ uint32_t cmpRingNumPages;
+ uint64_t ringsStatePPN;
+ uint64_t reqRingPPNs[PVSCSI_SETUP_RINGS_MAX_NUM_PAGES];
+ uint64_t cmpRingPPNs[PVSCSI_SETUP_RINGS_MAX_NUM_PAGES];
+} QEMU_PACKED;
+
+typedef struct PVSCSICmdDescSetupRings PVSCSICmdDescSetupRings;
+
+/*
+ * Command descriptor for PVSCSI_CMD_SETUP_MSG_RING --
+ *
+ * Notes:
+ * - this command was not supported in the initial revision of the h/w
+ * interface. Before using it, you need to check that it is supported by
+ * writing PVSCSI_CMD_SETUP_MSG_RING to the 'command' register, then
+ * immediately after read the 'command status' register:
+ * * a value of -1 means that the cmd is NOT supported,
+ * * a value != -1 means that the cmd IS supported.
+ * If it's supported the 'command status' register should return:
+ * sizeof(PVSCSICmdDescSetupMsgRing) / sizeof(uint32_t).
+ * - this command should be issued _after_ the usual SETUP_RINGS so that the
+ * RingsState page is already setup. If not, the command is a nop.
+ * - numPages needs to be a power of two,
+ * - numPages needs to be different from 0,
+ * - pad should be zero.
+ */
+
+#define PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES 16
+
+struct PVSCSICmdDescSetupMsgRing {
+ uint32_t numPages;
+ uint32_t pad;
+ uint64_t ringPPNs[PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES];
+} QEMU_PACKED;
+
+typedef struct PVSCSICmdDescSetupMsgRing PVSCSICmdDescSetupMsgRing;
+
+enum PVSCSIMsgType {
+ PVSCSI_MSG_DEV_ADDED = 0,
+ PVSCSI_MSG_DEV_REMOVED = 1,
+ PVSCSI_MSG_LAST = 2,
+};
+
+/*
+ * Msg descriptor.
+ *
+ * sizeof(struct PVSCSIRingMsgDesc) == 128.
+ *
+ * - type is of type enum PVSCSIMsgType.
+ * - the content of args depend on the type of event being delivered.
+ */
+
+struct PVSCSIRingMsgDesc {
+ uint32_t type;
+ uint32_t args[31];
+} QEMU_PACKED;
+
+typedef struct PVSCSIRingMsgDesc PVSCSIRingMsgDesc;
+
+struct PVSCSIMsgDescDevStatusChanged {
+ uint32_t type; /* PVSCSI_MSG_DEV _ADDED / _REMOVED */
+ uint32_t bus;
+ uint32_t target;
+ uint8_t lun[8];
+ uint32_t pad[27];
+} QEMU_PACKED;
+
+typedef struct PVSCSIMsgDescDevStatusChanged PVSCSIMsgDescDevStatusChanged;
+
+/*
+ * Rings state.
+ *
+ * - the fields:
+ * . msgProdIdx,
+ * . msgConsIdx,
+ * . msgNumEntriesLog2,
+ * .. are only used once the SETUP_MSG_RING cmd has been issued.
+ * - 'pad' helps to ensure that the msg related fields are on their own
+ * cache-line.
+ */
+
+struct PVSCSIRingsState {
+ uint32_t reqProdIdx;
+ uint32_t reqConsIdx;
+ uint32_t reqNumEntriesLog2;
+
+ uint32_t cmpProdIdx;
+ uint32_t cmpConsIdx;
+ uint32_t cmpNumEntriesLog2;
+
+ uint8_t pad[104];
+
+ uint32_t msgProdIdx;
+ uint32_t msgConsIdx;
+ uint32_t msgNumEntriesLog2;
+} QEMU_PACKED;
+
+typedef struct PVSCSIRingsState PVSCSIRingsState;
+
+/*
+ * Request descriptor.
+ *
+ * sizeof(RingReqDesc) = 128
+ *
+ * - context: is a unique identifier of a command. It could normally be any
+ * 64bit value, however we currently store it in the serialNumber variable
+ * of struct SCSI_Command, so we have the following restrictions due to the
+ * way this field is handled in the vmkernel storage stack:
+ * * this value can't be 0,
+ * * the upper 32bit need to be 0 since serialNumber is as a uint32_t.
+ * Currently tracked as PR 292060.
+ * - dataLen: contains the total number of bytes that need to be transferred.
+ * - dataAddr:
+ * * if PVSCSI_FLAG_CMD_WITH_SG_LIST is set: dataAddr is the PA of the first
+ * s/g table segment, each s/g segment is entirely contained on a single
+ * page of physical memory,
+ * * if PVSCSI_FLAG_CMD_WITH_SG_LIST is NOT set, then dataAddr is the PA of
+ * the buffer used for the DMA transfer,
+ * - flags:
+ * * PVSCSI_FLAG_CMD_WITH_SG_LIST: see dataAddr above,
+ * * PVSCSI_FLAG_CMD_DIR_NONE: no DMA involved,
+ * * PVSCSI_FLAG_CMD_DIR_TOHOST: transfer from device to main memory,
+ * * PVSCSI_FLAG_CMD_DIR_TODEVICE: transfer from main memory to device,
+ * * PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB: reserved to handle CDBs larger than
+ * 16bytes. To be specified.
+ * - vcpuHint: vcpuId of the processor that will be most likely waiting for the
+ * completion of the i/o. For guest OSes that use lowest priority message
+ * delivery mode (such as windows), we use this "hint" to deliver the
+ * completion action to the proper vcpu. For now, we can use the vcpuId of
+ * the processor that initiated the i/o as a likely candidate for the vcpu
+ * that will be waiting for the completion..
+ * - bus should be 0: we currently only support bus 0 for now.
+ * - unused should be zero'd.
+ */
+
+#define PVSCSI_FLAG_CMD_WITH_SG_LIST (1 << 0)
+#define PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB (1 << 1)
+#define PVSCSI_FLAG_CMD_DIR_NONE (1 << 2)
+#define PVSCSI_FLAG_CMD_DIR_TOHOST (1 << 3)
+#define PVSCSI_FLAG_CMD_DIR_TODEVICE (1 << 4)
+
+#define PVSCSI_KNOWN_FLAGS \
+ (PVSCSI_FLAG_CMD_WITH_SG_LIST | \
+ PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB | \
+ PVSCSI_FLAG_CMD_DIR_NONE | \
+ PVSCSI_FLAG_CMD_DIR_TOHOST | \
+ PVSCSI_FLAG_CMD_DIR_TODEVICE)
+
+struct PVSCSIRingReqDesc {
+ uint64_t context;
+ uint64_t dataAddr;
+ uint64_t dataLen;
+ uint64_t senseAddr;
+ uint32_t senseLen;
+ uint32_t flags;
+ uint8_t cdb[16];
+ uint8_t cdbLen;
+ uint8_t lun[8];
+ uint8_t tag;
+ uint8_t bus;
+ uint8_t target;
+ uint8_t vcpuHint;
+ uint8_t unused[59];
+} QEMU_PACKED;
+
+typedef struct PVSCSIRingReqDesc PVSCSIRingReqDesc;
+
+/*
+ * Scatter-gather list management.
+ *
+ * As described above, when PVSCSI_FLAG_CMD_WITH_SG_LIST is set in the
+ * RingReqDesc.flags, then RingReqDesc.dataAddr is the PA of the first s/g
+ * table segment.
+ *
+ * - each segment of the s/g table contain a succession of struct
+ * PVSCSISGElement.
+ * - each segment is entirely contained on a single physical page of memory.
+ * - a "chain" s/g element has the flag PVSCSI_SGE_FLAG_CHAIN_ELEMENT set in
+ * PVSCSISGElement.flags and in this case:
+ * * addr is the PA of the next s/g segment,
+ * * length is undefined, assumed to be 0.
+ */
+
+struct PVSCSISGElement {
+ uint64_t addr;
+ uint32_t length;
+ uint32_t flags;
+} QEMU_PACKED;
+
+typedef struct PVSCSISGElement PVSCSISGElement;
+
+/*
+ * Completion descriptor.
+ *
+ * sizeof(RingCmpDesc) = 32
+ *
+ * - context: identifier of the command. The same thing that was specified
+ * under "context" as part of struct RingReqDesc at initiation time,
+ * - dataLen: number of bytes transferred for the actual i/o operation,
+ * - senseLen: number of bytes written into the sense buffer,
+ * - hostStatus: adapter status,
+ * - scsiStatus: device status,
+ * - pad should be zero.
+ */
+
+struct PVSCSIRingCmpDesc {
+ uint64_t context;
+ uint64_t dataLen;
+ uint32_t senseLen;
+ uint16_t hostStatus;
+ uint16_t scsiStatus;
+ uint32_t pad[2];
+} QEMU_PACKED;
+
+typedef struct PVSCSIRingCmpDesc PVSCSIRingCmpDesc;
+
+/*
+ * Interrupt status / IRQ bits.
+ */
+
+#define PVSCSI_INTR_CMPL_0 (1 << 0)
+#define PVSCSI_INTR_CMPL_1 (1 << 1)
+#define PVSCSI_INTR_CMPL_MASK MASK(2)
+
+#define PVSCSI_INTR_MSG_0 (1 << 2)
+#define PVSCSI_INTR_MSG_1 (1 << 3)
+#define PVSCSI_INTR_MSG_MASK (MASK(2) << 2)
+
+#define PVSCSI_INTR_ALL_SUPPORTED MASK(4)
+
+/*
+ * Number of MSI-X vectors supported.
+ */
+#define PVSCSI_MAX_INTRS 24
+
+/*
+ * Enumeration of supported MSI-X vectors
+ */
+#define PVSCSI_VECTOR_COMPLETION 0
+
+/*
+ * Misc constants for the rings.
+ */
+
+#define PVSCSI_MAX_NUM_PAGES_REQ_RING PVSCSI_SETUP_RINGS_MAX_NUM_PAGES
+#define PVSCSI_MAX_NUM_PAGES_CMP_RING PVSCSI_SETUP_RINGS_MAX_NUM_PAGES
+#define PVSCSI_MAX_NUM_PAGES_MSG_RING PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES
+
+#define PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE \
+ (VMW_PAGE_SIZE / sizeof(struct PVSCSIRingReqDesc))
+
+#define PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE \
+ (VMW_PAGE_SIZE / sizeof(PVSCSIRingCmpDesc))
+
+#define PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE \
+ (VMW_PAGE_SIZE / sizeof(PVSCSIRingMsgDesc))
+
+#define PVSCSI_MAX_REQ_QUEUE_DEPTH \
+ (PVSCSI_MAX_NUM_PAGES_REQ_RING * PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE)
+
+#define PVSCSI_MEM_SPACE_COMMAND_NUM_PAGES 1
+#define PVSCSI_MEM_SPACE_INTR_STATUS_NUM_PAGES 1
+#define PVSCSI_MEM_SPACE_MISC_NUM_PAGES 2
+#define PVSCSI_MEM_SPACE_KICK_IO_NUM_PAGES 2
+#define PVSCSI_MEM_SPACE_MSIX_NUM_PAGES 2
+
+enum PVSCSIMemSpace {
+ PVSCSI_MEM_SPACE_COMMAND_PAGE = 0,
+ PVSCSI_MEM_SPACE_INTR_STATUS_PAGE = 1,
+ PVSCSI_MEM_SPACE_MISC_PAGE = 2,
+ PVSCSI_MEM_SPACE_KICK_IO_PAGE = 4,
+ PVSCSI_MEM_SPACE_MSIX_TABLE_PAGE = 6,
+ PVSCSI_MEM_SPACE_MSIX_PBA_PAGE = 7,
+};
+
+#define PVSCSI_MEM_SPACE_NUM_PAGES \
+ (PVSCSI_MEM_SPACE_COMMAND_NUM_PAGES + \
+ PVSCSI_MEM_SPACE_INTR_STATUS_NUM_PAGES + \
+ PVSCSI_MEM_SPACE_MISC_NUM_PAGES + \
+ PVSCSI_MEM_SPACE_KICK_IO_NUM_PAGES + \
+ PVSCSI_MEM_SPACE_MSIX_NUM_PAGES)
+
+#define PVSCSI_MEM_SPACE_SIZE (PVSCSI_MEM_SPACE_NUM_PAGES * VMW_PAGE_SIZE)
+
+#endif /* VMW_PVSCSI_H */
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 05315c0..2c138b1 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -59,6 +59,7 @@
#define PCI_DEVICE_ID_VMWARE_SVGA 0x0710
#define PCI_DEVICE_ID_VMWARE_NET 0x0720
#define PCI_DEVICE_ID_VMWARE_SCSI 0x0730
+#define PCI_DEVICE_ID_VMWARE_PVSCSI 0x07C0
#define PCI_DEVICE_ID_VMWARE_IDE 0x1729
#define PCI_DEVICE_ID_VMWARE_VMXNET3 0x07B0
diff --git a/trace-events b/trace-events
index 581d67a..e587487 100644
--- a/trace-events
+++ b/trace-events
@@ -766,6 +766,41 @@ pc87312_info_ide(uint32_t base) "base 0x%x"
pc87312_info_parallel(uint32_t base, uint32_t irq) "base 0x%x, irq %u"
pc87312_info_serial(int n, uint32_t base, uint32_t irq) "id=%d, base 0x%x, irq %u"
+# hw/scsi/vmw_pvscsi.c
+pvscsi_ring_init_data(uint32_t txr_len_log2, uint32_t rxr_len_log2) "TX/RX rings logarithms set to %d/%d"
+pvscsi_ring_init_msg(uint32_t len_log2) "MSG ring logarithm set to %d"
+pvscsi_ring_flush_cmp(uint64_t filled_cmp_ptr) "new production counter of completion ring is 0x%"PRIx64""
+pvscsi_ring_flush_msg(uint64_t filled_cmp_ptr) "new production counter of message ring is 0x%"PRIx64""
+pvscsi_update_irq_level(bool raise, uint64_t mask, uint64_t status) "interrupt level set to %d (MASK: 0x%"PRIx64", STATUS: 0x%"PRIx64")"
+pvscsi_update_irq_msi(void) "sending MSI notification"
+pvscsi_cmp_ring_put(unsigned long addr) "got completion descriptor 0x%lx"
+pvscsi_msg_ring_put(unsigned long addr) "got message descriptor 0x%lx"
+pvscsi_complete_request(uint64_t context, uint64_t len, uint8_t sense_key) "completion: ctx: 0x%"PRIx64", len: 0x%"PRIx64", sense key: %u"
+pvscsi_get_sg_list(int nsg, size_t size) "get SG list: depth: %u, size: %lu"
+pvscsi_get_next_sg_elem(uint32_t flags) "unknown flags in SG element (val: 0x%x)"
+pvscsi_command_complete_not_found(uint32_t tag) "can't find request for tag 0x%x"
+pvscsi_command_complete_data_run(void) "not all data required for command transferred"
+pvscsi_command_complete_sense_len(int len) "sense information length is %d bytes"
+pvscsi_convert_sglist(uint64_t context, unsigned long addr, uint32_t resid) "element: ctx: 0x%"PRIx64" addr: 0x%lx, len: %ul"
+pvscsi_process_req_descr(uint8_t cmd, uint64_t ctx) "SCSI cmd 0x%x, ctx: 0x%"PRIx64""
+pvscsi_process_req_descr_unknown_device(void) "command directed to unknown device rejected"
+pvscsi_process_req_descr_invalid_dir(void) "command with invalid transfer direction rejected"
+pvscsi_process_io(unsigned long addr) "got descriptor 0x%lx"
+pvscsi_on_cmd_noimpl(const char* cmd) "unimplemented command %s ignored"
+pvscsi_on_cmd_reset_dev(uint32_t tgt, int lun, void* dev) "PVSCSI_CMD_RESET_DEVICE[target %u lun %d (dev 0x%p)]"
+pvscsi_on_cmd_arrived(const char* cmd) "command %s arrived"
+pvscsi_on_cmd_abort(uint64_t ctx, uint32_t tgt) "command PVSCSI_CMD_ABORT_CMD for ctx 0x%"PRIx64", target %u"
+pvscsi_on_cmd_unknown(uint64_t cmd_id) "unknown command %"PRIx64""
+pvscsi_on_cmd_unknown_data(uint32_t data) "data for unknown command 0x:%x"
+pvscsi_io_write(const char* cmd, uint64_t val) "%s write: %"PRIx64""
+pvscsi_io_write_unknown(unsigned long addr, unsigned sz, uint64_t val) "unknown write address: 0x%lx size: %u bytes value: 0x%"PRIx64""
+pvscsi_io_read(const char* cmd, uint64_t status) "%s read: 0x%"PRIx64""
+pvscsi_io_read_unknown(unsigned long addr, unsigned sz) "unknown read address: 0x%lx size: %u bytes"
+pvscsi_init_msi_fail(int res) "failed to initialize MSI, error %d"
+pvscsi_state(const char* state) "starting %s ..."
+pvscsi_tx_rings_ppn(const char* label, uint64_t ppn) "%s page: %"PRIx64""
+pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of %s pages: %u"
+
# xen-all.c
xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx, size %#lx"
xen_client_set_memory(uint64_t start_addr, unsigned long size, bool log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device implementation
2013-04-19 14:24 ` [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device implementation Paolo Bonzini
@ 2013-06-21 3:47 ` Libaiqing
2013-06-21 7:36 ` Paolo Bonzini
0 siblings, 1 reply; 56+ messages in thread
From: Libaiqing @ 2013-06-21 3:47 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel@nongnu.org
Cc: Dmitry Fleytman, Yan Vugenfirer, asias@redhat.com,
nab@linux-iscsi.org
Hi paolo,
The PVSCSI device can be used as boot device?
I tested with fedora17 + kernel 3.6 ,but failed.Qemu commit id is " 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
PVSCSI device used as non-boot device works well.partition,mkfs,mount,dd,ok.
Could you give me some advise to debug this problem ? I can provide more information if need.
Regards,
baiqing
> -----Original Message-----
> From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org] On
> Behalf Of Paolo Bonzini
> Sent: Friday, April 19, 2013 10:24 PM
> To: qemu-devel@nongnu.org
> Cc: Dmitry Fleytman; Yan Vugenfirer; asias@redhat.com; nab@linux-iscsi.org
> Subject: [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device
> implementation
>
> From: Dmitry Fleytman <dmitry@daynix.com>
>
> Signed-off-by: Dmitry Fleytman <dmitry@daynix.com>
> Signed-off-by: Yan Vugenfirer <yan@daynix.com>
> [ Rename files to vmw_pvscsi, fix setting of hostStatus in
> pvscsi_request_cancelled - Paolo ]
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> default-configs/pci.mak | 1 +
> docs/specs/vmw_pvscsi-spec.txt | 92 +++
> hw/scsi/Makefile.objs | 1 +
> hw/scsi/vmw_pvscsi.c | 1216
> ++++++++++++++++++++++++++++++++++++++++
> hw/scsi/vmw_pvscsi.h | 434 ++++++++++++++
> include/hw/pci/pci.h | 1 +
> trace-events | 35 ++
> 7 files changed, 1780 insertions(+)
> create mode 100644 docs/specs/vmw_pvscsi-spec.txt
> create mode 100644 hw/scsi/vmw_pvscsi.c
> create mode 100644 hw/scsi/vmw_pvscsi.h
>
> diff --git a/default-configs/pci.mak b/default-configs/pci.mak
> index f5f100e..bf2cad7 100644
> --- a/default-configs/pci.mak
> +++ b/default-configs/pci.mak
> @@ -10,6 +10,7 @@ CONFIG_EEPRO100_PCI=y
> CONFIG_PCNET_PCI=y
> CONFIG_PCNET_COMMON=y
> CONFIG_LSI_SCSI_PCI=y
> +CONFIG_VMW_PVSCSI_SCSI_PCI=y
> CONFIG_MEGASAS_SCSI_PCI=y
> CONFIG_RTL8139_PCI=y
> CONFIG_E1000_PCI=y
> diff --git a/docs/specs/vmw_pvscsi-spec.txt
> b/docs/specs/vmw_pvscsi-spec.txt
> new file mode 100644
> index 0000000..49affb2
> --- /dev/null
> +++ b/docs/specs/vmw_pvscsi-spec.txt
> @@ -0,0 +1,92 @@
> +General Description
> +===================
> +
> +This document describes VMWare PVSCSI device interface specification.
> +Created by Dmitry Fleytman (dmitry@daynix.com), Daynix Computing LTD.
> +Based on source code of PVSCSI Linux driver from kernel 3.0.4
> +
> +PVSCSI Device Interface Overview
> +================================
> +
> +The interface is based on memory area shared between hypervisor and VM.
> +Memory area is obtained by driver as device IO memory resource of
> +PVSCSI_MEM_SPACE_SIZE length.
> +The shared memory consists of registers area and rings area.
> +The registers area is used to raise hypervisor interrupts and issue device
> +commands. The rings area is used to transfer data descriptors and SCSI
> +commands from VM to hypervisor and to transfer messages produced by
> +hypervisor to VM. Data itself is transferred via virtual scatter-gather DMA.
> +
> +PVSCSI Device Registers
> +=======================
> +
> +The length of the registers area is 1 page
> (PVSCSI_MEM_SPACE_COMMAND_NUM_PAGES).
> +The structure of the registers area is described by the PVSCSIRegOffset
> enum.
> +There are registers to issue device command (with optional short data),
> +issue device interrupt, control interrupts masking.
> +
> +PVSCSI Device Rings
> +===================
> +
> +There are three rings in shared memory:
> +
> + 1. Request ring (struct PVSCSIRingReqDesc *req_ring)
> + - ring for OS to device requests
> + 2. Completion ring (struct PVSCSIRingCmpDesc *cmp_ring)
> + - ring for device request completions
> + 3. Message ring (struct PVSCSIRingMsgDesc *msg_ring)
> + - ring for messages from device.
> + This ring is optional and the guest might not configure it.
> +There is a control area (struct PVSCSIRingsState *rings_state) used to
> control
> +rings operation.
> +
> +PVSCSI Device to Host Interrupts
> +================================
> +There are following interrupt types supported by PVSCSI device:
> + 1. Completion interrupts (completion ring notifications):
> + PVSCSI_INTR_CMPL_0
> + PVSCSI_INTR_CMPL_1
> + 2. Message interrupts (message ring notifications):
> + PVSCSI_INTR_MSG_0
> + PVSCSI_INTR_MSG_1
> +
> +Interrupts are controlled via PVSCSI_REG_OFFSET_INTR_MASK register
> +Bit set means interrupt enabled, bit cleared - disabled
> +
> +Interrupt modes supported are legacy, MSI and MSI-X
> +In case of legacy interrupts, register PVSCSI_REG_OFFSET_INTR_STATUS
> +is used to check which interrupt has arrived. Interrupts are
> +acknowledged when the corresponding bit is written to the interrupt
> +status register.
> +
> +PVSCSI Device Operation Sequences
> +=================================
> +
> +1. Startup sequence:
> + a. Issue PVSCSI_CMD_ADAPTER_RESET command;
> + aa. Windows driver reads interrupt status register here;
> + b. Issue PVSCSI_CMD_SETUP_MSG_RING command with no additional
> data,
> + check status and disable device messages if error returned;
> + (Omitted if device messages disabled by driver configuration)
> + c. Issue PVSCSI_CMD_SETUP_RINGS command, provide rings
> configuration
> + as struct PVSCSICmdDescSetupRings;
> + d. Issue PVSCSI_CMD_SETUP_MSG_RING command again, provide
> + rings configuration as struct PVSCSICmdDescSetupMsgRing;
> + e. Unmask completion and message (if device messages enabled)
> interrupts.
> +
> +2. Shutdown sequences
> + a. Mask interrupts;
> + b. Flush request ring using PVSCSI_REG_OFFSET_KICK_NON_RW_IO;
> + c. Issue PVSCSI_CMD_ADAPTER_RESET command.
> +
> +3. Send request
> + a. Fill next free request ring descriptor;
> + b. Issue PVSCSI_REG_OFFSET_KICK_RW_IO for R/W operations;
> + or PVSCSI_REG_OFFSET_KICK_NON_RW_IO for other operations.
> +
> +4. Abort command
> + a. Issue PVSCSI_CMD_ABORT_CMD command;
> +
> +5. Request completion processing
> + a. Upon completion interrupt arrival process completion
> + and message (if enabled) rings.
> diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
> index aab0e9b..eaec6c8 100644
> --- a/hw/scsi/Makefile.objs
> +++ b/hw/scsi/Makefile.objs
> @@ -2,6 +2,7 @@ common-obj-y += scsi-disk.o
> common-obj-y += scsi-generic.o scsi-bus.o
> common-obj-$(CONFIG_LSI_SCSI_PCI) += lsi53c895a.o
> common-obj-$(CONFIG_MEGASAS_SCSI_PCI) += megasas.o
> +common-obj-$(CONFIG_VMW_PVSCSI_SCSI_PCI) += vmw_pvscsi.o
> common-obj-$(CONFIG_ESP) += esp.o
> common-obj-$(CONFIG_ESP_PCI) += esp-pci.o
> obj-$(CONFIG_PSERIES) += spapr_vscsi.o
> diff --git a/hw/scsi/vmw_pvscsi.c b/hw/scsi/vmw_pvscsi.c
> new file mode 100644
> index 0000000..4b4a58f
> --- /dev/null
> +++ b/hw/scsi/vmw_pvscsi.c
> @@ -0,0 +1,1216 @@
> +/*
> + * QEMU VMWARE PVSCSI paravirtual SCSI bus
> + *
> + * Copyright (c) 2012 Ravello Systems LTD (http://ravellosystems.com)
> + *
> + * Developed by Daynix Computing LTD (http://www.daynix.com)
> + *
> + * Based on implementation by Paolo Bonzini
> + * http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00729.html
> + *
> + * Authors:
> + * Paolo Bonzini <pbonzini@redhat.com>
> + * Dmitry Fleytman <dmitry@daynix.com>
> + * Yan Vugenfirer <yan@daynix.com>
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.
> + * See the COPYING file in the top-level directory.
> + *
> + * NOTE about MSI-X:
> + * MSI-X support has been removed for the moment because it leads
> Windows OS
> + * to crash on startup. The crash happens because Windows driver requires
> + * MSI-X shared memory to be part of the same BAR used for rings state
> + * registers, etc. This is not supported by QEMU infrastructure so separate
> + * BAR created from MSI-X purposes. Windows driver fails to deal with 2
> BARs.
> + *
> + */
> +
> +#include "hw/scsi/scsi.h"
> +#include <block/scsi.h>
> +#include "hw/pci/msi.h"
> +#include "vmw_pvscsi.h"
> +#include "trace.h"
> +
> +
> +#define PVSCSI_MSI_OFFSET (0x50)
> +#define PVSCSI_USE_64BIT (true)
> +#define PVSCSI_PER_VECTOR_MASK (false)
> +
> +#define PVSCSI_MAX_DEVS (64)
> +#define PVSCSI_MSIX_NUM_VECTORS (1)
> +
> +#define PVSCSI_MAX_CMD_DATA_WORDS \
> + (sizeof(PVSCSICmdDescSetupRings)/sizeof(uint32_t))
> +
> +#define RS_GET_FIELD(rs_pa, field) \
> + (ldl_le_phys(rs_pa + offsetof(struct PVSCSIRingsState, field)))
> +#define RS_SET_FIELD(rs_pa, field, val) \
> + (stl_le_phys(rs_pa + offsetof(struct PVSCSIRingsState, field), val))
> +
> +#define TYPE_PVSCSI "pvscsi"
> +#define PVSCSI(obj) OBJECT_CHECK(PVSCSIState, (obj), TYPE_PVSCSI)
> +
> +typedef struct PVSCSIRingInfo {
> + uint64_t rs_pa;
> + uint32_t txr_len_mask;
> + uint32_t rxr_len_mask;
> + uint32_t msg_len_mask;
> + uint64_t
> req_ring_pages_pa[PVSCSI_SETUP_RINGS_MAX_NUM_PAGES];
> + uint64_t
> cmp_ring_pages_pa[PVSCSI_SETUP_RINGS_MAX_NUM_PAGES];
> + uint64_t
> msg_ring_pages_pa[PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES];
> + uint64_t consumed_ptr;
> + uint64_t filled_cmp_ptr;
> + uint64_t filled_msg_ptr;
> +} PVSCSIRingInfo;
> +
> +typedef struct PVSCSISGState {
> + hwaddr elemAddr;
> + hwaddr dataAddr;
> + uint32_t resid;
> +} PVSCSISGState;
> +
> +typedef QTAILQ_HEAD(, PVSCSIRequest) PVSCSIRequestList;
> +
> +typedef struct {
> + PCIDevice parent_obj;
> + MemoryRegion io_space;
> + SCSIBus bus;
> + QEMUBH *completion_worker;
> + PVSCSIRequestList pending_queue;
> + PVSCSIRequestList completion_queue;
> +
> + uint64_t reg_interrupt_status; /* Interrupt status register
> value */
> + uint64_t reg_interrupt_enabled; /* Interrupt mask register
> value */
> + uint64_t reg_command_status; /* Command status
> register value */
> +
> + /* Command data adoption mechanism */
> + uint64_t curr_cmd; /* Last command arrived
> */
> + uint32_t curr_cmd_data_cntr; /* Amount of data for last
> command */
> +
> + /* Collector for current command data */
> + uint32_t curr_cmd_data[PVSCSI_MAX_CMD_DATA_WORDS];
> +
> + uint8_t rings_info_valid; /* Whether data rings
> initialized */
> + uint8_t msg_ring_info_valid; /* Whether message ring
> initialized */
> + uint8_t use_msg; /* Whether to use message
> ring */
> +
> + uint8_t msi_used; /* Whether MSI support was installed
> successfully */
> +
> + PVSCSIRingInfo rings; /* Data transfer rings
> manager */
> + uint32_t resetting; /* Reset in progress
> */
> +} PVSCSIState;
> +
> +typedef struct PVSCSIRequest {
> + SCSIRequest *sreq;
> + PVSCSIState *dev;
> + uint8_t sense_key;
> + uint8_t completed;
> + int lun;
> + QEMUSGList sgl;
> + PVSCSISGState sg;
> + struct PVSCSIRingReqDesc req;
> + struct PVSCSIRingCmpDesc cmp;
> + QTAILQ_ENTRY(PVSCSIRequest) next;
> +} PVSCSIRequest;
> +
> +/* Integer binary logarithm */
> +static int
> +pvscsi_log2(uint32_t input)
> +{
> + int log = 0;
> + assert(input > 0);
> + while (input >> ++log) {
> + }
> + return log;
> +}
> +
> +static void
> +pvscsi_ring_init_data(PVSCSIRingInfo *m, PVSCSICmdDescSetupRings *ri)
> +{
> + int i;
> + uint32_t txr_len_log2, rxr_len_log2;
> + uint32_t req_ring_size, cmp_ring_size;
> + m->rs_pa = ri->ringsStatePPN << VMW_PAGE_SHIFT;
> +
> + req_ring_size = ri->reqRingNumPages *
> PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE;
> + cmp_ring_size = ri->cmpRingNumPages *
> PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE;
> + txr_len_log2 = pvscsi_log2(req_ring_size - 1);
> + rxr_len_log2 = pvscsi_log2(cmp_ring_size - 1);
> +
> + m->txr_len_mask = MASK(txr_len_log2);
> + m->rxr_len_mask = MASK(rxr_len_log2);
> +
> + m->consumed_ptr = 0;
> + m->filled_cmp_ptr = 0;
> +
> + for (i = 0; i < ri->reqRingNumPages; i++) {
> + m->req_ring_pages_pa[i] = ri->reqRingPPNs[i] <<
> VMW_PAGE_SHIFT;
> + }
> +
> + for (i = 0; i < ri->cmpRingNumPages; i++) {
> + m->cmp_ring_pages_pa[i] = ri->cmpRingPPNs[i] <<
> VMW_PAGE_SHIFT;
> + }
> +
> + RS_SET_FIELD(m->rs_pa, reqProdIdx, 0);
> + RS_SET_FIELD(m->rs_pa, reqConsIdx, 0);
> + RS_SET_FIELD(m->rs_pa, reqNumEntriesLog2, txr_len_log2);
> +
> + RS_SET_FIELD(m->rs_pa, cmpProdIdx, 0);
> + RS_SET_FIELD(m->rs_pa, cmpConsIdx, 0);
> + RS_SET_FIELD(m->rs_pa, cmpNumEntriesLog2, rxr_len_log2);
> +
> + trace_pvscsi_ring_init_data(txr_len_log2, rxr_len_log2);
> +
> + /* Flush ring state page changes */
> + smp_wmb();
> +}
> +
> +static void
> +pvscsi_ring_init_msg(PVSCSIRingInfo *m, PVSCSICmdDescSetupMsgRing
> *ri)
> +{
> + int i;
> + uint32_t len_log2;
> + uint32_t ring_size;
> +
> + ring_size = ri->numPages *
> PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE;
> + len_log2 = pvscsi_log2(ring_size - 1);
> +
> + m->msg_len_mask = MASK(len_log2);
> +
> + m->filled_msg_ptr = 0;
> +
> + for (i = 0; i < ri->numPages; i++) {
> + m->msg_ring_pages_pa[i] = ri->ringPPNs[i] <<
> VMW_PAGE_SHIFT;
> + }
> +
> + RS_SET_FIELD(m->rs_pa, msgProdIdx, 0);
> + RS_SET_FIELD(m->rs_pa, msgConsIdx, 0);
> + RS_SET_FIELD(m->rs_pa, msgNumEntriesLog2, len_log2);
> +
> + trace_pvscsi_ring_init_msg(len_log2);
> +
> + /* Flush ring state page changes */
> + smp_wmb();
> +}
> +
> +static void
> +pvscsi_ring_cleanup(PVSCSIRingInfo *mgr)
> +{
> + mgr->rs_pa = 0;
> + mgr->txr_len_mask = 0;
> + mgr->rxr_len_mask = 0;
> + mgr->msg_len_mask = 0;
> + mgr->consumed_ptr = 0;
> + mgr->filled_cmp_ptr = 0;
> + mgr->filled_msg_ptr = 0;
> + memset(mgr->req_ring_pages_pa, 0,
> sizeof(mgr->req_ring_pages_pa));
> + memset(mgr->cmp_ring_pages_pa, 0,
> sizeof(mgr->cmp_ring_pages_pa));
> + memset(mgr->msg_ring_pages_pa, 0,
> sizeof(mgr->msg_ring_pages_pa));
> +}
> +
> +static hwaddr
> +pvscsi_ring_pop_req_descr(PVSCSIRingInfo *mgr)
> +{
> + uint32_t ready_ptr = RS_GET_FIELD(mgr->rs_pa, reqProdIdx);
> +
> + if (ready_ptr != mgr->consumed_ptr) {
> + uint32_t next_ready_ptr =
> + mgr->consumed_ptr++ & mgr->txr_len_mask;
> + uint32_t next_ready_page =
> + next_ready_ptr /
> PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE;
> + uint32_t inpage_idx =
> + next_ready_ptr %
> PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE;
> +
> + return mgr->req_ring_pages_pa[next_ready_page] +
> + inpage_idx * sizeof(PVSCSIRingReqDesc);
> + } else {
> + return 0;
> + }
> +}
> +
> +static void
> +pvscsi_ring_flush_req(PVSCSIRingInfo *mgr)
> +{
> + RS_SET_FIELD(mgr->rs_pa, reqConsIdx, mgr->consumed_ptr);
> +}
> +
> +static hwaddr
> +pvscsi_ring_pop_cmp_descr(PVSCSIRingInfo *mgr)
> +{
> + /*
> + * According to Linux driver code it explicitly verifies that number
> + * of requests being processed by device is less then the size of
> + * completion queue, so device may omit completion queue overflow
> + * conditions check. We assume that this is true for other (Windows)
> + * drivers as well.
> + */
> +
> + uint32_t free_cmp_ptr =
> + mgr->filled_cmp_ptr++ & mgr->rxr_len_mask;
> + uint32_t free_cmp_page =
> + free_cmp_ptr / PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE;
> + uint32_t inpage_idx =
> + free_cmp_ptr % PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE;
> + return mgr->cmp_ring_pages_pa[free_cmp_page] +
> + inpage_idx * sizeof(PVSCSIRingCmpDesc);
> +}
> +
> +static hwaddr
> +pvscsi_ring_pop_msg_descr(PVSCSIRingInfo *mgr)
> +{
> + uint32_t free_msg_ptr =
> + mgr->filled_msg_ptr++ & mgr->msg_len_mask;
> + uint32_t free_msg_page =
> + free_msg_ptr / PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE;
> + uint32_t inpage_idx =
> + free_msg_ptr % PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE;
> + return mgr->msg_ring_pages_pa[free_msg_page] +
> + inpage_idx * sizeof(PVSCSIRingMsgDesc);
> +}
> +
> +static void
> +pvscsi_ring_flush_cmp(PVSCSIRingInfo *mgr)
> +{
> + /* Flush descriptor changes */
> + smp_wmb();
> +
> + trace_pvscsi_ring_flush_cmp(mgr->filled_cmp_ptr);
> +
> + RS_SET_FIELD(mgr->rs_pa, cmpProdIdx, mgr->filled_cmp_ptr);
> +}
> +
> +static bool
> +pvscsi_ring_msg_has_room(PVSCSIRingInfo *mgr)
> +{
> + uint32_t prodIdx = RS_GET_FIELD(mgr->rs_pa, msgProdIdx);
> + uint32_t consIdx = RS_GET_FIELD(mgr->rs_pa, msgConsIdx);
> +
> + return (prodIdx - consIdx) < (mgr->msg_len_mask + 1);
> +}
> +
> +static void
> +pvscsi_ring_flush_msg(PVSCSIRingInfo *mgr)
> +{
> + /* Flush descriptor changes */
> + smp_wmb();
> +
> + trace_pvscsi_ring_flush_msg(mgr->filled_msg_ptr);
> +
> + RS_SET_FIELD(mgr->rs_pa, msgProdIdx, mgr->filled_msg_ptr);
> +}
> +
> +static void
> +pvscsi_reset_state(PVSCSIState *s)
> +{
> + s->curr_cmd = PVSCSI_CMD_FIRST;
> + s->curr_cmd_data_cntr = 0;
> + s->reg_command_status =
> PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
> + s->reg_interrupt_status = 0;
> + pvscsi_ring_cleanup(&s->rings);
> + s->rings_info_valid = FALSE;
> + s->msg_ring_info_valid = FALSE;
> + QTAILQ_INIT(&s->pending_queue);
> + QTAILQ_INIT(&s->completion_queue);
> +}
> +
> +static void
> +pvscsi_update_irq_status(PVSCSIState *s)
> +{
> + PCIDevice *d = PCI_DEVICE(s);
> + bool should_raise = s->reg_interrupt_enabled &
> s->reg_interrupt_status;
> +
> + trace_pvscsi_update_irq_level(should_raise,
> s->reg_interrupt_enabled,
> + s->reg_interrupt_status);
> +
> + if (s->msi_used && msi_enabled(d)) {
> + if (should_raise) {
> + trace_pvscsi_update_irq_msi();
> + msi_notify(d, PVSCSI_VECTOR_COMPLETION);
> + }
> + return;
> + }
> +
> + qemu_set_irq(d->irq[0], !!should_raise);
> +}
> +
> +static void
> +pvscsi_raise_completion_interrupt(PVSCSIState *s)
> +{
> + s->reg_interrupt_status |= PVSCSI_INTR_CMPL_0;
> +
> + /* Memory barrier to flush interrupt status register changes*/
> + smp_wmb();
> +
> + pvscsi_update_irq_status(s);
> +}
> +
> +static void
> +pvscsi_raise_message_interrupt(PVSCSIState *s)
> +{
> + s->reg_interrupt_status |= PVSCSI_INTR_MSG_0;
> +
> + /* Memory barrier to flush interrupt status register changes*/
> + smp_wmb();
> +
> + pvscsi_update_irq_status(s);
> +}
> +
> +static void
> +pvscsi_cmp_ring_put(PVSCSIState *s, struct PVSCSIRingCmpDesc
> *cmp_desc)
> +{
> + hwaddr cmp_descr_pa;
> +
> + cmp_descr_pa = pvscsi_ring_pop_cmp_descr(&s->rings);
> + trace_pvscsi_cmp_ring_put(cmp_descr_pa);
> + cpu_physical_memory_write(cmp_descr_pa, (void *)cmp_desc,
> + sizeof(*cmp_desc));
> +}
> +
> +static void
> +pvscsi_msg_ring_put(PVSCSIState *s, struct PVSCSIRingMsgDesc
> *msg_desc)
> +{
> + hwaddr msg_descr_pa;
> +
> + msg_descr_pa = pvscsi_ring_pop_msg_descr(&s->rings);
> + trace_pvscsi_msg_ring_put(msg_descr_pa);
> + cpu_physical_memory_write(msg_descr_pa, (void *)msg_desc,
> + sizeof(*msg_desc));
> +}
> +
> +static void
> +pvscsi_process_completion_queue(void *opaque)
> +{
> + PVSCSIState *s = opaque;
> + PVSCSIRequest *pvscsi_req;
> + bool has_completed = false;
> +
> + while (!QTAILQ_EMPTY(&s->completion_queue)) {
> + pvscsi_req = QTAILQ_FIRST(&s->completion_queue);
> + QTAILQ_REMOVE(&s->completion_queue, pvscsi_req, next);
> + pvscsi_cmp_ring_put(s, &pvscsi_req->cmp);
> + g_free(pvscsi_req);
> + has_completed++;
> + }
> +
> + if (has_completed) {
> + pvscsi_ring_flush_cmp(&s->rings);
> + pvscsi_raise_completion_interrupt(s);
> + }
> +}
> +
> +static void
> +pvscsi_reset_adapter(PVSCSIState *s)
> +{
> + s->resetting++;
> + qbus_reset_all_fn(&s->bus);
> + s->resetting--;
> + pvscsi_process_completion_queue(s);
> + assert(QTAILQ_EMPTY(&s->pending_queue));
> + pvscsi_reset_state(s);
> +}
> +
> +static void
> +pvscsi_schedule_completion_processing(PVSCSIState *s)
> +{
> + /* Try putting more complete requests on the ring. */
> + if (!QTAILQ_EMPTY(&s->completion_queue)) {
> + qemu_bh_schedule(s->completion_worker);
> + }
> +}
> +
> +static void
> +pvscsi_complete_request(PVSCSIState *s, PVSCSIRequest *r)
> +{
> + assert(!r->completed);
> +
> + trace_pvscsi_complete_request(r->cmp.context, r->cmp.dataLen,
> + r->sense_key);
> + if (r->sreq != NULL) {
> + scsi_req_unref(r->sreq);
> + r->sreq = NULL;
> + }
> + r->completed = 1;
> + QTAILQ_REMOVE(&s->pending_queue, r, next);
> + QTAILQ_INSERT_TAIL(&s->completion_queue, r, next);
> + pvscsi_schedule_completion_processing(s);
> +}
> +
> +static QEMUSGList *pvscsi_get_sg_list(SCSIRequest *r)
> +{
> + PVSCSIRequest *req = r->hba_private;
> +
> + trace_pvscsi_get_sg_list(req->sgl.nsg, req->sgl.size);
> +
> + return &req->sgl;
> +}
> +
> +static void
> +pvscsi_get_next_sg_elem(PVSCSISGState *sg)
> +{
> + struct PVSCSISGElement elem;
> +
> + cpu_physical_memory_read(sg->elemAddr, (void *)&elem,
> sizeof(elem));
> + if ((elem.flags & ~PVSCSI_KNOWN_FLAGS) != 0) {
> + /*
> + * There is PVSCSI_SGE_FLAG_CHAIN_ELEMENT flag
> described in
> + * header file but its value is unknown. This flag requires
> + * additional processing, so we put warning here to catch it
> + * some day and make proper implementation
> + */
> + trace_pvscsi_get_next_sg_elem(elem.flags);
> + }
> +
> + sg->elemAddr += sizeof(elem);
> + sg->dataAddr = elem.addr;
> + sg->resid = elem.length;
> +}
> +
> +static void
> +pvscsi_write_sense(PVSCSIRequest *r, uint8_t *sense, int len)
> +{
> + r->cmp.senseLen = MIN(r->req.senseLen, len);
> + r->sense_key = sense[(sense[0] & 2) ? 1 : 2];
> + cpu_physical_memory_write(r->req.senseAddr, sense,
> r->cmp.senseLen);
> +}
> +
> +static void
> +pvscsi_command_complete(SCSIRequest *req, uint32_t status, size_t resid)
> +{
> + PVSCSIRequest *pvscsi_req = req->hba_private;
> + PVSCSIState *s = pvscsi_req->dev;
> +
> + if (!pvscsi_req) {
> + trace_pvscsi_command_complete_not_found(req->tag);
> + return;
> + }
> +
> + if (resid) {
> + /* Short transfer. */
> + trace_pvscsi_command_complete_data_run();
> + pvscsi_req->cmp.hostStatus = BTSTAT_DATARUN;
> + }
> +
> + pvscsi_req->cmp.scsiStatus = status;
> + if (pvscsi_req->cmp.scsiStatus == CHECK_CONDITION) {
> + uint8_t sense[SCSI_SENSE_BUF_SIZE];
> + int sense_len =
> + scsi_req_get_sense(pvscsi_req->sreq, sense, sizeof(sense));
> +
> + trace_pvscsi_command_complete_sense_len(sense_len);
> + pvscsi_write_sense(pvscsi_req, sense, sense_len);
> + }
> + qemu_sglist_destroy(&pvscsi_req->sgl);
> + pvscsi_complete_request(s, pvscsi_req);
> +}
> +
> +static void
> +pvscsi_send_msg(PVSCSIState *s, SCSIDevice *dev, uint32_t msg_type)
> +{
> + if (s->msg_ring_info_valid && pvscsi_ring_msg_has_room(&s->rings))
> {
> + PVSCSIMsgDescDevStatusChanged msg = {0};
> +
> + msg.type = msg_type;
> + msg.bus = dev->channel;
> + msg.target = dev->id;
> + msg.lun[1] = dev->lun;
> +
> + pvscsi_msg_ring_put(s, (PVSCSIRingMsgDesc *)&msg);
> + pvscsi_ring_flush_msg(&s->rings);
> + pvscsi_raise_message_interrupt(s);
> + }
> +}
> +
> +static void
> +pvscsi_hotplug(SCSIBus *bus, SCSIDevice *dev)
> +{
> + PVSCSIState *s = container_of(bus, PVSCSIState, bus);
> + pvscsi_send_msg(s, dev, PVSCSI_MSG_DEV_ADDED);
> +}
> +
> +static void
> +pvscsi_hot_unplug(SCSIBus *bus, SCSIDevice *dev)
> +{
> + PVSCSIState *s = container_of(bus, PVSCSIState, bus);
> + pvscsi_send_msg(s, dev, PVSCSI_MSG_DEV_REMOVED);
> +}
> +
> +static void
> +pvscsi_request_cancelled(SCSIRequest *req)
> +{
> + PVSCSIRequest *pvscsi_req = req->hba_private;
> + PVSCSIState *s = pvscsi_req->dev;
> +
> + if (pvscsi_req->completed) {
> + return;
> + }
> +
> + if (pvscsi_req->dev->resetting) {
> + pvscsi_req->cmp.hostStatus = BTSTAT_BUSRESET;
> + } else {
> + pvscsi_req->cmp.hostStatus = BTSTAT_ABORTQUEUE;
> + }
> +
> + pvscsi_complete_request(s, pvscsi_req);
> +}
> +
> +static SCSIDevice*
> +pvscsi_device_find(PVSCSIState *s, int channel, int target,
> + uint8_t *requested_lun, uint8_t *target_lun)
> +{
> + if (requested_lun[0] || requested_lun[2] || requested_lun[3] ||
> + requested_lun[4] || requested_lun[5] || requested_lun[6] ||
> + requested_lun[7] || (target > PVSCSI_MAX_DEVS)) {
> + return NULL;
> + } else {
> + *target_lun = requested_lun[1];
> + return scsi_device_find(&s->bus, channel, target, *target_lun);
> + }
> +}
> +
> +static PVSCSIRequest *
> +pvscsi_queue_pending_descriptor(PVSCSIState *s, SCSIDevice **d,
> + struct PVSCSIRingReqDesc *descr)
> +{
> + PVSCSIRequest *pvscsi_req;
> + uint8_t lun;
> +
> + pvscsi_req = g_malloc0(sizeof(*pvscsi_req));
> + pvscsi_req->dev = s;
> + pvscsi_req->req = *descr;
> + pvscsi_req->cmp.context = pvscsi_req->req.context;
> + QTAILQ_INSERT_TAIL(&s->pending_queue, pvscsi_req, next);
> +
> + *d = pvscsi_device_find(s, descr->bus, descr->target, descr->lun,
> &lun);
> + if (*d) {
> + pvscsi_req->lun = lun;
> + }
> +
> + return pvscsi_req;
> +}
> +
> +static void
> +pvscsi_convert_sglist(PVSCSIRequest *r)
> +{
> + int chunk_size;
> + uint64_t data_length = r->req.dataLen;
> + PVSCSISGState sg = r->sg;
> + while (data_length) {
> + while (!sg.resid) {
> + pvscsi_get_next_sg_elem(&sg);
> + trace_pvscsi_convert_sglist(r->req.context, r->sg.dataAddr,
> + r->sg.resid);
> + }
> + assert(data_length > 0);
> + chunk_size = MIN((unsigned) data_length, sg.resid);
> + if (chunk_size) {
> + qemu_sglist_add(&r->sgl, sg.dataAddr, chunk_size);
> + }
> +
> + sg.dataAddr += chunk_size;
> + data_length -= chunk_size;
> + sg.resid -= chunk_size;
> + }
> +}
> +
> +static void
> +pvscsi_build_sglist(PVSCSIState *s, PVSCSIRequest *r)
> +{
> + PCIDevice *d = PCI_DEVICE(s);
> +
> + qemu_sglist_init(&r->sgl, 1, pci_dma_context(d));
> + if (r->req.flags & PVSCSI_FLAG_CMD_WITH_SG_LIST) {
> + pvscsi_convert_sglist(r);
> + } else {
> + qemu_sglist_add(&r->sgl, r->req.dataAddr, r->req.dataLen);
> + }
> +}
> +
> +static void
> +pvscsi_process_request_descriptor(PVSCSIState *s,
> + struct PVSCSIRingReqDesc
> *descr)
> +{
> + SCSIDevice *d;
> + PVSCSIRequest *r = pvscsi_queue_pending_descriptor(s, &d, descr);
> + int64_t n;
> +
> + trace_pvscsi_process_req_descr(descr->cdb[0], descr->context);
> +
> + if (!d) {
> + r->cmp.hostStatus = BTSTAT_SELTIMEO;
> + trace_pvscsi_process_req_descr_unknown_device();
> + pvscsi_complete_request(s, r);
> + return;
> + }
> +
> + if (descr->flags & PVSCSI_FLAG_CMD_WITH_SG_LIST) {
> + r->sg.elemAddr = descr->dataAddr;
> + }
> +
> + r->sreq = scsi_req_new(d, descr->context, r->lun, descr->cdb, r);
> + if (r->sreq->cmd.mode == SCSI_XFER_FROM_DEV &&
> + (descr->flags & PVSCSI_FLAG_CMD_DIR_TODEVICE)) {
> + r->cmp.hostStatus = BTSTAT_BADMSG;
> + trace_pvscsi_process_req_descr_invalid_dir();
> + scsi_req_cancel(r->sreq);
> + return;
> + }
> + if (r->sreq->cmd.mode == SCSI_XFER_TO_DEV &&
> + (descr->flags & PVSCSI_FLAG_CMD_DIR_TOHOST)) {
> + r->cmp.hostStatus = BTSTAT_BADMSG;
> + trace_pvscsi_process_req_descr_invalid_dir();
> + scsi_req_cancel(r->sreq);
> + return;
> + }
> +
> + pvscsi_build_sglist(s, r);
> + n = scsi_req_enqueue(r->sreq);
> +
> + if (n) {
> + scsi_req_continue(r->sreq);
> + }
> +}
> +
> +static void
> +pvscsi_process_io(PVSCSIState *s)
> +{
> + PVSCSIRingReqDesc descr;
> + hwaddr next_descr_pa;
> +
> + assert(s->rings_info_valid);
> + while ((next_descr_pa = pvscsi_ring_pop_req_descr(&s->rings)) != 0) {
> +
> + /* Only read after production index verification */
> + smp_rmb();
> +
> + trace_pvscsi_process_io(next_descr_pa);
> + cpu_physical_memory_read(next_descr_pa, &descr,
> sizeof(descr));
> + pvscsi_process_request_descriptor(s, &descr);
> + }
> +
> + pvscsi_ring_flush_req(&s->rings);
> +}
> +
> +static void
> +pvscsi_dbg_dump_tx_rings_config(PVSCSICmdDescSetupRings *rc)
> +{
> + int i;
> + trace_pvscsi_tx_rings_ppn("Rings State", rc->ringsStatePPN);
> +
> + trace_pvscsi_tx_rings_num_pages("Request Ring",
> rc->reqRingNumPages);
> + for (i = 0; i < rc->reqRingNumPages; i++) {
> + trace_pvscsi_tx_rings_ppn("Request Ring", rc->reqRingPPNs[i]);
> + }
> +
> + trace_pvscsi_tx_rings_num_pages("Confirm Ring",
> rc->cmpRingNumPages);
> + for (i = 0; i < rc->cmpRingNumPages; i++) {
> + trace_pvscsi_tx_rings_ppn("Confirm Ring", rc->reqRingPPNs[i]);
> + }
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_config(PVSCSIState *s)
> +{
> + trace_pvscsi_on_cmd_noimpl("PVSCSI_CMD_CONFIG");
> + return PVSCSI_COMMAND_PROCESSING_FAILED;
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_unplug(PVSCSIState *s)
> +{
> + trace_pvscsi_on_cmd_noimpl("PVSCSI_CMD_DEVICE_UNPLUG");
> + return PVSCSI_COMMAND_PROCESSING_FAILED;
> +}
> +
> +static uint64_t
> +pvscsi_on_issue_scsi(PVSCSIState *s)
> +{
> + trace_pvscsi_on_cmd_noimpl("PVSCSI_CMD_ISSUE_SCSI");
> + return PVSCSI_COMMAND_PROCESSING_FAILED;
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_setup_rings(PVSCSIState *s)
> +{
> + PVSCSICmdDescSetupRings *rc =
> + (PVSCSICmdDescSetupRings *) s->curr_cmd_data;
> +
> + trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_SETUP_RINGS");
> +
> + pvscsi_dbg_dump_tx_rings_config(rc);
> + pvscsi_ring_init_data(&s->rings, rc);
> + s->rings_info_valid = TRUE;
> + return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_abort(PVSCSIState *s)
> +{
> + PVSCSICmdDescAbortCmd *cmd = (PVSCSICmdDescAbortCmd *)
> s->curr_cmd_data;
> + PVSCSIRequest *r, *next;
> +
> + trace_pvscsi_on_cmd_abort(cmd->context, cmd->target);
> +
> + QTAILQ_FOREACH_SAFE(r, &s->pending_queue, next, next) {
> + if (r->req.context == cmd->context) {
> + break;
> + }
> + }
> + if (r) {
> + assert(!r->completed);
> + r->cmp.hostStatus = BTSTAT_ABORTQUEUE;
> + scsi_req_cancel(r->sreq);
> + }
> +
> + return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_unknown(PVSCSIState *s)
> +{
> + trace_pvscsi_on_cmd_unknown_data(s->curr_cmd_data[0]);
> + return PVSCSI_COMMAND_PROCESSING_FAILED;
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_reset_device(PVSCSIState *s)
> +{
> + uint8_t target_lun = 0;
> + struct PVSCSICmdDescResetDevice *cmd =
> + (struct PVSCSICmdDescResetDevice *) s->curr_cmd_data;
> + SCSIDevice *sdev;
> +
> + sdev = pvscsi_device_find(s, 0, cmd->target, cmd->lun, &target_lun);
> +
> + trace_pvscsi_on_cmd_reset_dev(cmd->target, (int) target_lun, sdev);
> +
> + if (sdev != NULL) {
> + s->resetting++;
> + device_reset(&sdev->qdev);
> + s->resetting--;
> + return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
> + }
> +
> + return PVSCSI_COMMAND_PROCESSING_FAILED;
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_reset_bus(PVSCSIState *s)
> +{
> + trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_RESET_BUS");
> +
> + s->resetting++;
> + qbus_reset_all_fn(&s->bus);
> + s->resetting--;
> + return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_setup_msg_ring(PVSCSIState *s)
> +{
> + PVSCSICmdDescSetupMsgRing *rc =
> + (PVSCSICmdDescSetupMsgRing *) s->curr_cmd_data;
> +
> + trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_SETUP_MSG_RING");
> +
> + if (!s->use_msg) {
> + return PVSCSI_COMMAND_PROCESSING_FAILED;
> + }
> +
> + if (s->rings_info_valid) {
> + pvscsi_ring_init_msg(&s->rings, rc);
> + s->msg_ring_info_valid = TRUE;
> + }
> + return sizeof(PVSCSICmdDescSetupMsgRing) / sizeof(uint32_t);
> +}
> +
> +static uint64_t
> +pvscsi_on_cmd_adapter_reset(PVSCSIState *s)
> +{
> + trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_ADAPTER_RESET");
> +
> + pvscsi_reset_adapter(s);
> + return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
> +}
> +
> +static const struct {
> + int data_size;
> + uint64_t (*handler_fn)(PVSCSIState *s);
> +} pvscsi_commands[] = {
> + [PVSCSI_CMD_FIRST] = {
> + .data_size = 0,
> + .handler_fn = pvscsi_on_cmd_unknown,
> + },
> +
> + /* Not implemented, data size defined based on what arrives on
> windows */
> + [PVSCSI_CMD_CONFIG] = {
> + .data_size = 6 * sizeof(uint32_t),
> + .handler_fn = pvscsi_on_cmd_config,
> + },
> +
> + /* Command not implemented, data size is unknown */
> + [PVSCSI_CMD_ISSUE_SCSI] = {
> + .data_size = 0,
> + .handler_fn = pvscsi_on_issue_scsi,
> + },
> +
> + /* Command not implemented, data size is unknown */
> + [PVSCSI_CMD_DEVICE_UNPLUG] = {
> + .data_size = 0,
> + .handler_fn = pvscsi_on_cmd_unplug,
> + },
> +
> + [PVSCSI_CMD_SETUP_RINGS] = {
> + .data_size = sizeof(PVSCSICmdDescSetupRings),
> + .handler_fn = pvscsi_on_cmd_setup_rings,
> + },
> +
> + [PVSCSI_CMD_RESET_DEVICE] = {
> + .data_size = sizeof(struct PVSCSICmdDescResetDevice),
> + .handler_fn = pvscsi_on_cmd_reset_device,
> + },
> +
> + [PVSCSI_CMD_RESET_BUS] = {
> + .data_size = 0,
> + .handler_fn = pvscsi_on_cmd_reset_bus,
> + },
> +
> + [PVSCSI_CMD_SETUP_MSG_RING] = {
> + .data_size = sizeof(PVSCSICmdDescSetupMsgRing),
> + .handler_fn = pvscsi_on_cmd_setup_msg_ring,
> + },
> +
> + [PVSCSI_CMD_ADAPTER_RESET] = {
> + .data_size = 0,
> + .handler_fn = pvscsi_on_cmd_adapter_reset,
> + },
> +
> + [PVSCSI_CMD_ABORT_CMD] = {
> + .data_size = sizeof(struct PVSCSICmdDescAbortCmd),
> + .handler_fn = pvscsi_on_cmd_abort,
> + },
> +};
> +
> +static void
> +pvscsi_do_command_processing(PVSCSIState *s)
> +{
> + size_t bytes_arrived = s->curr_cmd_data_cntr * sizeof(uint32_t);
> +
> + assert(s->curr_cmd < PVSCSI_CMD_LAST);
> + if (bytes_arrived >= pvscsi_commands[s->curr_cmd].data_size) {
> + s->reg_command_status =
> pvscsi_commands[s->curr_cmd].handler_fn(s);
> + s->curr_cmd = PVSCSI_CMD_FIRST;
> + s->curr_cmd_data_cntr = 0;
> + }
> +}
> +
> +static void
> +pvscsi_on_command_data(PVSCSIState *s, uint32_t value)
> +{
> + size_t bytes_arrived = s->curr_cmd_data_cntr * sizeof(uint32_t);
> +
> + assert(bytes_arrived < sizeof(s->curr_cmd_data));
> + s->curr_cmd_data[s->curr_cmd_data_cntr++] = value;
> +
> + pvscsi_do_command_processing(s);
> +}
> +
> +static void
> +pvscsi_on_command(PVSCSIState *s, uint64_t cmd_id)
> +{
> + if ((cmd_id > PVSCSI_CMD_FIRST) && (cmd_id < PVSCSI_CMD_LAST)) {
> + s->curr_cmd = cmd_id;
> + } else {
> + s->curr_cmd = PVSCSI_CMD_FIRST;
> + trace_pvscsi_on_cmd_unknown(cmd_id);
> + }
> +
> + s->curr_cmd_data_cntr = 0;
> + s->reg_command_status = PVSCSI_COMMAND_NOT_ENOUGH_DATA;
> +
> + pvscsi_do_command_processing(s);
> +}
> +
> +static void
> +pvscsi_io_write(void *opaque, hwaddr addr,
> + uint64_t val, unsigned size)
> +{
> + PVSCSIState *s = opaque;
> +
> + switch (addr) {
> + case PVSCSI_REG_OFFSET_COMMAND:
> + pvscsi_on_command(s, val);
> + break;
> +
> + case PVSCSI_REG_OFFSET_COMMAND_DATA:
> + pvscsi_on_command_data(s, (uint32_t) val);
> + break;
> +
> + case PVSCSI_REG_OFFSET_INTR_STATUS:
> + trace_pvscsi_io_write("PVSCSI_REG_OFFSET_INTR_STATUS", val);
> + s->reg_interrupt_status &= ~val;
> + pvscsi_update_irq_status(s);
> + pvscsi_schedule_completion_processing(s);
> + break;
> +
> + case PVSCSI_REG_OFFSET_INTR_MASK:
> + trace_pvscsi_io_write("PVSCSI_REG_OFFSET_INTR_MASK", val);
> + s->reg_interrupt_enabled = val;
> + pvscsi_update_irq_status(s);
> + break;
> +
> + case PVSCSI_REG_OFFSET_KICK_NON_RW_IO:
> + trace_pvscsi_io_write("PVSCSI_REG_OFFSET_KICK_NON_RW_IO",
> val);
> + pvscsi_process_io(s);
> + break;
> +
> + case PVSCSI_REG_OFFSET_KICK_RW_IO:
> + trace_pvscsi_io_write("PVSCSI_REG_OFFSET_KICK_RW_IO", val);
> + pvscsi_process_io(s);
> + break;
> +
> + case PVSCSI_REG_OFFSET_DEBUG:
> + trace_pvscsi_io_write("PVSCSI_REG_OFFSET_DEBUG", val);
> + break;
> +
> + default:
> + trace_pvscsi_io_write_unknown(addr, size, val);
> + break;
> + }
> +
> +}
> +
> +static uint64_t
> +pvscsi_io_read(void *opaque, hwaddr addr, unsigned size)
> +{
> + PVSCSIState *s = opaque;
> +
> + switch (addr) {
> + case PVSCSI_REG_OFFSET_INTR_STATUS:
> + trace_pvscsi_io_read("PVSCSI_REG_OFFSET_INTR_STATUS",
> + s->reg_interrupt_status);
> + return s->reg_interrupt_status;
> +
> + case PVSCSI_REG_OFFSET_INTR_MASK:
> + trace_pvscsi_io_read("PVSCSI_REG_OFFSET_INTR_MASK",
> + s->reg_interrupt_status);
> + return s->reg_interrupt_enabled;
> +
> + case PVSCSI_REG_OFFSET_COMMAND_STATUS:
> +
> trace_pvscsi_io_read("PVSCSI_REG_OFFSET_COMMAND_STATUS",
> + s->reg_interrupt_status);
> + return s->reg_command_status;
> +
> + default:
> + trace_pvscsi_io_read_unknown(addr, size);
> + return 0;
> + }
> +}
> +
> +
> +static bool
> +pvscsi_init_msi(PVSCSIState *s)
> +{
> + int res;
> + PCIDevice *d = PCI_DEVICE(s);
> +
> + res = msi_init(d, PVSCSI_MSI_OFFSET, PVSCSI_MSIX_NUM_VECTORS,
> + PVSCSI_USE_64BIT, PVSCSI_PER_VECTOR_MASK);
> + if (res < 0) {
> + trace_pvscsi_init_msi_fail(res);
> + s->msi_used = false;
> + } else {
> + s->msi_used = true;
> + }
> +
> + return s->msi_used;
> +}
> +
> +static void
> +pvscsi_cleanup_msi(PVSCSIState *s)
> +{
> + PCIDevice *d = PCI_DEVICE(s);
> +
> + if (s->msi_used) {
> + msi_uninit(d);
> + }
> +}
> +
> +static const MemoryRegionOps pvscsi_ops = {
> + .read = pvscsi_io_read,
> + .write = pvscsi_io_write,
> + .endianness = DEVICE_LITTLE_ENDIAN,
> + .impl = {
> + .min_access_size = 4,
> + .max_access_size = 4,
> + },
> +};
> +
> +static const struct SCSIBusInfo pvscsi_scsi_info = {
> + .tcq = true,
> + .max_target = PVSCSI_MAX_DEVS,
> + .max_channel = 0,
> + .max_lun = 0,
> +
> + .get_sg_list = pvscsi_get_sg_list,
> + .complete = pvscsi_command_complete,
> + .cancel = pvscsi_request_cancelled,
> + .hotplug = pvscsi_hotplug,
> + .hot_unplug = pvscsi_hot_unplug,
> +};
> +
> +static int
> +pvscsi_init(PCIDevice *pci_dev)
> +{
> + PVSCSIState *s = PVSCSI(pci_dev);
> +
> + trace_pvscsi_state("init");
> +
> + /* PCI subsystem ID */
> + pci_dev->config[PCI_SUBSYSTEM_ID] = 0x00;
> + pci_dev->config[PCI_SUBSYSTEM_ID + 1] = 0x10;
> +
> + /* PCI latency timer = 255 */
> + pci_dev->config[PCI_LATENCY_TIMER] = 0xff;
> +
> + /* Interrupt pin A */
> + pci_config_set_interrupt_pin(pci_dev->config, 1);
> +
> + memory_region_init_io(&s->io_space, &pvscsi_ops, s,
> + "pvscsi-io", PVSCSI_MEM_SPACE_SIZE);
> + pci_register_bar(pci_dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY,
> &s->io_space);
> +
> + pvscsi_init_msi(s);
> +
> + s->completion_worker =
> qemu_bh_new(pvscsi_process_completion_queue, s);
> + if (!s->completion_worker) {
> + pvscsi_cleanup_msi(s);
> + memory_region_destroy(&s->io_space);
> + return -ENOMEM;
> + }
> +
> + scsi_bus_new(&s->bus, &pci_dev->qdev, &pvscsi_scsi_info);
> + pvscsi_reset_state(s);
> +
> + return 0;
> +}
> +
> +static void
> +pvscsi_uninit(PCIDevice *pci_dev)
> +{
> + PVSCSIState *s = PVSCSI(pci_dev);
> +
> + trace_pvscsi_state("uninit");
> + qemu_bh_delete(s->completion_worker);
> +
> + pvscsi_cleanup_msi(s);
> +
> + memory_region_destroy(&s->io_space);
> +}
> +
> +static void
> +pvscsi_reset(DeviceState *dev)
> +{
> + PCIDevice *d = PCI_DEVICE(dev);
> + PVSCSIState *s = PVSCSI(d);
> +
> + trace_pvscsi_state("reset");
> + pvscsi_reset_adapter(s);
> +}
> +
> +static void
> +pvscsi_pre_save(void *opaque)
> +{
> + PVSCSIState *s = (PVSCSIState *) opaque;
> +
> + trace_pvscsi_state("presave");
> +
> + assert(QTAILQ_EMPTY(&s->pending_queue));
> + assert(QTAILQ_EMPTY(&s->completion_queue));
> +}
> +
> +static int
> +pvscsi_post_load(void *opaque, int version_id)
> +{
> + trace_pvscsi_state("postload");
> + return 0;
> +}
> +
> +static const VMStateDescription vmstate_pvscsi = {
> + .name = TYPE_PVSCSI,
> + .version_id = 0,
> + .minimum_version_id = 0,
> + .minimum_version_id_old = 0,
> + .pre_save = pvscsi_pre_save,
> + .post_load = pvscsi_post_load,
> + .fields = (VMStateField[]) {
> + VMSTATE_PCI_DEVICE(parent_obj, PVSCSIState),
> + VMSTATE_UINT8(msi_used, PVSCSIState),
> + VMSTATE_UINT32(resetting, PVSCSIState),
> + VMSTATE_UINT64(reg_interrupt_status, PVSCSIState),
> + VMSTATE_UINT64(reg_interrupt_enabled, PVSCSIState),
> + VMSTATE_UINT64(reg_command_status, PVSCSIState),
> + VMSTATE_UINT64(curr_cmd, PVSCSIState),
> + VMSTATE_UINT32(curr_cmd_data_cntr, PVSCSIState),
> + VMSTATE_UINT32_ARRAY(curr_cmd_data, PVSCSIState,
> + ARRAY_SIZE(((PVSCSIState
> *)NULL)->curr_cmd_data)),
> + VMSTATE_UINT8(rings_info_valid, PVSCSIState),
> + VMSTATE_UINT8(msg_ring_info_valid, PVSCSIState),
> + VMSTATE_UINT8(use_msg, PVSCSIState),
> +
> + VMSTATE_UINT64(rings.rs_pa, PVSCSIState),
> + VMSTATE_UINT32(rings.txr_len_mask, PVSCSIState),
> + VMSTATE_UINT32(rings.rxr_len_mask, PVSCSIState),
> + VMSTATE_UINT64_ARRAY(rings.req_ring_pages_pa, PVSCSIState,
> +
> PVSCSI_SETUP_RINGS_MAX_NUM_PAGES),
> + VMSTATE_UINT64_ARRAY(rings.cmp_ring_pages_pa,
> PVSCSIState,
> +
> PVSCSI_SETUP_RINGS_MAX_NUM_PAGES),
> + VMSTATE_UINT64(rings.consumed_ptr, PVSCSIState),
> + VMSTATE_UINT64(rings.filled_cmp_ptr, PVSCSIState),
> +
> + VMSTATE_END_OF_LIST()
> + }
> +};
> +
> +static void
> +pvscsi_write_config(PCIDevice *pci, uint32_t addr, uint32_t val, int len)
> +{
> + pci_default_write_config(pci, addr, val, len);
> + msi_write_config(pci, addr, val, len);
> +}
> +
> +static Property pvscsi_properties[] = {
> + DEFINE_PROP_UINT8("use_msg", PVSCSIState, use_msg, 1),
> + DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void pvscsi_class_init(ObjectClass *klass, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> +
> + k->init = pvscsi_init;
> + k->exit = pvscsi_uninit;
> + k->vendor_id = PCI_VENDOR_ID_VMWARE;
> + k->device_id = PCI_DEVICE_ID_VMWARE_PVSCSI;
> + k->class_id = PCI_CLASS_STORAGE_SCSI;
> + k->subsystem_id = 0x1000;
> + dc->reset = pvscsi_reset;
> + dc->vmsd = &vmstate_pvscsi;
> + dc->props = pvscsi_properties;
> + k->config_write = pvscsi_write_config;
> +}
> +
> +static const TypeInfo pvscsi_info = {
> + .name = "pvscsi",
> + .parent = TYPE_PCI_DEVICE,
> + .instance_size = sizeof(PVSCSIState),
> + .class_init = pvscsi_class_init,
> +};
> +
> +static void
> +pvscsi_register_types(void)
> +{
> + type_register_static(&pvscsi_info);
> +}
> +
> +type_init(pvscsi_register_types);
> diff --git a/hw/scsi/vmw_pvscsi.h b/hw/scsi/vmw_pvscsi.h
> new file mode 100644
> index 0000000..17fcf66
> --- /dev/null
> +++ b/hw/scsi/vmw_pvscsi.h
> @@ -0,0 +1,434 @@
> +/*
> + * VMware PVSCSI header file
> + *
> + * Copyright (C) 2008-2009, VMware, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; version 2 of the License and no later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD
> TITLE or
> + * NON INFRINGEMENT. See the GNU General Public License for more
> + * details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Maintained by: Arvind Kumar <arvindkumar@vmware.com>
> + *
> + */
> +
> +#ifndef VMW_PVSCSI_H
> +#define VMW_PVSCSI_H
> +
> +#define VMW_PAGE_SIZE (4096)
> +#define VMW_PAGE_SHIFT (12)
> +
> +#define MASK(n) ((1 << (n)) - 1) /* make an n-bit mask */
> +
> +/*
> + * host adapter status/error codes
> + */
> +enum HostBusAdapterStatus {
> + BTSTAT_SUCCESS = 0x00, /* CCB complete normally with no
> errors */
> + BTSTAT_LINKED_COMMAND_COMPLETED = 0x0a,
> + BTSTAT_LINKED_COMMAND_COMPLETED_WITH_FLAG = 0x0b,
> + BTSTAT_DATA_UNDERRUN = 0x0c,
> + BTSTAT_SELTIMEO = 0x11, /* SCSI selection timeout */
> + BTSTAT_DATARUN = 0x12, /* data overrun/underrun */
> + BTSTAT_BUSFREE = 0x13, /* unexpected bus free */
> + BTSTAT_INVPHASE = 0x14, /* invalid bus phase or sequence */
> + /* requested by target
> */
> + BTSTAT_LUNMISMATCH = 0x17, /* linked CCB has different LUN
> */
> + /* from first CCB
> */
> + BTSTAT_SENSFAILED = 0x1b, /* auto request sense failed */
> + BTSTAT_TAGREJECT = 0x1c, /* SCSI II tagged queueing message
> */
> + /* rejected by target
> */
> + BTSTAT_BADMSG = 0x1d, /* unsupported message received
> by */
> + /* the host adapter
> */
> + BTSTAT_HAHARDWARE = 0x20, /* host adapter hardware failed
> */
> + BTSTAT_NORESPONSE = 0x21, /* target did not respond to SCSI
> ATN, */
> + /* sent a SCSI RST
> */
> + BTSTAT_SENTRST = 0x22, /* host adapter asserted a SCSI RST
> */
> + BTSTAT_RECVRST = 0x23, /* other SCSI devices asserted a
> SCSI RST */
> + BTSTAT_DISCONNECT = 0x24, /* target device reconnected
> improperly */
> + /* (w/o tag)
> */
> + BTSTAT_BUSRESET = 0x25, /* host adapter issued BUS device
> reset */
> + BTSTAT_ABORTQUEUE = 0x26, /* abort queue generated */
> + BTSTAT_HASOFTWARE = 0x27, /* host adapter software error */
> + BTSTAT_HATIMEOUT = 0x30, /* host adapter hardware timeout
> error */
> + BTSTAT_SCSIPARITY = 0x34, /* SCSI parity error detected */
> +};
> +
> +/*
> + * Register offsets.
> + *
> + * These registers are accessible both via i/o space and mm i/o.
> + */
> +
> +enum PVSCSIRegOffset {
> + PVSCSI_REG_OFFSET_COMMAND = 0x0,
> + PVSCSI_REG_OFFSET_COMMAND_DATA = 0x4,
> + PVSCSI_REG_OFFSET_COMMAND_STATUS = 0x8,
> + PVSCSI_REG_OFFSET_LAST_STS_0 = 0x100,
> + PVSCSI_REG_OFFSET_LAST_STS_1 = 0x104,
> + PVSCSI_REG_OFFSET_LAST_STS_2 = 0x108,
> + PVSCSI_REG_OFFSET_LAST_STS_3 = 0x10c,
> + PVSCSI_REG_OFFSET_INTR_STATUS = 0x100c,
> + PVSCSI_REG_OFFSET_INTR_MASK = 0x2010,
> + PVSCSI_REG_OFFSET_KICK_NON_RW_IO = 0x3014,
> + PVSCSI_REG_OFFSET_DEBUG = 0x3018,
> + PVSCSI_REG_OFFSET_KICK_RW_IO = 0x4018,
> +};
> +
> +/*
> + * Virtual h/w commands.
> + */
> +
> +enum PVSCSICommands {
> + PVSCSI_CMD_FIRST = 0, /* has to be first */
> +
> + PVSCSI_CMD_ADAPTER_RESET = 1,
> + PVSCSI_CMD_ISSUE_SCSI = 2,
> + PVSCSI_CMD_SETUP_RINGS = 3,
> + PVSCSI_CMD_RESET_BUS = 4,
> + PVSCSI_CMD_RESET_DEVICE = 5,
> + PVSCSI_CMD_ABORT_CMD = 6,
> + PVSCSI_CMD_CONFIG = 7,
> + PVSCSI_CMD_SETUP_MSG_RING = 8,
> + PVSCSI_CMD_DEVICE_UNPLUG = 9,
> +
> + PVSCSI_CMD_LAST = 10 /* has to be last */
> +};
> +
> +#define PVSCSI_COMMAND_PROCESSING_SUCCEEDED (0)
> +#define PVSCSI_COMMAND_PROCESSING_FAILED (-1)
> +#define PVSCSI_COMMAND_NOT_ENOUGH_DATA (-2)
> +
> +/*
> + * Command descriptor for PVSCSI_CMD_RESET_DEVICE --
> + */
> +
> +struct PVSCSICmdDescResetDevice {
> + uint32_t target;
> + uint8_t lun[8];
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSICmdDescResetDevice PVSCSICmdDescResetDevice;
> +
> +/*
> + * Command descriptor for PVSCSI_CMD_ABORT_CMD --
> + *
> + * - currently does not support specifying the LUN.
> + * - pad should be 0.
> + */
> +
> +struct PVSCSICmdDescAbortCmd {
> + uint64_t context;
> + uint32_t target;
> + uint32_t pad;
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSICmdDescAbortCmd PVSCSICmdDescAbortCmd;
> +
> +/*
> + * Command descriptor for PVSCSI_CMD_SETUP_RINGS --
> + *
> + * Notes:
> + * - reqRingNumPages and cmpRingNumPages need to be power of two.
> + * - reqRingNumPages and cmpRingNumPages need to be different from 0,
> + * - reqRingNumPages and cmpRingNumPages need to be inferior to
> + * PVSCSI_SETUP_RINGS_MAX_NUM_PAGES.
> + */
> +
> +#define PVSCSI_SETUP_RINGS_MAX_NUM_PAGES 32
> +struct PVSCSICmdDescSetupRings {
> + uint32_t reqRingNumPages;
> + uint32_t cmpRingNumPages;
> + uint64_t ringsStatePPN;
> + uint64_t reqRingPPNs[PVSCSI_SETUP_RINGS_MAX_NUM_PAGES];
> + uint64_t
> cmpRingPPNs[PVSCSI_SETUP_RINGS_MAX_NUM_PAGES];
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSICmdDescSetupRings PVSCSICmdDescSetupRings;
> +
> +/*
> + * Command descriptor for PVSCSI_CMD_SETUP_MSG_RING --
> + *
> + * Notes:
> + * - this command was not supported in the initial revision of the h/w
> + * interface. Before using it, you need to check that it is supported by
> + * writing PVSCSI_CMD_SETUP_MSG_RING to the 'command' register,
> then
> + * immediately after read the 'command status' register:
> + * * a value of -1 means that the cmd is NOT supported,
> + * * a value != -1 means that the cmd IS supported.
> + * If it's supported the 'command status' register should return:
> + * sizeof(PVSCSICmdDescSetupMsgRing) / sizeof(uint32_t).
> + * - this command should be issued _after_ the usual SETUP_RINGS so that
> the
> + * RingsState page is already setup. If not, the command is a nop.
> + * - numPages needs to be a power of two,
> + * - numPages needs to be different from 0,
> + * - pad should be zero.
> + */
> +
> +#define PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES 16
> +
> +struct PVSCSICmdDescSetupMsgRing {
> + uint32_t numPages;
> + uint32_t pad;
> + uint64_t
> ringPPNs[PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES];
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSICmdDescSetupMsgRing
> PVSCSICmdDescSetupMsgRing;
> +
> +enum PVSCSIMsgType {
> + PVSCSI_MSG_DEV_ADDED = 0,
> + PVSCSI_MSG_DEV_REMOVED = 1,
> + PVSCSI_MSG_LAST = 2,
> +};
> +
> +/*
> + * Msg descriptor.
> + *
> + * sizeof(struct PVSCSIRingMsgDesc) == 128.
> + *
> + * - type is of type enum PVSCSIMsgType.
> + * - the content of args depend on the type of event being delivered.
> + */
> +
> +struct PVSCSIRingMsgDesc {
> + uint32_t type;
> + uint32_t args[31];
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSIRingMsgDesc PVSCSIRingMsgDesc;
> +
> +struct PVSCSIMsgDescDevStatusChanged {
> + uint32_t type; /* PVSCSI_MSG_DEV _ADDED / _REMOVED */
> + uint32_t bus;
> + uint32_t target;
> + uint8_t lun[8];
> + uint32_t pad[27];
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSIMsgDescDevStatusChanged
> PVSCSIMsgDescDevStatusChanged;
> +
> +/*
> + * Rings state.
> + *
> + * - the fields:
> + * . msgProdIdx,
> + * . msgConsIdx,
> + * . msgNumEntriesLog2,
> + * .. are only used once the SETUP_MSG_RING cmd has been issued.
> + * - 'pad' helps to ensure that the msg related fields are on their own
> + * cache-line.
> + */
> +
> +struct PVSCSIRingsState {
> + uint32_t reqProdIdx;
> + uint32_t reqConsIdx;
> + uint32_t reqNumEntriesLog2;
> +
> + uint32_t cmpProdIdx;
> + uint32_t cmpConsIdx;
> + uint32_t cmpNumEntriesLog2;
> +
> + uint8_t pad[104];
> +
> + uint32_t msgProdIdx;
> + uint32_t msgConsIdx;
> + uint32_t msgNumEntriesLog2;
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSIRingsState PVSCSIRingsState;
> +
> +/*
> + * Request descriptor.
> + *
> + * sizeof(RingReqDesc) = 128
> + *
> + * - context: is a unique identifier of a command. It could normally be any
> + * 64bit value, however we currently store it in the serialNumber
> variable
> + * of struct SCSI_Command, so we have the following restrictions due to
> the
> + * way this field is handled in the vmkernel storage stack:
> + * * this value can't be 0,
> + * * the upper 32bit need to be 0 since serialNumber is as a uint32_t.
> + * Currently tracked as PR 292060.
> + * - dataLen: contains the total number of bytes that need to be
> transferred.
> + * - dataAddr:
> + * * if PVSCSI_FLAG_CMD_WITH_SG_LIST is set: dataAddr is the PA of
> the first
> + * s/g table segment, each s/g segment is entirely contained on a
> single
> + * page of physical memory,
> + * * if PVSCSI_FLAG_CMD_WITH_SG_LIST is NOT set, then dataAddr is
> the PA of
> + * the buffer used for the DMA transfer,
> + * - flags:
> + * * PVSCSI_FLAG_CMD_WITH_SG_LIST: see dataAddr above,
> + * * PVSCSI_FLAG_CMD_DIR_NONE: no DMA involved,
> + * * PVSCSI_FLAG_CMD_DIR_TOHOST: transfer from device to main
> memory,
> + * * PVSCSI_FLAG_CMD_DIR_TODEVICE: transfer from main memory to
> device,
> + * * PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB: reserved to handle CDBs
> larger than
> + * 16bytes. To be specified.
> + * - vcpuHint: vcpuId of the processor that will be most likely waiting for the
> + * completion of the i/o. For guest OSes that use lowest priority
> message
> + * delivery mode (such as windows), we use this "hint" to deliver the
> + * completion action to the proper vcpu. For now, we can use the vcpuId
> of
> + * the processor that initiated the i/o as a likely candidate for the vcpu
> + * that will be waiting for the completion..
> + * - bus should be 0: we currently only support bus 0 for now.
> + * - unused should be zero'd.
> + */
> +
> +#define PVSCSI_FLAG_CMD_WITH_SG_LIST (1 << 0)
> +#define PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB (1 << 1)
> +#define PVSCSI_FLAG_CMD_DIR_NONE (1 << 2)
> +#define PVSCSI_FLAG_CMD_DIR_TOHOST (1 << 3)
> +#define PVSCSI_FLAG_CMD_DIR_TODEVICE (1 << 4)
> +
> +#define PVSCSI_KNOWN_FLAGS \
> + (PVSCSI_FLAG_CMD_WITH_SG_LIST | \
> + PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB | \
> + PVSCSI_FLAG_CMD_DIR_NONE | \
> + PVSCSI_FLAG_CMD_DIR_TOHOST | \
> + PVSCSI_FLAG_CMD_DIR_TODEVICE)
> +
> +struct PVSCSIRingReqDesc {
> + uint64_t context;
> + uint64_t dataAddr;
> + uint64_t dataLen;
> + uint64_t senseAddr;
> + uint32_t senseLen;
> + uint32_t flags;
> + uint8_t cdb[16];
> + uint8_t cdbLen;
> + uint8_t lun[8];
> + uint8_t tag;
> + uint8_t bus;
> + uint8_t target;
> + uint8_t vcpuHint;
> + uint8_t unused[59];
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSIRingReqDesc PVSCSIRingReqDesc;
> +
> +/*
> + * Scatter-gather list management.
> + *
> + * As described above, when PVSCSI_FLAG_CMD_WITH_SG_LIST is set in
> the
> + * RingReqDesc.flags, then RingReqDesc.dataAddr is the PA of the first s/g
> + * table segment.
> + *
> + * - each segment of the s/g table contain a succession of struct
> + * PVSCSISGElement.
> + * - each segment is entirely contained on a single physical page of
> memory.
> + * - a "chain" s/g element has the flag PVSCSI_SGE_FLAG_CHAIN_ELEMENT
> set in
> + * PVSCSISGElement.flags and in this case:
> + * * addr is the PA of the next s/g segment,
> + * * length is undefined, assumed to be 0.
> + */
> +
> +struct PVSCSISGElement {
> + uint64_t addr;
> + uint32_t length;
> + uint32_t flags;
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSISGElement PVSCSISGElement;
> +
> +/*
> + * Completion descriptor.
> + *
> + * sizeof(RingCmpDesc) = 32
> + *
> + * - context: identifier of the command. The same thing that was specified
> + * under "context" as part of struct RingReqDesc at initiation time,
> + * - dataLen: number of bytes transferred for the actual i/o operation,
> + * - senseLen: number of bytes written into the sense buffer,
> + * - hostStatus: adapter status,
> + * - scsiStatus: device status,
> + * - pad should be zero.
> + */
> +
> +struct PVSCSIRingCmpDesc {
> + uint64_t context;
> + uint64_t dataLen;
> + uint32_t senseLen;
> + uint16_t hostStatus;
> + uint16_t scsiStatus;
> + uint32_t pad[2];
> +} QEMU_PACKED;
> +
> +typedef struct PVSCSIRingCmpDesc PVSCSIRingCmpDesc;
> +
> +/*
> + * Interrupt status / IRQ bits.
> + */
> +
> +#define PVSCSI_INTR_CMPL_0 (1 << 0)
> +#define PVSCSI_INTR_CMPL_1 (1 << 1)
> +#define PVSCSI_INTR_CMPL_MASK MASK(2)
> +
> +#define PVSCSI_INTR_MSG_0 (1 << 2)
> +#define PVSCSI_INTR_MSG_1 (1 << 3)
> +#define PVSCSI_INTR_MSG_MASK (MASK(2) << 2)
> +
> +#define PVSCSI_INTR_ALL_SUPPORTED MASK(4)
> +
> +/*
> + * Number of MSI-X vectors supported.
> + */
> +#define PVSCSI_MAX_INTRS 24
> +
> +/*
> + * Enumeration of supported MSI-X vectors
> + */
> +#define PVSCSI_VECTOR_COMPLETION 0
> +
> +/*
> + * Misc constants for the rings.
> + */
> +
> +#define PVSCSI_MAX_NUM_PAGES_REQ_RING
> PVSCSI_SETUP_RINGS_MAX_NUM_PAGES
> +#define PVSCSI_MAX_NUM_PAGES_CMP_RING
> PVSCSI_SETUP_RINGS_MAX_NUM_PAGES
> +#define PVSCSI_MAX_NUM_PAGES_MSG_RING
> PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES
> +
> +#define PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE \
> + (VMW_PAGE_SIZE / sizeof(struct PVSCSIRingReqDesc))
> +
> +#define PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE \
> + (VMW_PAGE_SIZE / sizeof(PVSCSIRingCmpDesc))
> +
> +#define PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE \
> + (VMW_PAGE_SIZE / sizeof(PVSCSIRingMsgDesc))
> +
> +#define PVSCSI_MAX_REQ_QUEUE_DEPTH \
> + (PVSCSI_MAX_NUM_PAGES_REQ_RING *
> PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE)
> +
> +#define PVSCSI_MEM_SPACE_COMMAND_NUM_PAGES 1
> +#define PVSCSI_MEM_SPACE_INTR_STATUS_NUM_PAGES 1
> +#define PVSCSI_MEM_SPACE_MISC_NUM_PAGES 2
> +#define PVSCSI_MEM_SPACE_KICK_IO_NUM_PAGES 2
> +#define PVSCSI_MEM_SPACE_MSIX_NUM_PAGES 2
> +
> +enum PVSCSIMemSpace {
> + PVSCSI_MEM_SPACE_COMMAND_PAGE = 0,
> + PVSCSI_MEM_SPACE_INTR_STATUS_PAGE = 1,
> + PVSCSI_MEM_SPACE_MISC_PAGE = 2,
> + PVSCSI_MEM_SPACE_KICK_IO_PAGE = 4,
> + PVSCSI_MEM_SPACE_MSIX_TABLE_PAGE = 6,
> + PVSCSI_MEM_SPACE_MSIX_PBA_PAGE = 7,
> +};
> +
> +#define PVSCSI_MEM_SPACE_NUM_PAGES \
> + (PVSCSI_MEM_SPACE_COMMAND_NUM_PAGES + \
> + PVSCSI_MEM_SPACE_INTR_STATUS_NUM_PAGES + \
> + PVSCSI_MEM_SPACE_MISC_NUM_PAGES + \
> + PVSCSI_MEM_SPACE_KICK_IO_NUM_PAGES + \
> + PVSCSI_MEM_SPACE_MSIX_NUM_PAGES)
> +
> +#define PVSCSI_MEM_SPACE_SIZE (PVSCSI_MEM_SPACE_NUM_PAGES
> * VMW_PAGE_SIZE)
> +
> +#endif /* VMW_PVSCSI_H */
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index 05315c0..2c138b1 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -59,6 +59,7 @@
> #define PCI_DEVICE_ID_VMWARE_SVGA 0x0710
> #define PCI_DEVICE_ID_VMWARE_NET 0x0720
> #define PCI_DEVICE_ID_VMWARE_SCSI 0x0730
> +#define PCI_DEVICE_ID_VMWARE_PVSCSI 0x07C0
> #define PCI_DEVICE_ID_VMWARE_IDE 0x1729
> #define PCI_DEVICE_ID_VMWARE_VMXNET3 0x07B0
>
> diff --git a/trace-events b/trace-events
> index 581d67a..e587487 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -766,6 +766,41 @@ pc87312_info_ide(uint32_t base) "base 0x%x"
> pc87312_info_parallel(uint32_t base, uint32_t irq) "base 0x%x, irq %u"
> pc87312_info_serial(int n, uint32_t base, uint32_t irq) "id=%d, base 0x%x,
> irq %u"
>
> +# hw/scsi/vmw_pvscsi.c
> +pvscsi_ring_init_data(uint32_t txr_len_log2, uint32_t rxr_len_log2) "TX/RX
> rings logarithms set to %d/%d"
> +pvscsi_ring_init_msg(uint32_t len_log2) "MSG ring logarithm set to %d"
> +pvscsi_ring_flush_cmp(uint64_t filled_cmp_ptr) "new production counter of
> completion ring is 0x%"PRIx64""
> +pvscsi_ring_flush_msg(uint64_t filled_cmp_ptr) "new production counter of
> message ring is 0x%"PRIx64""
> +pvscsi_update_irq_level(bool raise, uint64_t mask, uint64_t status)
> "interrupt level set to %d (MASK: 0x%"PRIx64", STATUS: 0x%"PRIx64")"
> +pvscsi_update_irq_msi(void) "sending MSI notification"
> +pvscsi_cmp_ring_put(unsigned long addr) "got completion descriptor
> 0x%lx"
> +pvscsi_msg_ring_put(unsigned long addr) "got message descriptor 0x%lx"
> +pvscsi_complete_request(uint64_t context, uint64_t len, uint8_t sense_key)
> "completion: ctx: 0x%"PRIx64", len: 0x%"PRIx64", sense key: %u"
> +pvscsi_get_sg_list(int nsg, size_t size) "get SG list: depth: %u, size: %lu"
> +pvscsi_get_next_sg_elem(uint32_t flags) "unknown flags in SG element (val:
> 0x%x)"
> +pvscsi_command_complete_not_found(uint32_t tag) "can't find request for
> tag 0x%x"
> +pvscsi_command_complete_data_run(void) "not all data required for
> command transferred"
> +pvscsi_command_complete_sense_len(int len) "sense information length
> is %d bytes"
> +pvscsi_convert_sglist(uint64_t context, unsigned long addr, uint32_t resid)
> "element: ctx: 0x%"PRIx64" addr: 0x%lx, len: %ul"
> +pvscsi_process_req_descr(uint8_t cmd, uint64_t ctx) "SCSI cmd 0x%x, ctx:
> 0x%"PRIx64""
> +pvscsi_process_req_descr_unknown_device(void) "command directed to
> unknown device rejected"
> +pvscsi_process_req_descr_invalid_dir(void) "command with invalid transfer
> direction rejected"
> +pvscsi_process_io(unsigned long addr) "got descriptor 0x%lx"
> +pvscsi_on_cmd_noimpl(const char* cmd) "unimplemented command %s
> ignored"
> +pvscsi_on_cmd_reset_dev(uint32_t tgt, int lun, void* dev)
> "PVSCSI_CMD_RESET_DEVICE[target %u lun %d (dev 0x%p)]"
> +pvscsi_on_cmd_arrived(const char* cmd) "command %s arrived"
> +pvscsi_on_cmd_abort(uint64_t ctx, uint32_t tgt) "command
> PVSCSI_CMD_ABORT_CMD for ctx 0x%"PRIx64", target %u"
> +pvscsi_on_cmd_unknown(uint64_t cmd_id) "unknown
> command %"PRIx64""
> +pvscsi_on_cmd_unknown_data(uint32_t data) "data for unknown
> command 0x:%x"
> +pvscsi_io_write(const char* cmd, uint64_t val) "%s write: %"PRIx64""
> +pvscsi_io_write_unknown(unsigned long addr, unsigned sz, uint64_t val)
> "unknown write address: 0x%lx size: %u bytes value: 0x%"PRIx64""
> +pvscsi_io_read(const char* cmd, uint64_t status) "%s read: 0x%"PRIx64""
> +pvscsi_io_read_unknown(unsigned long addr, unsigned sz) "unknown read
> address: 0x%lx size: %u bytes"
> +pvscsi_init_msi_fail(int res) "failed to initialize MSI, error %d"
> +pvscsi_state(const char* state) "starting %s ..."
> +pvscsi_tx_rings_ppn(const char* label, uint64_t ppn) "%s page: %"PRIx64""
> +pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number
> of %s pages: %u"
> +
> # xen-all.c
> xen_ram_alloc(unsigned long ram_addr, unsigned long size)
> "requested: %#lx, size %#lx"
> xen_client_set_memory(uint64_t start_addr, unsigned long size, bool
> log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
> --
> 1.8.1.4
>
>
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device implementation
2013-06-21 3:47 ` Libaiqing
@ 2013-06-21 7:36 ` Paolo Bonzini
2013-06-21 11:44 ` Dmitry Fleytman
0 siblings, 1 reply; 56+ messages in thread
From: Paolo Bonzini @ 2013-06-21 7:36 UTC (permalink / raw)
To: Libaiqing
Cc: Dmitry Fleytman, Yan Vugenfirer, asias@redhat.com,
qemu-devel@nongnu.org, nab@linux-iscsi.org
Il 21/06/2013 05:47, Libaiqing ha scritto:
> Hi paolo,
> The PVSCSI device can be used as boot device?
> I tested with fedora17 + kernel 3.6 ,but failed.Qemu commit id is " 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> PVSCSI device used as non-boot device works well.partition,mkfs,mount,dd,ok.
> Could you give me some advise to debug this problem ? I can provide more information if need.
No, there is no support in SeaBIOS for it.
Paolo
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device implementation
2013-06-21 7:36 ` Paolo Bonzini
@ 2013-06-21 11:44 ` Dmitry Fleytman
2013-06-21 12:00 ` Paolo Bonzini
0 siblings, 1 reply; 56+ messages in thread
From: Dmitry Fleytman @ 2013-06-21 11:44 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Yan Vugenfirer, Libaiqing, qemu-devel@nongnu.org,
nab@linux-iscsi.org, asias@redhat.com
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
BTW,
Can't we add to QEMU some simplified interface (device) for boot time only,
so that system will be able to boot without SeaBIOS support for specific
device?
Regards,
Dmitry
On Fri, Jun 21, 2013 at 10:36 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 21/06/2013 05:47, Libaiqing ha scritto:
> > Hi paolo,
> > The PVSCSI device can be used as boot device?
> > I tested with fedora17 + kernel 3.6 ,but failed.Qemu commit id is "
> 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> > PVSCSI device used as non-boot device works
> well.partition,mkfs,mount,dd,ok.
> > Could you give me some advise to debug this problem ? I can provide
> more information if need.
>
> No, there is no support in SeaBIOS for it.
>
> Paolo
>
>
[-- Attachment #2: Type: text/html, Size: 1302 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device implementation
2013-06-21 11:44 ` Dmitry Fleytman
@ 2013-06-21 12:00 ` Paolo Bonzini
0 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-06-21 12:00 UTC (permalink / raw)
To: Dmitry Fleytman
Cc: Yan Vugenfirer, Libaiqing, qemu-devel@nongnu.org,
nab@linux-iscsi.org, asias@redhat.com
Il 21/06/2013 13:44, Dmitry Fleytman ha scritto:
> BTW,
>
> Can't we add to QEMU some simplified interface (device) for boot time only,
> so that system will be able to boot without SeaBIOS support for specific
> device?
We had it, and we dropped it. :)
Writing a SeaBIOS driver is very easy, and the biggest limitation of
pvscsi is that it doesn't support the VMware option ROM. There is a
simple interface using only I/O BARs, or so I was told, exactly for the
purpose of booting---but we do not implement that interface. I'm not
sure how hard it would be to reverse engineere it, I do not have access
to vSphere.
Paolo
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Qemu-devel] [PATCH 3/9] vhost: Add vhost_commit callback for SeaBIOS ROM region re-mapping
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 1/9] scsi: avoid assertion failure on VERIFY command Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 2/9] scsi: VMWare PVSCSI paravirtual device implementation Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 4/9] virtio-scsi: create VirtIOSCSICommon Paolo Bonzini
` (8 subsequent siblings)
11 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: asias, nab, Michael S. Tsirkin
From: Nicholas Bellinger <nab@linux-iscsi.org>
This patch follows MST's recommendation to move checks for
vhost_verify_ring_mappings() -> cpu_physical_memory_map() operations
from MemoryListener->region_[add,del]() -> vhost_set_memory() into
final MemoryListener->commit() -> vhost_commit() callback.
It addresses the case where virtio-scsi vq ioport RAM re-mapping
to read-only SeaBIOS ROM triggers a cpu_physical_memory_map()
NIL MemoryRegionSection pointer failure.
Also save vhost_dev->mem_changed_[start,end]_addr values in
vhost_set_memory() for final ranges_overlap checks. (Thanks Paolo!)
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Asias He <asias@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/virtio/vhost.c | 53 +++++++++++++++++++++++++++++++++--------------
include/hw/virtio/vhost.h | 3 +++
2 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 636fad0..40feab4 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -382,8 +382,6 @@ static void vhost_set_memory(MemoryListener *listener,
bool log_dirty = memory_region_is_logging(section->mr);
int s = offsetof(struct vhost_memory, regions) +
(dev->mem->nregions + 1) * sizeof dev->mem->regions[0];
- uint64_t log_size;
- int r;
void *ram;
dev->mem = g_realloc(dev->mem, s);
@@ -416,12 +414,47 @@ static void vhost_set_memory(MemoryListener *listener,
/* Remove old mapping for this memory, if any. */
vhost_dev_unassign_memory(dev, start_addr, size);
}
+ dev->mem_changed_start_addr = MIN(dev->mem_changed_start_addr, start_addr);
+ dev->mem_changed_end_addr = MAX(dev->mem_changed_end_addr, start_addr + size - 1);
+ dev->memory_changed = true;
+}
+
+static bool vhost_section(MemoryRegionSection *section)
+{
+ return memory_region_is_ram(section->mr);
+}
+
+static void vhost_begin(MemoryListener *listener)
+{
+ struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+ memory_listener);
+ dev->mem_changed_end_addr = 0;
+ dev->mem_changed_start_addr = -1;
+}
+static void vhost_commit(MemoryListener *listener)
+{
+ struct vhost_dev *dev = container_of(listener, struct vhost_dev,
+ memory_listener);
+ hwaddr start_addr = 0;
+ ram_addr_t size = 0;
+ uint64_t log_size;
+ int r;
+
+ if (!dev->memory_changed) {
+ return;
+ }
if (!dev->started) {
return;
}
+ if (dev->mem_changed_start_addr > dev->mem_changed_end_addr) {
+ return;
+ }
if (dev->started) {
+ start_addr = dev->mem_changed_start_addr;
+ size = dev->mem_changed_end_addr - dev->mem_changed_start_addr + 1;
+
r = vhost_verify_ring_mappings(dev, start_addr, size);
assert(r >= 0);
}
@@ -429,6 +462,7 @@ static void vhost_set_memory(MemoryListener *listener,
if (!dev->log_enabled) {
r = ioctl(dev->control, VHOST_SET_MEM_TABLE, dev->mem);
assert(r >= 0);
+ dev->memory_changed = false;
return;
}
log_size = vhost_get_log_size(dev);
@@ -445,19 +479,7 @@ static void vhost_set_memory(MemoryListener *listener,
if (dev->log_size > log_size + VHOST_LOG_BUFFER) {
vhost_dev_log_resize(dev, log_size);
}
-}
-
-static bool vhost_section(MemoryRegionSection *section)
-{
- return memory_region_is_ram(section->mr);
-}
-
-static void vhost_begin(MemoryListener *listener)
-{
-}
-
-static void vhost_commit(MemoryListener *listener)
-{
+ dev->memory_changed = false;
}
static void vhost_region_add(MemoryListener *listener,
@@ -842,6 +864,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, const char *devpath,
hdev->log_size = 0;
hdev->log_enabled = false;
hdev->started = false;
+ hdev->memory_changed = false;
memory_listener_register(&hdev->memory_listener, &address_space_memory);
hdev->force = force;
return 0;
diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index b373be0..de24746 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -45,6 +45,9 @@ struct vhost_dev {
vhost_log_chunk_t *log;
unsigned long long log_size;
bool force;
+ bool memory_changed;
+ hwaddr mem_changed_start_addr;
+ hwaddr mem_changed_end_addr;
};
int vhost_dev_init(struct vhost_dev *hdev, int devfd, const char *devpath,
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Qemu-devel] [PATCH 4/9] virtio-scsi: create VirtIOSCSICommon
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (2 preceding siblings ...)
2013-04-19 14:24 ` [Qemu-devel] [PATCH 3/9] vhost: Add vhost_commit callback for SeaBIOS ROM region re-mapping Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 5/9] virtio: simplify Makefile conditionals Paolo Bonzini
` (7 subsequent siblings)
11 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: asias, nab, Michael S. Tsirkin
This patch refactors existing virtio-scsi code into VirtIOSCSICommon
in order to allow virtio_scsi_init_common() to be used by both internal
virtio_scsi_init() and external vhost-scsi-pci code.
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Asias He <asias@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/s390x/s390-virtio-bus.c | 2 +-
hw/s390x/virtio-ccw.c | 2 +-
hw/scsi/virtio-scsi.c | 212 ++++++++++++++--------------------------
hw/virtio/virtio-pci.c | 5 +-
include/hw/virtio/virtio-scsi.h | 133 ++++++++++++++++++++++++-
include/qemu/osdep.h | 4 +
6 files changed, 210 insertions(+), 148 deletions(-)
diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index ca0e301..8f29b5e 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -560,7 +560,7 @@ static const TypeInfo virtio_s390_device_info = {
};
static Property s390_virtio_scsi_properties[] = {
- DEFINE_VIRTIO_SCSI_PROPERTIES(VirtIOSCSIS390, vdev.conf),
+ DEFINE_VIRTIO_SCSI_PROPERTIES(VirtIOSCSIS390, vdev.parent_obj.conf),
DEFINE_VIRTIO_SCSI_FEATURES(VirtIOS390Device, host_features),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index e9e7509..5232526 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -873,7 +873,7 @@ static const TypeInfo virtio_ccw_balloon = {
static Property virtio_ccw_scsi_properties[] = {
DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
- DEFINE_VIRTIO_SCSI_PROPERTIES(VirtIOSCSICcw, vdev.conf),
+ DEFINE_VIRTIO_SCSI_PROPERTIES(VirtIOSCSICcw, vdev.parent_obj.conf),
DEFINE_VIRTIO_SCSI_FEATURES(VirtioCcwDevice, host_features[0]),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index ead7cda..051daea 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -19,118 +19,6 @@
#include <block/scsi.h>
#include <hw/virtio/virtio-bus.h>
-#define VIRTIO_SCSI_VQ_SIZE 128
-#define VIRTIO_SCSI_CDB_SIZE 32
-#define VIRTIO_SCSI_SENSE_SIZE 96
-#define VIRTIO_SCSI_MAX_CHANNEL 0
-#define VIRTIO_SCSI_MAX_TARGET 255
-#define VIRTIO_SCSI_MAX_LUN 16383
-
-/* Response codes */
-#define VIRTIO_SCSI_S_OK 0
-#define VIRTIO_SCSI_S_OVERRUN 1
-#define VIRTIO_SCSI_S_ABORTED 2
-#define VIRTIO_SCSI_S_BAD_TARGET 3
-#define VIRTIO_SCSI_S_RESET 4
-#define VIRTIO_SCSI_S_BUSY 5
-#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6
-#define VIRTIO_SCSI_S_TARGET_FAILURE 7
-#define VIRTIO_SCSI_S_NEXUS_FAILURE 8
-#define VIRTIO_SCSI_S_FAILURE 9
-#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED 10
-#define VIRTIO_SCSI_S_FUNCTION_REJECTED 11
-#define VIRTIO_SCSI_S_INCORRECT_LUN 12
-
-/* Controlq type codes. */
-#define VIRTIO_SCSI_T_TMF 0
-#define VIRTIO_SCSI_T_AN_QUERY 1
-#define VIRTIO_SCSI_T_AN_SUBSCRIBE 2
-
-/* Valid TMF subtypes. */
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK 0
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET 1
-#define VIRTIO_SCSI_T_TMF_CLEAR_ACA 2
-#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET 3
-#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET 4
-#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET 5
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK 6
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET 7
-
-/* Events. */
-#define VIRTIO_SCSI_T_EVENTS_MISSED 0x80000000
-#define VIRTIO_SCSI_T_NO_EVENT 0
-#define VIRTIO_SCSI_T_TRANSPORT_RESET 1
-#define VIRTIO_SCSI_T_ASYNC_NOTIFY 2
-#define VIRTIO_SCSI_T_PARAM_CHANGE 3
-
-/* Reasons for transport reset event */
-#define VIRTIO_SCSI_EVT_RESET_HARD 0
-#define VIRTIO_SCSI_EVT_RESET_RESCAN 1
-#define VIRTIO_SCSI_EVT_RESET_REMOVED 2
-
-/* SCSI command request, followed by data-out */
-typedef struct {
- uint8_t lun[8]; /* Logical Unit Number */
- uint64_t tag; /* Command identifier */
- uint8_t task_attr; /* Task attribute */
- uint8_t prio;
- uint8_t crn;
- uint8_t cdb[];
-} QEMU_PACKED VirtIOSCSICmdReq;
-
-/* Response, followed by sense data and data-in */
-typedef struct {
- uint32_t sense_len; /* Sense data length */
- uint32_t resid; /* Residual bytes in data buffer */
- uint16_t status_qualifier; /* Status qualifier */
- uint8_t status; /* Command completion status */
- uint8_t response; /* Response values */
- uint8_t sense[];
-} QEMU_PACKED VirtIOSCSICmdResp;
-
-/* Task Management Request */
-typedef struct {
- uint32_t type;
- uint32_t subtype;
- uint8_t lun[8];
- uint64_t tag;
-} QEMU_PACKED VirtIOSCSICtrlTMFReq;
-
-typedef struct {
- uint8_t response;
-} QEMU_PACKED VirtIOSCSICtrlTMFResp;
-
-/* Asynchronous notification query/subscription */
-typedef struct {
- uint32_t type;
- uint8_t lun[8];
- uint32_t event_requested;
-} QEMU_PACKED VirtIOSCSICtrlANReq;
-
-typedef struct {
- uint32_t event_actual;
- uint8_t response;
-} QEMU_PACKED VirtIOSCSICtrlANResp;
-
-typedef struct {
- uint32_t event;
- uint8_t lun[8];
- uint32_t reason;
-} QEMU_PACKED VirtIOSCSIEvent;
-
-typedef struct {
- uint32_t num_queues;
- uint32_t seg_max;
- uint32_t max_sectors;
- uint32_t cmd_per_lun;
- uint32_t event_info_size;
- uint32_t sense_size;
- uint32_t cdb_size;
- uint16_t max_channel;
- uint16_t max_target;
- uint32_t max_lun;
-} QEMU_PACKED VirtIOSCSIConfig;
-
typedef struct VirtIOSCSIReq {
VirtIOSCSI *dev;
VirtQueue *vq;
@@ -237,9 +125,10 @@ static VirtIOSCSIReq *virtio_scsi_pop_req(VirtIOSCSI *s, VirtQueue *vq)
static void virtio_scsi_save_request(QEMUFile *f, SCSIRequest *sreq)
{
VirtIOSCSIReq *req = sreq->hba_private;
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(req->dev);
uint32_t n = virtio_queue_get_id(req->vq) - 2;
- assert(n < req->dev->conf.num_queues);
+ assert(n < vs->conf.num_queues);
qemu_put_be32s(f, &n);
qemu_put_buffer(f, (unsigned char *)&req->elem, sizeof(req->elem));
}
@@ -248,14 +137,15 @@ static void *virtio_scsi_load_request(QEMUFile *f, SCSIRequest *sreq)
{
SCSIBus *bus = sreq->bus;
VirtIOSCSI *s = container_of(bus, VirtIOSCSI, bus);
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
VirtIOSCSIReq *req;
uint32_t n;
req = g_malloc(sizeof(*req));
qemu_get_be32s(f, &n);
- assert(n < s->conf.num_queues);
+ assert(n < vs->conf.num_queues);
qemu_get_buffer(f, (unsigned char *)&req->elem, sizeof(req->elem));
- virtio_scsi_parse_req(s, s->cmd_vqs[n], req);
+ virtio_scsi_parse_req(s, vs->cmd_vqs[n], req);
scsi_req_ref(sreq);
req->sreq = sreq;
@@ -457,7 +347,10 @@ static void virtio_scsi_fail_cmd_req(VirtIOSCSIReq *req)
static void virtio_scsi_handle_cmd(VirtIODevice *vdev, VirtQueue *vq)
{
+ /* use non-QOM casts in the data path */
VirtIOSCSI *s = (VirtIOSCSI *)vdev;
+ VirtIOSCSICommon *vs = &s->parent_obj;
+
VirtIOSCSIReq *req;
int n;
@@ -470,8 +363,8 @@ static void virtio_scsi_handle_cmd(VirtIODevice *vdev, VirtQueue *vq)
out_size = req->elem.out_sg[0].iov_len;
in_size = req->elem.in_sg[0].iov_len;
- if (out_size < sizeof(VirtIOSCSICmdReq) + s->cdb_size ||
- in_size < sizeof(VirtIOSCSICmdResp) + s->sense_size) {
+ if (out_size < sizeof(VirtIOSCSICmdReq) + vs->cdb_size ||
+ in_size < sizeof(VirtIOSCSICmdResp) + vs->sense_size) {
virtio_scsi_bad_req();
}
@@ -513,7 +406,7 @@ static void virtio_scsi_get_config(VirtIODevice *vdev,
uint8_t *config)
{
VirtIOSCSIConfig *scsiconf = (VirtIOSCSIConfig *)config;
- VirtIOSCSI *s = (VirtIOSCSI *)vdev;
+ VirtIOSCSICommon *s = VIRTIO_SCSI_COMMON(vdev);
stl_raw(&scsiconf->num_queues, s->conf.num_queues);
stl_raw(&scsiconf->seg_max, 128 - 2);
@@ -531,7 +424,7 @@ static void virtio_scsi_set_config(VirtIODevice *vdev,
const uint8_t *config)
{
VirtIOSCSIConfig *scsiconf = (VirtIOSCSIConfig *)config;
- VirtIOSCSI *s = (VirtIOSCSI *)vdev;
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
if ((uint32_t) ldl_raw(&scsiconf->sense_size) >= 65536 ||
(uint32_t) ldl_raw(&scsiconf->cdb_size) >= 256) {
@@ -539,8 +432,8 @@ static void virtio_scsi_set_config(VirtIODevice *vdev,
exit(1);
}
- s->sense_size = ldl_raw(&scsiconf->sense_size);
- s->cdb_size = ldl_raw(&scsiconf->cdb_size);
+ vs->sense_size = ldl_raw(&scsiconf->sense_size);
+ vs->cdb_size = ldl_raw(&scsiconf->cdb_size);
}
static uint32_t virtio_scsi_get_features(VirtIODevice *vdev,
@@ -551,14 +444,15 @@ static uint32_t virtio_scsi_get_features(VirtIODevice *vdev,
static void virtio_scsi_reset(VirtIODevice *vdev)
{
- VirtIOSCSI *s = (VirtIOSCSI *)vdev;
+ VirtIOSCSI *s = VIRTIO_SCSI(vdev);
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
s->resetting++;
qbus_reset_all(&s->bus.qbus);
s->resetting--;
- s->sense_size = VIRTIO_SCSI_SENSE_SIZE;
- s->cdb_size = VIRTIO_SCSI_CDB_SIZE;
+ vs->sense_size = VIRTIO_SCSI_SENSE_SIZE;
+ vs->cdb_size = VIRTIO_SCSI_CDB_SIZE;
s->events_dropped = false;
}
@@ -586,7 +480,8 @@ static int virtio_scsi_load(QEMUFile *f, void *opaque, int version_id)
static void virtio_scsi_push_event(VirtIOSCSI *s, SCSIDevice *dev,
uint32_t event, uint32_t reason)
{
- VirtIOSCSIReq *req = virtio_scsi_pop_req(s, s->event_vq);
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
+ VirtIOSCSIReq *req = virtio_scsi_pop_req(s, vs->event_vq);
VirtIOSCSIEvent *evt;
VirtIODevice *vdev = VIRTIO_DEVICE(s);
int in_size;
@@ -692,23 +587,19 @@ static struct SCSIBusInfo virtio_scsi_scsi_info = {
.load_request = virtio_scsi_load_request,
};
-static int virtio_scsi_device_init(VirtIODevice *vdev)
+int virtio_scsi_common_init(VirtIOSCSICommon *s)
{
- DeviceState *qdev = DEVICE(vdev);
- VirtIOSCSI *s = VIRTIO_SCSI(vdev);
- static int virtio_scsi_id;
+ VirtIODevice *vdev = VIRTIO_DEVICE(s);
int i;
virtio_init(VIRTIO_DEVICE(s), "virtio-scsi", VIRTIO_ID_SCSI,
sizeof(VirtIOSCSIConfig));
s->cmd_vqs = g_malloc0(s->conf.num_queues * sizeof(VirtQueue *));
+ s->sense_size = VIRTIO_SCSI_SENSE_SIZE;
+ s->cdb_size = VIRTIO_SCSI_CDB_SIZE;
- /* TODO set up vdev function pointers */
vdev->get_config = virtio_scsi_get_config;
- vdev->set_config = virtio_scsi_set_config;
- vdev->get_features = virtio_scsi_get_features;
- vdev->reset = virtio_scsi_reset;
s->ctrl_vq = virtio_add_queue(vdev, VIRTIO_SCSI_VQ_SIZE,
virtio_scsi_handle_ctrl);
@@ -719,6 +610,26 @@ static int virtio_scsi_device_init(VirtIODevice *vdev)
virtio_scsi_handle_cmd);
}
+ return 0;
+}
+
+static int virtio_scsi_device_init(VirtIODevice *vdev)
+{
+ DeviceState *qdev = DEVICE(vdev);
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+ VirtIOSCSI *s = VIRTIO_SCSI(vdev);
+ static int virtio_scsi_id;
+ int ret;
+
+ ret = virtio_scsi_common_init(vs);
+ if (ret < 0) {
+ return ret;
+ }
+
+ vdev->get_features = virtio_scsi_get_features;
+ vdev->set_config = virtio_scsi_set_config;
+ vdev->reset = virtio_scsi_reset;
+
scsi_bus_new(&s->bus, qdev, &virtio_scsi_scsi_info);
if (!qdev->hotplugged) {
scsi_bus_legacy_handle_cmdline(&s->bus);
@@ -730,22 +641,36 @@ static int virtio_scsi_device_init(VirtIODevice *vdev)
return 0;
}
+int virtio_scsi_common_exit(VirtIOSCSICommon *vs)
+{
+ VirtIODevice *vdev = VIRTIO_DEVICE(vs);
+
+ g_free(vs->cmd_vqs);
+ virtio_common_cleanup(vdev);
+ return 0;
+}
+
static int virtio_scsi_device_exit(DeviceState *qdev)
{
VirtIOSCSI *s = VIRTIO_SCSI(qdev);
- VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(qdev);
unregister_savevm(qdev, "virtio-scsi", s);
- g_free(s->cmd_vqs);
- virtio_common_cleanup(vdev);
- return 0;
+ return virtio_scsi_common_exit(vs);
}
static Property virtio_scsi_properties[] = {
- DEFINE_VIRTIO_SCSI_PROPERTIES(VirtIOSCSI, conf),
+ DEFINE_VIRTIO_SCSI_PROPERTIES(VirtIOSCSI, parent_obj.conf),
DEFINE_PROP_END_OF_LIST(),
};
+static void virtio_scsi_common_class_init(ObjectClass *klass, void *data)
+{
+ VirtioDeviceClass *vdc = VIRTIO_DEVICE_CLASS(klass);
+
+ vdc->get_config = virtio_scsi_get_config;
+}
+
static void virtio_scsi_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
@@ -753,21 +678,28 @@ static void virtio_scsi_class_init(ObjectClass *klass, void *data)
dc->exit = virtio_scsi_device_exit;
dc->props = virtio_scsi_properties;
vdc->init = virtio_scsi_device_init;
- vdc->get_config = virtio_scsi_get_config;
vdc->set_config = virtio_scsi_set_config;
vdc->get_features = virtio_scsi_get_features;
vdc->reset = virtio_scsi_reset;
}
+static const TypeInfo virtio_scsi_common_info = {
+ .name = TYPE_VIRTIO_SCSI_COMMON,
+ .parent = TYPE_VIRTIO_DEVICE,
+ .instance_size = sizeof(VirtIOSCSICommon),
+ .class_init = virtio_scsi_common_class_init,
+};
+
static const TypeInfo virtio_scsi_info = {
.name = TYPE_VIRTIO_SCSI,
- .parent = TYPE_VIRTIO_DEVICE,
+ .parent = TYPE_VIRTIO_SCSI_COMMON,
.instance_size = sizeof(VirtIOSCSI),
.class_init = virtio_scsi_class_init,
};
static void virtio_register_types(void)
{
+ type_register_static(&virtio_scsi_common_info);
type_register_static(&virtio_scsi_info);
}
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index e2d1693..b362cc8 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1236,7 +1236,7 @@ static Property virtio_scsi_pci_properties[] = {
DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors,
DEV_NVECTORS_UNSPECIFIED),
DEFINE_VIRTIO_SCSI_FEATURES(VirtIOPCIProxy, host_features),
- DEFINE_VIRTIO_SCSI_PROPERTIES(VirtIOSCSIPCI, vdev.conf),
+ DEFINE_VIRTIO_SCSI_PROPERTIES(VirtIOSCSIPCI, vdev.parent_obj.conf),
DEFINE_PROP_END_OF_LIST(),
};
@@ -1244,9 +1244,10 @@ static int virtio_scsi_pci_init_pci(VirtIOPCIProxy *vpci_dev)
{
VirtIOSCSIPCI *dev = VIRTIO_SCSI_PCI(vpci_dev);
DeviceState *vdev = DEVICE(&dev->vdev);
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {
- vpci_dev->nvectors = dev->vdev.conf.num_queues + 3;
+ vpci_dev->nvectors = vs->conf.num_queues + 3;
}
qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h
index ccd7b06..4a961b9 100644
--- a/include/hw/virtio/virtio-scsi.h
+++ b/include/hw/virtio/virtio-scsi.h
@@ -18,6 +18,10 @@
#include "hw/pci/pci.h"
#include "hw/scsi/scsi.h"
+#define TYPE_VIRTIO_SCSI_COMMON "virtio-scsi-common"
+#define VIRTIO_SCSI_COMMON(obj) \
+ OBJECT_CHECK(VirtIOSCSICommon, (obj), TYPE_VIRTIO_SCSI_COMMON)
+
#define TYPE_VIRTIO_SCSI "virtio-scsi-device"
#define VIRTIO_SCSI(obj) \
OBJECT_CHECK(VirtIOSCSI, (obj), TYPE_VIRTIO_SCSI)
@@ -31,24 +35,141 @@
#define VIRTIO_SCSI_F_HOTPLUG 1
#define VIRTIO_SCSI_F_CHANGE 2
+#define VIRTIO_SCSI_VQ_SIZE 128
+#define VIRTIO_SCSI_CDB_SIZE 32
+#define VIRTIO_SCSI_SENSE_SIZE 96
+#define VIRTIO_SCSI_MAX_CHANNEL 0
+#define VIRTIO_SCSI_MAX_TARGET 255
+#define VIRTIO_SCSI_MAX_LUN 16383
+
+/* Response codes */
+#define VIRTIO_SCSI_S_OK 0
+#define VIRTIO_SCSI_S_OVERRUN 1
+#define VIRTIO_SCSI_S_ABORTED 2
+#define VIRTIO_SCSI_S_BAD_TARGET 3
+#define VIRTIO_SCSI_S_RESET 4
+#define VIRTIO_SCSI_S_BUSY 5
+#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6
+#define VIRTIO_SCSI_S_TARGET_FAILURE 7
+#define VIRTIO_SCSI_S_NEXUS_FAILURE 8
+#define VIRTIO_SCSI_S_FAILURE 9
+#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED 10
+#define VIRTIO_SCSI_S_FUNCTION_REJECTED 11
+#define VIRTIO_SCSI_S_INCORRECT_LUN 12
+
+/* Controlq type codes. */
+#define VIRTIO_SCSI_T_TMF 0
+#define VIRTIO_SCSI_T_AN_QUERY 1
+#define VIRTIO_SCSI_T_AN_SUBSCRIBE 2
+
+/* Valid TMF subtypes. */
+#define VIRTIO_SCSI_T_TMF_ABORT_TASK 0
+#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET 1
+#define VIRTIO_SCSI_T_TMF_CLEAR_ACA 2
+#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET 3
+#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET 4
+#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET 5
+#define VIRTIO_SCSI_T_TMF_QUERY_TASK 6
+#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET 7
+
+/* Events. */
+#define VIRTIO_SCSI_T_EVENTS_MISSED 0x80000000
+#define VIRTIO_SCSI_T_NO_EVENT 0
+#define VIRTIO_SCSI_T_TRANSPORT_RESET 1
+#define VIRTIO_SCSI_T_ASYNC_NOTIFY 2
+#define VIRTIO_SCSI_T_PARAM_CHANGE 3
+
+/* Reasons for transport reset event */
+#define VIRTIO_SCSI_EVT_RESET_HARD 0
+#define VIRTIO_SCSI_EVT_RESET_RESCAN 1
+#define VIRTIO_SCSI_EVT_RESET_REMOVED 2
+
+/* SCSI command request, followed by data-out */
+typedef struct {
+ uint8_t lun[8]; /* Logical Unit Number */
+ uint64_t tag; /* Command identifier */
+ uint8_t task_attr; /* Task attribute */
+ uint8_t prio;
+ uint8_t crn;
+ uint8_t cdb[];
+} QEMU_PACKED VirtIOSCSICmdReq;
+
+/* Response, followed by sense data and data-in */
+typedef struct {
+ uint32_t sense_len; /* Sense data length */
+ uint32_t resid; /* Residual bytes in data buffer */
+ uint16_t status_qualifier; /* Status qualifier */
+ uint8_t status; /* Command completion status */
+ uint8_t response; /* Response values */
+ uint8_t sense[];
+} QEMU_PACKED VirtIOSCSICmdResp;
+
+/* Task Management Request */
+typedef struct {
+ uint32_t type;
+ uint32_t subtype;
+ uint8_t lun[8];
+ uint64_t tag;
+} QEMU_PACKED VirtIOSCSICtrlTMFReq;
+
+typedef struct {
+ uint8_t response;
+} QEMU_PACKED VirtIOSCSICtrlTMFResp;
+
+/* Asynchronous notification query/subscription */
+typedef struct {
+ uint32_t type;
+ uint8_t lun[8];
+ uint32_t event_requested;
+} QEMU_PACKED VirtIOSCSICtrlANReq;
+
+typedef struct {
+ uint32_t event_actual;
+ uint8_t response;
+} QEMU_PACKED VirtIOSCSICtrlANResp;
+
+typedef struct {
+ uint32_t event;
+ uint8_t lun[8];
+ uint32_t reason;
+} QEMU_PACKED VirtIOSCSIEvent;
+
+typedef struct {
+ uint32_t num_queues;
+ uint32_t seg_max;
+ uint32_t max_sectors;
+ uint32_t cmd_per_lun;
+ uint32_t event_info_size;
+ uint32_t sense_size;
+ uint32_t cdb_size;
+ uint16_t max_channel;
+ uint16_t max_target;
+ uint32_t max_lun;
+} QEMU_PACKED VirtIOSCSIConfig;
+
struct VirtIOSCSIConf {
uint32_t num_queues;
uint32_t max_sectors;
uint32_t cmd_per_lun;
};
-typedef struct VirtIOSCSI {
+typedef struct VirtIOSCSICommon {
VirtIODevice parent_obj;
VirtIOSCSIConf conf;
- SCSIBus bus;
uint32_t sense_size;
uint32_t cdb_size;
- int resetting;
- bool events_dropped;
VirtQueue *ctrl_vq;
VirtQueue *event_vq;
VirtQueue **cmd_vqs;
+} VirtIOSCSICommon;
+
+typedef struct {
+ VirtIOSCSICommon parent_obj;
+
+ SCSIBus bus;
+ int resetting;
+ bool events_dropped;
} VirtIOSCSI;
#define DEFINE_VIRTIO_SCSI_PROPERTIES(_state, _conf_field) \
@@ -63,4 +184,8 @@ typedef struct VirtIOSCSI {
DEFINE_PROP_BIT("param_change", _state, _feature_field, \
VIRTIO_SCSI_F_CHANGE, true)
+int virtio_scsi_common_init(VirtIOSCSICommon *vs);
+int virtio_scsi_common_exit(VirtIOSCSICommon *vs);
+
+
#endif /* _QEMU_VIRTIO_SCSI_H */
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index df24400..8b465fd 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -67,6 +67,10 @@ typedef signed int int_fast16_t;
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif
+#ifndef ROUND_UP
+#define ROUND_UP(n,d) (((n) + (d) - 1) & -(d))
+#endif
+
#ifndef DIV_ROUND_UP
#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
#endif
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Qemu-devel] [PATCH 5/9] virtio: simplify Makefile conditionals
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (3 preceding siblings ...)
2013-04-19 14:24 ` [Qemu-devel] [PATCH 4/9] virtio-scsi: create VirtIOSCSICommon Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module Paolo Bonzini
` (6 subsequent siblings)
11 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: asias, nab
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/Makefile.objs | 2 +-
hw/virtio/Makefile.objs | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index b7a1613..0243d6a 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -24,7 +24,7 @@ devices-dirs-$(CONFIG_SOFTMMU) += ssi/
devices-dirs-$(CONFIG_SOFTMMU) += timer/
devices-dirs-$(CONFIG_TPM) += tpm/
devices-dirs-$(CONFIG_SOFTMMU) += usb/
-devices-dirs-$(CONFIG_SOFTMMU) += virtio/
+devices-dirs-$(CONFIG_VIRTIO) += virtio/
devices-dirs-$(CONFIG_SOFTMMU) += watchdog/
devices-dirs-$(CONFIG_SOFTMMU) += xen/
devices-dirs-y += core/
diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
index c7e8013..cbe6d51 100644
--- a/hw/virtio/Makefile.objs
+++ b/hw/virtio/Makefile.objs
@@ -1,7 +1,7 @@
-common-obj-$(CONFIG_VIRTIO) += virtio-rng.o
+common-obj-y += virtio-rng.o
common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
-common-obj-$(CONFIG_VIRTIO) += virtio-bus.o
+common-obj-y += virtio-bus.o
common-obj-$(CONFIG_VIRTIO_BLK_DATA_PLANE) += dataplane/
-obj-$(CONFIG_VIRTIO) += virtio.o virtio-balloon.o
-obj-$(CONFIG_VHOST_NET) += vhost.o
+obj-y += virtio.o virtio-balloon.o
+obj-$(CONFIG_LINUX) += vhost.o
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (4 preceding siblings ...)
2013-04-19 14:24 ` [Qemu-devel] [PATCH 5/9] virtio: simplify Makefile conditionals Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-05-28 7:13 ` Wenchao Xia
2013-04-19 14:24 ` [Qemu-devel] [PATCH 7/9] vhost-scsi-pci: " Paolo Bonzini
` (5 subsequent siblings)
11 siblings, 1 reply; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: asias, nab, Michael S. Tsirkin
From: Nicholas Bellinger <nab@linux-iscsi.org>
The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
available from the QEMU command-line. Instead, I hardcode it to zero.
Changes in Patch-v2:
- Add vhost_scsi_get_features() in order to determine feature bits
supports by host kernel (mst + nab)
- Re-enable usage of DEFINE_VIRTIO_COMMON_FEATURES, and allow
EVENT_IDX to be disabled by host in vhost_scsi_get_features()
- Drop unused hotplug bit in DEFINE_VHOST_SCSI_PROPERTIES
Changes in Patch-v1:
- Set event_idx=off by default (nab, thanks asias)
- Disable hotplug feature bit for v3.9 tcm_vhost kernel code, need to
re-enable in v3.10 (nab)
- Update to latest qemu.git/master HEAD
Changes in WIP-V3:
- Drop ioeventfd vhost_scsi_properties (asias, thanks stefanha)
- Add CONFIG_VHOST_SCSI (asias, thanks stefanha)
- Add hotplug feature bit
Changes in WIP-V2:
- Add backend guest masking support (nab)
- Bump ABI_VERSION to 1 (nab)
- Set up set_guest_notifiers (asias)
- Set up vs->dev.vq_index (asias)
- Drop vs->vs.vdev.{set,clear}_vhost_endpoint (asias)
- Drop VIRTIO_CONFIG_S_DRIVER check in vhost_scsi_set_status (asias)
Howto:
Use the latest seabios, at least commit b44a7be17b
git clone git://git.seabios.org/seabios.git
make
cp out/bios.bin /usr/share/qemu/bios.bin
qemu -device vhost-scsi-pci,wwpn=naa.6001405bd4e8476d
...
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Asias He <asias@redhat.com>
[ Rebase on top of VirtIOSCSICommon patch, fix bugs in feature
negotiation and irqfd masking - Paolo ]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
configure | 10 ++
hw/scsi/Makefile.objs | 6 +-
hw/scsi/vhost-scsi.c | 288 ++++++++++++++++++++++++++++++++++++++++
include/hw/virtio/vhost-scsi.h | 73 ++++++++++
include/hw/virtio/virtio-scsi.h | 2 +
5 files changed, 378 insertions(+), 1 deletion(-)
create mode 100644 hw/scsi/vhost-scsi.c
create mode 100644 include/hw/virtio/vhost-scsi.h
diff --git a/configure b/configure
index ed49f91..51a6c56 100755
--- a/configure
+++ b/configure
@@ -179,6 +179,7 @@ libattr=""
xfs=""
vhost_net="no"
+vhost_scsi="no"
kvm="no"
gprof="no"
debug_tcg="no"
@@ -543,6 +544,7 @@ Haiku)
usb="linux"
kvm="yes"
vhost_net="yes"
+ vhost_scsi="yes"
if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
audio_possible_drivers="$audio_possible_drivers fmod"
fi
@@ -870,6 +872,10 @@ for opt do
;;
--enable-vhost-net) vhost_net="yes"
;;
+ --disable-vhost-scsi) vhost_scsi="no"
+ ;;
+ --enable-vhost-scsi) vhost_scsi="yes"
+ ;;
--disable-glx) glx="no"
;;
--enable-glx) glx="yes"
@@ -3553,6 +3559,7 @@ echo "sigev_thread_id $sigev_thread_id"
echo "uuid support $uuid"
echo "libcap-ng support $cap_ng"
echo "vhost-net support $vhost_net"
+echo "vhost-scsi support $vhost_scsi"
echo "Trace backend $trace_backend"
echo "Trace output file $trace_file-<pid>"
echo "spice support $spice ($spice_protocol_version/$spice_server_version)"
@@ -3836,6 +3843,9 @@ fi
if test "$virtfs" = "yes" ; then
echo "CONFIG_VIRTFS=y" >> $config_host_mak
fi
+if test "$vhost_scsi" = "yes" ; then
+ echo "CONFIG_VHOST_SCSI=y" >> $config_host_mak
+fi
if test "$blobs" = "yes" ; then
echo "INSTALL_BLOBS=yes" >> $config_host_mak
fi
diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
index eaec6c8..121ddc5 100644
--- a/hw/scsi/Makefile.objs
+++ b/hw/scsi/Makefile.objs
@@ -6,4 +6,8 @@ common-obj-$(CONFIG_VMW_PVSCSI_SCSI_PCI) += vmw_pvscsi.o
common-obj-$(CONFIG_ESP) += esp.o
common-obj-$(CONFIG_ESP_PCI) += esp-pci.o
obj-$(CONFIG_PSERIES) += spapr_vscsi.o
-obj-$(CONFIG_VIRTIO) += virtio-scsi.o
+
+ifeq ($(CONFIG_VIRTIO),y)
+obj-y += virtio-scsi.o
+obj-$(CONFIG_VHOST_SCSI) += vhost-scsi.o
+endif
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
new file mode 100644
index 0000000..3dd1a0f
--- /dev/null
+++ b/hw/scsi/vhost-scsi.c
@@ -0,0 +1,288 @@
+/*
+ * vhost_scsi host device
+ *
+ * Copyright IBM, Corp. 2011
+ *
+ * Authors:
+ * Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
+ *
+ * Changes for QEMU mainline + tcm_vhost kernel upstream:
+ * Nicholas Bellinger <nab@risingtidesystems.com>
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include <sys/ioctl.h>
+#include "config.h"
+#include "qemu/queue.h"
+#include "monitor/monitor.h"
+#include "migration/migration.h"
+#include "hw/virtio/vhost-scsi.h"
+#include "hw/virtio/vhost.h"
+#include "hw/virtio/virtio-scsi.h"
+
+static int vhost_scsi_set_endpoint(VHostSCSI *s)
+{
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
+ struct vhost_scsi_target backend;
+ int ret;
+
+ memset(&backend, 0, sizeof(backend));
+ pstrcpy(backend.vhost_wwpn, sizeof(backend.vhost_wwpn), vs->conf.wwpn);
+ ret = ioctl(s->dev.control, VHOST_SCSI_SET_ENDPOINT, &backend);
+ if (ret < 0) {
+ return -errno;
+ }
+ return 0;
+}
+
+static void vhost_scsi_clear_endpoint(VHostSCSI *s)
+{
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
+ struct vhost_scsi_target backend;
+
+ memset(&backend, 0, sizeof(backend));
+ pstrcpy(backend.vhost_wwpn, sizeof(backend.vhost_wwpn), vs->conf.wwpn);
+ ioctl(s->dev.control, VHOST_SCSI_CLEAR_ENDPOINT, &backend);
+}
+
+static int vhost_scsi_start(VHostSCSI *s)
+{
+ int ret, abi_version, i;
+ VirtIODevice *vdev = VIRTIO_DEVICE(s);
+
+ if (!vdev->binding->set_guest_notifiers) {
+ error_report("binding does not support guest notifiers");
+ return -ENOSYS;
+ }
+
+ ret = ioctl(s->dev.control, VHOST_SCSI_GET_ABI_VERSION, &abi_version);
+ if (ret < 0) {
+ return -errno;
+ }
+ if (abi_version > VHOST_SCSI_ABI_VERSION) {
+ error_report("vhost-scsi: The running tcm_vhost kernel abi_version:"
+ " %d is greater than vhost_scsi userspace supports: %d, please"
+ " upgrade your version of QEMU\n", abi_version,
+ VHOST_SCSI_ABI_VERSION);
+ return -ENOSYS;
+ }
+
+ ret = vhost_dev_enable_notifiers(&s->dev, vdev);
+ if (ret < 0) {
+ return ret;
+ }
+
+ s->dev.acked_features = vdev->guest_features;
+ ret = vhost_dev_start(&s->dev, vdev);
+ if (ret < 0) {
+ error_report("Error start vhost dev");
+ goto err_notifiers;
+ }
+
+ ret = vhost_scsi_set_endpoint(s);
+ if (ret < 0) {
+ error_report("Error set vhost-scsi endpoint");
+ goto err_vhost_stop;
+ }
+
+ ret = vdev->binding->set_guest_notifiers(vdev->binding_opaque, s->dev.nvqs, true);
+ if (ret < 0) {
+ error_report("Error binding guest notifier");
+ goto err_endpoint;
+ }
+
+ /* guest_notifier_mask/pending not used yet, so just unmask
+ * everything here. virtio-pci will do the right thing by
+ * enabling/disabling irqfd.
+ */
+ for (i = 0; i < s->dev.nvqs; i++) {
+ vhost_virtqueue_mask(&s->dev, vdev, i, false);
+ }
+
+ return ret;
+
+err_endpoint:
+ vhost_scsi_clear_endpoint(s);
+err_vhost_stop:
+ vhost_dev_stop(&s->dev, vdev);
+err_notifiers:
+ vhost_dev_disable_notifiers(&s->dev, vdev);
+ return ret;
+}
+
+static void vhost_scsi_stop(VHostSCSI *s)
+{
+ VirtIODevice *vdev = VIRTIO_DEVICE(s);
+ int ret = 0;
+
+ if (!vdev->binding->set_guest_notifiers) {
+ ret = vdev->binding->set_guest_notifiers(vdev->binding_opaque,
+ s->dev.nvqs, false);
+ if (ret < 0) {
+ error_report("vhost guest notifier cleanup failed: %d\n", ret);
+ }
+ }
+ assert(ret >= 0);
+
+ vhost_scsi_clear_endpoint(s);
+ vhost_dev_stop(&s->dev, vdev);
+ vhost_dev_disable_notifiers(&s->dev, vdev);
+}
+
+static uint32_t vhost_scsi_get_features(VirtIODevice *vdev,
+ uint32_t features)
+{
+ VHostSCSI *s = VHOST_SCSI(vdev);
+
+ /* Clear features not supported by host kernel. */
+ if (!(s->dev.features & (1 << VIRTIO_F_NOTIFY_ON_EMPTY))) {
+ features &= ~(1 << VIRTIO_F_NOTIFY_ON_EMPTY);
+ }
+ if (!(s->dev.features & (1 << VIRTIO_RING_F_INDIRECT_DESC))) {
+ features &= ~(1 << VIRTIO_RING_F_INDIRECT_DESC);
+ }
+ if (!(s->dev.features & (1 << VIRTIO_RING_F_EVENT_IDX))) {
+ features &= ~(1 << VIRTIO_RING_F_EVENT_IDX);
+ }
+ if (!(s->dev.features & (1 << VIRTIO_SCSI_F_HOTPLUG))) {
+ features &= ~(1 << VIRTIO_SCSI_F_HOTPLUG);
+ }
+
+ return features;
+}
+
+static void vhost_scsi_set_config(VirtIODevice *vdev,
+ const uint8_t *config)
+{
+ VirtIOSCSIConfig *scsiconf = (VirtIOSCSIConfig *)config;
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+
+ if ((uint32_t) ldl_raw(&scsiconf->sense_size) != vs->sense_size ||
+ (uint32_t) ldl_raw(&scsiconf->cdb_size) != vs->cdb_size) {
+ error_report("vhost-scsi does not support changing the sense data and CDB sizes");
+ exit(1);
+ }
+}
+
+static void vhost_scsi_set_status(VirtIODevice *vdev, uint8_t val)
+{
+ VHostSCSI *s = (VHostSCSI *)vdev;
+ bool start = (val & VIRTIO_CONFIG_S_DRIVER_OK);
+
+ if (s->dev.started == start) {
+ return;
+ }
+
+ if (start) {
+ int ret;
+
+ ret = vhost_scsi_start(s);
+ if (ret < 0) {
+ error_report("virtio-scsi: unable to start vhost: %s\n",
+ strerror(-ret));
+
+ /* There is no userspace virtio-scsi fallback so exit */
+ exit(1);
+ }
+ } else {
+ vhost_scsi_stop(s);
+ }
+}
+
+static int vhost_scsi_init(VirtIODevice *vdev)
+{
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+ VHostSCSI *s = VHOST_SCSI(vdev);
+ int vhostfd = -1;
+ int ret;
+
+ if (!vs->conf.wwpn) {
+ error_report("vhost-scsi: missing wwpn\n");
+ return -EINVAL;
+ }
+
+ if (vs->conf.vhostfd) {
+ vhostfd = monitor_handle_fd_param(cur_mon, vs->conf.vhostfd);
+ if (vhostfd == -1) {
+ error_report("vhost-scsi: unable to parse vhostfd\n");
+ return -EINVAL;
+ }
+ }
+
+ ret = virtio_scsi_common_init(vs);
+ if (ret < 0) {
+ return ret;
+ }
+
+ vdev->get_features = vhost_scsi_get_features;
+ vdev->set_config = vhost_scsi_set_config;
+ vdev->set_status = vhost_scsi_set_status;
+
+ s->dev.nvqs = VHOST_SCSI_VQ_NUM_FIXED + vs->conf.num_queues;
+ s->dev.vqs = g_new(struct vhost_virtqueue, s->dev.nvqs);
+ s->dev.vq_index = 0;
+
+ ret = vhost_dev_init(&s->dev, vhostfd, "/dev/vhost-scsi", true);
+ if (ret < 0) {
+ error_report("vhost-scsi: vhost initialization failed: %s\n",
+ strerror(-ret));
+ return ret;
+ }
+ s->dev.backend_features = 0;
+
+ error_setg(&s->migration_blocker,
+ "vhost-scsi does not support migration");
+ migrate_add_blocker(s->migration_blocker);
+
+ return 0;
+}
+
+static int vhost_scsi_exit(DeviceState *qdev)
+{
+ VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
+ VHostSCSI *s = VHOST_SCSI(qdev);
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(qdev);
+
+ migrate_del_blocker(s->migration_blocker);
+ error_free(s->migration_blocker);
+
+ /* This will stop vhost backend. */
+ vhost_scsi_set_status(vdev, 0);
+
+ g_free(s->dev.vqs);
+ return virtio_scsi_common_exit(vs);
+}
+
+static Property vhost_scsi_properties[] = {
+ DEFINE_VHOST_SCSI_PROPERTIES(VHostSCSI, parent_obj.conf),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
+static void vhost_scsi_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ VirtioDeviceClass *vdc = VIRTIO_DEVICE_CLASS(klass);
+ dc->exit = vhost_scsi_exit;
+ dc->props = vhost_scsi_properties;
+ vdc->init = vhost_scsi_init;
+ vdc->get_features = vhost_scsi_get_features;
+ vdc->set_config = vhost_scsi_set_config;
+ vdc->set_status = vhost_scsi_set_status;
+}
+
+static const TypeInfo vhost_scsi_info = {
+ .name = TYPE_VHOST_SCSI,
+ .parent = TYPE_VIRTIO_SCSI_COMMON,
+ .instance_size = sizeof(VHostSCSI),
+ .class_init = vhost_scsi_class_init,
+};
+
+static void virtio_register_types(void)
+{
+ type_register_static(&vhost_scsi_info);
+}
+
+type_init(virtio_register_types)
diff --git a/include/hw/virtio/vhost-scsi.h b/include/hw/virtio/vhost-scsi.h
new file mode 100644
index 0000000..85cc031
--- /dev/null
+++ b/include/hw/virtio/vhost-scsi.h
@@ -0,0 +1,73 @@
+/*
+ * vhost_scsi host device
+ *
+ * Copyright IBM, Corp. 2011
+ *
+ * Authors:
+ * Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#ifndef VHOST_SCSI_H
+#define VHOST_SCSI_H
+
+#include "qemu-common.h"
+#include "hw/qdev.h"
+#include "hw/virtio/virtio-scsi.h"
+#include "hw/virtio/vhost.h"
+
+/*
+ * Used by QEMU userspace to ensure a consistent vhost-scsi ABI.
+ *
+ * ABI Rev 0: July 2012 version starting point for v3.6-rc merge candidate +
+ * RFC-v2 vhost-scsi userspace. Add GET_ABI_VERSION ioctl usage
+ * ABI Rev 1: January 2013. Ignore vhost_tpgt filed in struct vhost_scsi_target.
+ * All the targets under vhost_wwpn can be seen and used by guest.
+ */
+
+#define VHOST_SCSI_ABI_VERSION 1
+
+/* TODO #include <linux/vhost.h> properly */
+/* For VHOST_SCSI_SET_ENDPOINT/VHOST_SCSI_CLEAR_ENDPOINT ioctl */
+struct vhost_scsi_target {
+ int abi_version;
+ char vhost_wwpn[224];
+ unsigned short vhost_tpgt;
+ unsigned short reserved;
+};
+
+enum vhost_scsi_vq_list {
+ VHOST_SCSI_VQ_CONTROL = 0,
+ VHOST_SCSI_VQ_EVENT = 1,
+ VHOST_SCSI_VQ_NUM_FIXED = 2,
+};
+
+#define VHOST_VIRTIO 0xAF
+#define VHOST_SCSI_SET_ENDPOINT _IOW(VHOST_VIRTIO, 0x40, struct vhost_scsi_target)
+#define VHOST_SCSI_CLEAR_ENDPOINT _IOW(VHOST_VIRTIO, 0x41, struct vhost_scsi_target)
+#define VHOST_SCSI_GET_ABI_VERSION _IOW(VHOST_VIRTIO, 0x42, int)
+
+#define TYPE_VHOST_SCSI "vhost-scsi"
+#define VHOST_SCSI(obj) \
+ OBJECT_CHECK(VHostSCSI, (obj), TYPE_VHOST_SCSI)
+
+typedef struct VHostSCSI {
+ VirtIOSCSICommon parent_obj;
+
+ Error *migration_blocker;
+
+ struct vhost_dev dev;
+} VHostSCSI;
+
+#define DEFINE_VHOST_SCSI_PROPERTIES(_state, _conf_field) \
+ DEFINE_PROP_STRING("vhostfd", _state, _conf_field.vhostfd), \
+ DEFINE_PROP_STRING("wwpn", _state, _conf_field.wwpn), \
+ DEFINE_PROP_UINT32("num_queues", _state, _conf_field.num_queues, 1), \
+ DEFINE_PROP_UINT32("max_sectors", _state, _conf_field.max_sectors, 0xFFFF), \
+ DEFINE_PROP_UINT32("cmd_per_lun", _state, _conf_field.cmd_per_lun, 128)
+
+
+#endif
diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h
index 4a961b9..4db346b 100644
--- a/include/hw/virtio/virtio-scsi.h
+++ b/include/hw/virtio/virtio-scsi.h
@@ -151,6 +151,8 @@ struct VirtIOSCSIConf {
uint32_t num_queues;
uint32_t max_sectors;
uint32_t cmd_per_lun;
+ char *vhostfd;
+ char *wwpn;
};
typedef struct VirtIOSCSICommon {
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-04-19 14:24 ` [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module Paolo Bonzini
@ 2013-05-28 7:13 ` Wenchao Xia
2013-05-28 8:01 ` Paolo Bonzini
0 siblings, 1 reply; 56+ messages in thread
From: Wenchao Xia @ 2013-05-28 7:13 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: asias, qemu-devel, nab, Michael S. Tsirkin
于 2013-4-19 22:24, Paolo Bonzini 写道:
> From: Nicholas Bellinger <nab@linux-iscsi.org>
>
> The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
> The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
> available from the QEMU command-line. Instead, I hardcode it to zero.
>
Hi, Paolo
Any document about how to config it correctly in configfs, before
invoking qemu with the WWPN number?
> Changes in Patch-v2:
> - Add vhost_scsi_get_features() in order to determine feature bits
> supports by host kernel (mst + nab)
> - Re-enable usage of DEFINE_VIRTIO_COMMON_FEATURES, and allow
> EVENT_IDX to be disabled by host in vhost_scsi_get_features()
> - Drop unused hotplug bit in DEFINE_VHOST_SCSI_PROPERTIES
>
> Changes in Patch-v1:
> - Set event_idx=off by default (nab, thanks asias)
> - Disable hotplug feature bit for v3.9 tcm_vhost kernel code, need to
> re-enable in v3.10 (nab)
> - Update to latest qemu.git/master HEAD
>
> Changes in WIP-V3:
> - Drop ioeventfd vhost_scsi_properties (asias, thanks stefanha)
> - Add CONFIG_VHOST_SCSI (asias, thanks stefanha)
> - Add hotplug feature bit
>
> Changes in WIP-V2:
> - Add backend guest masking support (nab)
> - Bump ABI_VERSION to 1 (nab)
> - Set up set_guest_notifiers (asias)
> - Set up vs->dev.vq_index (asias)
> - Drop vs->vs.vdev.{set,clear}_vhost_endpoint (asias)
> - Drop VIRTIO_CONFIG_S_DRIVER check in vhost_scsi_set_status (asias)
>
> Howto:
> Use the latest seabios, at least commit b44a7be17b
> git clone git://git.seabios.org/seabios.git
> make
> cp out/bios.bin /usr/share/qemu/bios.bin
> qemu -device vhost-scsi-pci,wwpn=naa.6001405bd4e8476d
> ...
>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
> Signed-off-by: Asias He <asias@redhat.com>
> [ Rebase on top of VirtIOSCSICommon patch, fix bugs in feature
> negotiation and irqfd masking - Paolo ]
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> configure | 10 ++
> hw/scsi/Makefile.objs | 6 +-
> hw/scsi/vhost-scsi.c | 288 ++++++++++++++++++++++++++++++++++++++++
> include/hw/virtio/vhost-scsi.h | 73 ++++++++++
> include/hw/virtio/virtio-scsi.h | 2 +
> 5 files changed, 378 insertions(+), 1 deletion(-)
> create mode 100644 hw/scsi/vhost-scsi.c
> create mode 100644 include/hw/virtio/vhost-scsi.h
>
> diff --git a/configure b/configure
> index ed49f91..51a6c56 100755
> --- a/configure
> +++ b/configure
> @@ -179,6 +179,7 @@ libattr=""
> xfs=""
>
> vhost_net="no"
> +vhost_scsi="no"
> kvm="no"
> gprof="no"
> debug_tcg="no"
> @@ -543,6 +544,7 @@ Haiku)
> usb="linux"
> kvm="yes"
> vhost_net="yes"
> + vhost_scsi="yes"
> if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
> audio_possible_drivers="$audio_possible_drivers fmod"
> fi
> @@ -870,6 +872,10 @@ for opt do
> ;;
> --enable-vhost-net) vhost_net="yes"
> ;;
> + --disable-vhost-scsi) vhost_scsi="no"
> + ;;
> + --enable-vhost-scsi) vhost_scsi="yes"
> + ;;
> --disable-glx) glx="no"
> ;;
> --enable-glx) glx="yes"
> @@ -3553,6 +3559,7 @@ echo "sigev_thread_id $sigev_thread_id"
> echo "uuid support $uuid"
> echo "libcap-ng support $cap_ng"
> echo "vhost-net support $vhost_net"
> +echo "vhost-scsi support $vhost_scsi"
> echo "Trace backend $trace_backend"
> echo "Trace output file $trace_file-<pid>"
> echo "spice support $spice ($spice_protocol_version/$spice_server_version)"
> @@ -3836,6 +3843,9 @@ fi
> if test "$virtfs" = "yes" ; then
> echo "CONFIG_VIRTFS=y" >> $config_host_mak
> fi
> +if test "$vhost_scsi" = "yes" ; then
> + echo "CONFIG_VHOST_SCSI=y" >> $config_host_mak
> +fi
> if test "$blobs" = "yes" ; then
> echo "INSTALL_BLOBS=yes" >> $config_host_mak
> fi
> diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
> index eaec6c8..121ddc5 100644
> --- a/hw/scsi/Makefile.objs
> +++ b/hw/scsi/Makefile.objs
> @@ -6,4 +6,8 @@ common-obj-$(CONFIG_VMW_PVSCSI_SCSI_PCI) += vmw_pvscsi.o
> common-obj-$(CONFIG_ESP) += esp.o
> common-obj-$(CONFIG_ESP_PCI) += esp-pci.o
> obj-$(CONFIG_PSERIES) += spapr_vscsi.o
> -obj-$(CONFIG_VIRTIO) += virtio-scsi.o
> +
> +ifeq ($(CONFIG_VIRTIO),y)
> +obj-y += virtio-scsi.o
> +obj-$(CONFIG_VHOST_SCSI) += vhost-scsi.o
> +endif
> diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
> new file mode 100644
> index 0000000..3dd1a0f
> --- /dev/null
> +++ b/hw/scsi/vhost-scsi.c
> @@ -0,0 +1,288 @@
> +/*
> + * vhost_scsi host device
> + *
> + * Copyright IBM, Corp. 2011
> + *
> + * Authors:
> + * Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
> + *
> + * Changes for QEMU mainline + tcm_vhost kernel upstream:
> + * Nicholas Bellinger <nab@risingtidesystems.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2 or later.
> + * See the COPYING.LIB file in the top-level directory.
> + *
> + */
> +
> +#include <sys/ioctl.h>
> +#include "config.h"
> +#include "qemu/queue.h"
> +#include "monitor/monitor.h"
> +#include "migration/migration.h"
> +#include "hw/virtio/vhost-scsi.h"
> +#include "hw/virtio/vhost.h"
> +#include "hw/virtio/virtio-scsi.h"
> +
> +static int vhost_scsi_set_endpoint(VHostSCSI *s)
> +{
> + VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
> + struct vhost_scsi_target backend;
> + int ret;
> +
> + memset(&backend, 0, sizeof(backend));
> + pstrcpy(backend.vhost_wwpn, sizeof(backend.vhost_wwpn), vs->conf.wwpn);
> + ret = ioctl(s->dev.control, VHOST_SCSI_SET_ENDPOINT, &backend);
> + if (ret < 0) {
> + return -errno;
> + }
> + return 0;
> +}
> +
> +static void vhost_scsi_clear_endpoint(VHostSCSI *s)
> +{
> + VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
> + struct vhost_scsi_target backend;
> +
> + memset(&backend, 0, sizeof(backend));
> + pstrcpy(backend.vhost_wwpn, sizeof(backend.vhost_wwpn), vs->conf.wwpn);
> + ioctl(s->dev.control, VHOST_SCSI_CLEAR_ENDPOINT, &backend);
> +}
> +
> +static int vhost_scsi_start(VHostSCSI *s)
> +{
> + int ret, abi_version, i;
> + VirtIODevice *vdev = VIRTIO_DEVICE(s);
> +
> + if (!vdev->binding->set_guest_notifiers) {
> + error_report("binding does not support guest notifiers");
> + return -ENOSYS;
> + }
> +
> + ret = ioctl(s->dev.control, VHOST_SCSI_GET_ABI_VERSION, &abi_version);
> + if (ret < 0) {
> + return -errno;
> + }
> + if (abi_version > VHOST_SCSI_ABI_VERSION) {
> + error_report("vhost-scsi: The running tcm_vhost kernel abi_version:"
> + " %d is greater than vhost_scsi userspace supports: %d, please"
> + " upgrade your version of QEMU\n", abi_version,
> + VHOST_SCSI_ABI_VERSION);
> + return -ENOSYS;
> + }
> +
> + ret = vhost_dev_enable_notifiers(&s->dev, vdev);
> + if (ret < 0) {
> + return ret;
> + }
> +
> + s->dev.acked_features = vdev->guest_features;
> + ret = vhost_dev_start(&s->dev, vdev);
> + if (ret < 0) {
> + error_report("Error start vhost dev");
> + goto err_notifiers;
> + }
> +
> + ret = vhost_scsi_set_endpoint(s);
> + if (ret < 0) {
> + error_report("Error set vhost-scsi endpoint");
> + goto err_vhost_stop;
> + }
> +
> + ret = vdev->binding->set_guest_notifiers(vdev->binding_opaque, s->dev.nvqs, true);
> + if (ret < 0) {
> + error_report("Error binding guest notifier");
> + goto err_endpoint;
> + }
> +
> + /* guest_notifier_mask/pending not used yet, so just unmask
> + * everything here. virtio-pci will do the right thing by
> + * enabling/disabling irqfd.
> + */
> + for (i = 0; i < s->dev.nvqs; i++) {
> + vhost_virtqueue_mask(&s->dev, vdev, i, false);
> + }
> +
> + return ret;
> +
> +err_endpoint:
> + vhost_scsi_clear_endpoint(s);
> +err_vhost_stop:
> + vhost_dev_stop(&s->dev, vdev);
> +err_notifiers:
> + vhost_dev_disable_notifiers(&s->dev, vdev);
> + return ret;
> +}
> +
> +static void vhost_scsi_stop(VHostSCSI *s)
> +{
> + VirtIODevice *vdev = VIRTIO_DEVICE(s);
> + int ret = 0;
> +
> + if (!vdev->binding->set_guest_notifiers) {
> + ret = vdev->binding->set_guest_notifiers(vdev->binding_opaque,
> + s->dev.nvqs, false);
> + if (ret < 0) {
> + error_report("vhost guest notifier cleanup failed: %d\n", ret);
> + }
> + }
> + assert(ret >= 0);
> +
> + vhost_scsi_clear_endpoint(s);
> + vhost_dev_stop(&s->dev, vdev);
> + vhost_dev_disable_notifiers(&s->dev, vdev);
> +}
> +
> +static uint32_t vhost_scsi_get_features(VirtIODevice *vdev,
> + uint32_t features)
> +{
> + VHostSCSI *s = VHOST_SCSI(vdev);
> +
> + /* Clear features not supported by host kernel. */
> + if (!(s->dev.features & (1 << VIRTIO_F_NOTIFY_ON_EMPTY))) {
> + features &= ~(1 << VIRTIO_F_NOTIFY_ON_EMPTY);
> + }
> + if (!(s->dev.features & (1 << VIRTIO_RING_F_INDIRECT_DESC))) {
> + features &= ~(1 << VIRTIO_RING_F_INDIRECT_DESC);
> + }
> + if (!(s->dev.features & (1 << VIRTIO_RING_F_EVENT_IDX))) {
> + features &= ~(1 << VIRTIO_RING_F_EVENT_IDX);
> + }
> + if (!(s->dev.features & (1 << VIRTIO_SCSI_F_HOTPLUG))) {
> + features &= ~(1 << VIRTIO_SCSI_F_HOTPLUG);
> + }
> +
> + return features;
> +}
> +
> +static void vhost_scsi_set_config(VirtIODevice *vdev,
> + const uint8_t *config)
> +{
> + VirtIOSCSIConfig *scsiconf = (VirtIOSCSIConfig *)config;
> + VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
> +
> + if ((uint32_t) ldl_raw(&scsiconf->sense_size) != vs->sense_size ||
> + (uint32_t) ldl_raw(&scsiconf->cdb_size) != vs->cdb_size) {
> + error_report("vhost-scsi does not support changing the sense data and CDB sizes");
> + exit(1);
> + }
> +}
> +
> +static void vhost_scsi_set_status(VirtIODevice *vdev, uint8_t val)
> +{
> + VHostSCSI *s = (VHostSCSI *)vdev;
> + bool start = (val & VIRTIO_CONFIG_S_DRIVER_OK);
> +
> + if (s->dev.started == start) {
> + return;
> + }
> +
> + if (start) {
> + int ret;
> +
> + ret = vhost_scsi_start(s);
> + if (ret < 0) {
> + error_report("virtio-scsi: unable to start vhost: %s\n",
> + strerror(-ret));
> +
> + /* There is no userspace virtio-scsi fallback so exit */
> + exit(1);
> + }
> + } else {
> + vhost_scsi_stop(s);
> + }
> +}
> +
> +static int vhost_scsi_init(VirtIODevice *vdev)
> +{
> + VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
> + VHostSCSI *s = VHOST_SCSI(vdev);
> + int vhostfd = -1;
> + int ret;
> +
> + if (!vs->conf.wwpn) {
> + error_report("vhost-scsi: missing wwpn\n");
> + return -EINVAL;
> + }
> +
> + if (vs->conf.vhostfd) {
> + vhostfd = monitor_handle_fd_param(cur_mon, vs->conf.vhostfd);
> + if (vhostfd == -1) {
> + error_report("vhost-scsi: unable to parse vhostfd\n");
> + return -EINVAL;
> + }
> + }
> +
> + ret = virtio_scsi_common_init(vs);
> + if (ret < 0) {
> + return ret;
> + }
> +
> + vdev->get_features = vhost_scsi_get_features;
> + vdev->set_config = vhost_scsi_set_config;
> + vdev->set_status = vhost_scsi_set_status;
> +
> + s->dev.nvqs = VHOST_SCSI_VQ_NUM_FIXED + vs->conf.num_queues;
> + s->dev.vqs = g_new(struct vhost_virtqueue, s->dev.nvqs);
> + s->dev.vq_index = 0;
> +
> + ret = vhost_dev_init(&s->dev, vhostfd, "/dev/vhost-scsi", true);
> + if (ret < 0) {
> + error_report("vhost-scsi: vhost initialization failed: %s\n",
> + strerror(-ret));
> + return ret;
> + }
> + s->dev.backend_features = 0;
> +
> + error_setg(&s->migration_blocker,
> + "vhost-scsi does not support migration");
> + migrate_add_blocker(s->migration_blocker);
> +
> + return 0;
> +}
> +
> +static int vhost_scsi_exit(DeviceState *qdev)
> +{
> + VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
> + VHostSCSI *s = VHOST_SCSI(qdev);
> + VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(qdev);
> +
> + migrate_del_blocker(s->migration_blocker);
> + error_free(s->migration_blocker);
> +
> + /* This will stop vhost backend. */
> + vhost_scsi_set_status(vdev, 0);
> +
> + g_free(s->dev.vqs);
> + return virtio_scsi_common_exit(vs);
> +}
> +
> +static Property vhost_scsi_properties[] = {
> + DEFINE_VHOST_SCSI_PROPERTIES(VHostSCSI, parent_obj.conf),
> + DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void vhost_scsi_class_init(ObjectClass *klass, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + VirtioDeviceClass *vdc = VIRTIO_DEVICE_CLASS(klass);
> + dc->exit = vhost_scsi_exit;
> + dc->props = vhost_scsi_properties;
> + vdc->init = vhost_scsi_init;
> + vdc->get_features = vhost_scsi_get_features;
> + vdc->set_config = vhost_scsi_set_config;
> + vdc->set_status = vhost_scsi_set_status;
> +}
> +
> +static const TypeInfo vhost_scsi_info = {
> + .name = TYPE_VHOST_SCSI,
> + .parent = TYPE_VIRTIO_SCSI_COMMON,
> + .instance_size = sizeof(VHostSCSI),
> + .class_init = vhost_scsi_class_init,
> +};
> +
> +static void virtio_register_types(void)
> +{
> + type_register_static(&vhost_scsi_info);
> +}
> +
> +type_init(virtio_register_types)
> diff --git a/include/hw/virtio/vhost-scsi.h b/include/hw/virtio/vhost-scsi.h
> new file mode 100644
> index 0000000..85cc031
> --- /dev/null
> +++ b/include/hw/virtio/vhost-scsi.h
> @@ -0,0 +1,73 @@
> +/*
> + * vhost_scsi host device
> + *
> + * Copyright IBM, Corp. 2011
> + *
> + * Authors:
> + * Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2 or later.
> + * See the COPYING.LIB file in the top-level directory.
> + *
> + */
> +
> +#ifndef VHOST_SCSI_H
> +#define VHOST_SCSI_H
> +
> +#include "qemu-common.h"
> +#include "hw/qdev.h"
> +#include "hw/virtio/virtio-scsi.h"
> +#include "hw/virtio/vhost.h"
> +
> +/*
> + * Used by QEMU userspace to ensure a consistent vhost-scsi ABI.
> + *
> + * ABI Rev 0: July 2012 version starting point for v3.6-rc merge candidate +
> + * RFC-v2 vhost-scsi userspace. Add GET_ABI_VERSION ioctl usage
> + * ABI Rev 1: January 2013. Ignore vhost_tpgt filed in struct vhost_scsi_target.
> + * All the targets under vhost_wwpn can be seen and used by guest.
> + */
> +
> +#define VHOST_SCSI_ABI_VERSION 1
> +
> +/* TODO #include <linux/vhost.h> properly */
> +/* For VHOST_SCSI_SET_ENDPOINT/VHOST_SCSI_CLEAR_ENDPOINT ioctl */
> +struct vhost_scsi_target {
> + int abi_version;
> + char vhost_wwpn[224];
> + unsigned short vhost_tpgt;
> + unsigned short reserved;
> +};
> +
> +enum vhost_scsi_vq_list {
> + VHOST_SCSI_VQ_CONTROL = 0,
> + VHOST_SCSI_VQ_EVENT = 1,
> + VHOST_SCSI_VQ_NUM_FIXED = 2,
> +};
> +
> +#define VHOST_VIRTIO 0xAF
> +#define VHOST_SCSI_SET_ENDPOINT _IOW(VHOST_VIRTIO, 0x40, struct vhost_scsi_target)
> +#define VHOST_SCSI_CLEAR_ENDPOINT _IOW(VHOST_VIRTIO, 0x41, struct vhost_scsi_target)
> +#define VHOST_SCSI_GET_ABI_VERSION _IOW(VHOST_VIRTIO, 0x42, int)
> +
> +#define TYPE_VHOST_SCSI "vhost-scsi"
> +#define VHOST_SCSI(obj) \
> + OBJECT_CHECK(VHostSCSI, (obj), TYPE_VHOST_SCSI)
> +
> +typedef struct VHostSCSI {
> + VirtIOSCSICommon parent_obj;
> +
> + Error *migration_blocker;
> +
> + struct vhost_dev dev;
> +} VHostSCSI;
> +
> +#define DEFINE_VHOST_SCSI_PROPERTIES(_state, _conf_field) \
> + DEFINE_PROP_STRING("vhostfd", _state, _conf_field.vhostfd), \
> + DEFINE_PROP_STRING("wwpn", _state, _conf_field.wwpn), \
> + DEFINE_PROP_UINT32("num_queues", _state, _conf_field.num_queues, 1), \
> + DEFINE_PROP_UINT32("max_sectors", _state, _conf_field.max_sectors, 0xFFFF), \
> + DEFINE_PROP_UINT32("cmd_per_lun", _state, _conf_field.cmd_per_lun, 128)
> +
> +
> +#endif
> diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h
> index 4a961b9..4db346b 100644
> --- a/include/hw/virtio/virtio-scsi.h
> +++ b/include/hw/virtio/virtio-scsi.h
> @@ -151,6 +151,8 @@ struct VirtIOSCSIConf {
> uint32_t num_queues;
> uint32_t max_sectors;
> uint32_t cmd_per_lun;
> + char *vhostfd;
> + char *wwpn;
> };
>
> typedef struct VirtIOSCSICommon {
>
--
Best Regards
Wenchao Xia
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-28 7:13 ` Wenchao Xia
@ 2013-05-28 8:01 ` Paolo Bonzini
2013-05-28 8:33 ` Asias He
2013-06-19 12:55 ` Libaiqing
0 siblings, 2 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-05-28 8:01 UTC (permalink / raw)
To: Wenchao Xia; +Cc: asias, qemu-devel, nab, Michael S. Tsirkin
Il 28/05/2013 09:13, Wenchao Xia ha scritto:
>> > From: Nicholas Bellinger <nab@linux-iscsi.org>
>> >
>> > The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
>> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
>> > available from the QEMU command-line. Instead, I hardcode it to zero.
>> >
> Hi, Paolo
> Any document about how to config it correctly in configfs, before
> invoking qemu with the WWPN number?
Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
iSCSI for example) so it's quite simple. Here is an example:
cd /sys/kernel/config/target
mkdir -p core/fileio_0/fileio
echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' > core/fileio_0/fileio/control
echo 1 > core/fileio_0/fileio/enable
mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
cd vhost/naa.600140554cf3a18e/tpgt_0
ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
echo naa.60014053226f0388 > nexus
The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
target WWN that you have to pass to "-device vhost-scsi-pci".
Paolo
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-28 8:01 ` Paolo Bonzini
@ 2013-05-28 8:33 ` Asias He
2013-05-28 9:00 ` Wenchao Xia
2013-06-19 12:55 ` Libaiqing
1 sibling, 1 reply; 56+ messages in thread
From: Asias He @ 2013-05-28 8:33 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Michael S. Tsirkin, Wenchao Xia, nab, qemu-devel
On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> >> >
> >> > The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
> >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
> >> > available from the QEMU command-line. Instead, I hardcode it to zero.
> >> >
> > Hi, Paolo
> > Any document about how to config it correctly in configfs, before
> > invoking qemu with the WWPN number?
>
> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> iSCSI for example) so it's quite simple. Here is an example:
>
> cd /sys/kernel/config/target
> mkdir -p core/fileio_0/fileio
> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' > core/fileio_0/fileio/control
> echo 1 > core/fileio_0/fileio/enable
> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> cd vhost/naa.600140554cf3a18e/tpgt_0
> ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> echo naa.60014053226f0388 > nexus
>
> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> target WWN that you have to pass to "-device vhost-scsi-pci".
>
> Paolo
For me, I always use targetcli utils instead of the sysfs interface.
targetcli in F18 has vhost support now.
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-28 8:33 ` Asias He
@ 2013-05-28 9:00 ` Wenchao Xia
2013-05-29 9:05 ` Wenchao Xia
0 siblings, 1 reply; 56+ messages in thread
From: Wenchao Xia @ 2013-05-28 9:00 UTC (permalink / raw)
To: Asias He; +Cc: Paolo Bonzini, qemu-devel, nab, Michael S. Tsirkin
于 2013-5-28 16:33, Asias He 写道:
> On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
>> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
>>>>> From: Nicholas Bellinger <nab@linux-iscsi.org>
>>>>>
>>>>> The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
>>>>> The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
>>>>> available from the QEMU command-line. Instead, I hardcode it to zero.
>>>>>
>>> Hi, Paolo
>>> Any document about how to config it correctly in configfs, before
>>> invoking qemu with the WWPN number?
>>
>> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
>> iSCSI for example) so it's quite simple. Here is an example:
>>
>> cd /sys/kernel/config/target
>> mkdir -p core/fileio_0/fileio
>> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' > core/fileio_0/fileio/control
>> echo 1 > core/fileio_0/fileio/enable
>> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
>> cd vhost/naa.600140554cf3a18e/tpgt_0
>> ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
>> echo naa.60014053226f0388 > nexus
>>
>> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
>> target WWN that you have to pass to "-device vhost-scsi-pci".
>>
>> Paolo
>
> For me, I always use targetcli utils instead of the sysfs interface.
> targetcli in F18 has vhost support now.
>
Thanks very much for above information, I'll try it for test.
--
Best Regards
Wenchao Xia
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-28 9:00 ` Wenchao Xia
@ 2013-05-29 9:05 ` Wenchao Xia
2013-05-29 9:27 ` Asias He
2013-05-29 15:10 ` Badari Pulavarty
0 siblings, 2 replies; 56+ messages in thread
From: Wenchao Xia @ 2013-05-29 9:05 UTC (permalink / raw)
To: Asias He
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, nab, Badari,
Paolo Bonzini
于 2013-5-28 17:00, Wenchao Xia 写道:
> 于 2013-5-28 16:33, Asias He 写道:
>> On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
>>> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
>>>>>> From: Nicholas Bellinger <nab@linux-iscsi.org>
>>>>>>
>>>>>> The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
>>>>>> The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
>>>>>> not
>>>>>> available from the QEMU command-line. Instead, I hardcode it to
>>>>>> zero.
>>>>>>
>>>> Hi, Paolo
>>>> Any document about how to config it correctly in configfs, before
>>>> invoking qemu with the WWPN number?
>>>
>>> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
>>> iSCSI for example) so it's quite simple. Here is an example:
>>>
>>> cd /sys/kernel/config/target
>>> mkdir -p core/fileio_0/fileio
>>> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
>>> core/fileio_0/fileio/control
>>> echo 1 > core/fileio_0/fileio/enable
>>> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
>>> cd vhost/naa.600140554cf3a18e/tpgt_0
>>> ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
>>> echo naa.60014053226f0388 > nexus
>>>
>>> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
>>> target WWN that you have to pass to "-device vhost-scsi-pci".
>>>
>>> Paolo
>>
>> For me, I always use targetcli utils instead of the sysfs interface.
>> targetcli in F18 has vhost support now.
>>
> Thanks very much for above information, I'll try it for test.
>
I have done a basic test of vhost-scsi, following is the result I'd
like to post, generally it seems fine:
Result:
fdisk/mkfs: fdisk can find it, mke2fs works fine.
mount: can mount it.
file I/O: dd 90M zero to a file in that disk succeed.
Issues:
1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
dev fd0, sector 0", I guess it is caused by nested KVM that failed
to kick host kernel?
2) in fdisk -l, it shows 512 bytes larger than the parameter I
specified in fd_dev_size parameter in configfs on host.(shows
104858112 bytes, see the invocation script below)
ENV:
nested KVM:
RH6.4
(Qemu Virtual CPU 1.5.50, Linux 3.10.0.rc3)
| (100M vhost-scsi hooked with file backend)
RH6.4
(Common KVM processer, Linux 3.10.0.rc3,
qemu-system-x86_64 1.5.50+, 6a4e17711442849bf2cc731ccddef5a2a2d92d29,
seabios 1.7.2.2, e9725dd76d5d7212cb4a97fd18ff2599538955cf)
|
Fefora 18
(Intel Xeon X5650, Linux version 3.8.11-200.fc18.x86_64,
QEMU emulator version 1.2.2)
Invocation details:
On RH6.4 host:
1 with root, execute following script to prepare configfs system:
FILEIO=fileio_1
IMAGE=/home/xiawenc/Work/qemu/test/test1.raw
SIZE=104857600
QEMU_WWPN=naa.600140554cf3a1fe
NEXUS=naa.60014053226f03f8
mkdir -p /sys/kernel/config/target/core/$FILEIO/fileio
echo "fd_dev_name=$IMAGE,fd_dev_size=$SIZE" >
/sys/kernel/config/target/core/$FILEIO/fileio/control
echo 1 > /sys/kernel/config/target/core/$FILEIO/fileio/enable
mkdir -p /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/lun/lun_0
ln -sf /sys/kernel/config/target/core/$FILEIO/fileio/
/sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/lun/lun_0/virtual_scsi_port
echo $NEXUS > /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/nexus
2 invoke qemu, test_guest_RH64.qcow2 is a pre-made disk containing
RH6.4 system:
x86_64-softmmu/qemu-system-x86_64 --enablem 1024 -drive
file=/mnt/nfs/test_guest_RH64.qcow2,if=ide,cache=writethrough -vnc
0.0.0.0:10 -L mybios/ -device
vhost-scsi-pci,wwpn=naa.600140554cf3a1fe,event_idx=off
--
Best Regards
Wenchao Xia
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-29 9:05 ` Wenchao Xia
@ 2013-05-29 9:27 ` Asias He
2013-05-29 15:10 ` Badari Pulavarty
1 sibling, 0 replies; 56+ messages in thread
From: Asias He @ 2013-05-29 9:27 UTC (permalink / raw)
To: Wenchao Xia
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, nab, Badari,
Paolo Bonzini
On Wed, May 29, 2013 at 05:05:31PM +0800, Wenchao Xia wrote:
> 于 2013-5-28 17:00, Wenchao Xia 写道:
> >于 2013-5-28 16:33, Asias He 写道:
> >>On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
> >>>Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> >>>>>>From: Nicholas Bellinger <nab@linux-iscsi.org>
> >>>>>>
> >>>>>>The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
> >>>>>>The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
> >>>>>>not
> >>>>>>available from the QEMU command-line. Instead, I hardcode it to
> >>>>>>zero.
> >>>>>>
> >>>>Hi, Paolo
> >>>> Any document about how to config it correctly in configfs, before
> >>>>invoking qemu with the WWPN number?
> >>>
> >>>Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> >>>iSCSI for example) so it's quite simple. Here is an example:
> >>>
> >>>cd /sys/kernel/config/target
> >>>mkdir -p core/fileio_0/fileio
> >>>echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> >>>core/fileio_0/fileio/control
> >>>echo 1 > core/fileio_0/fileio/enable
> >>>mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> >>>cd vhost/naa.600140554cf3a18e/tpgt_0
> >>>ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> >>>echo naa.60014053226f0388 > nexus
> >>>
> >>>The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> >>>target WWN that you have to pass to "-device vhost-scsi-pci".
> >>>
> >>>Paolo
> >>
> >>For me, I always use targetcli utils instead of the sysfs interface.
> >>targetcli in F18 has vhost support now.
> >>
> > Thanks very much for above information, I'll try it for test.
> >
> I have done a basic test of vhost-scsi, following is the result I'd
> like to post, generally it seems fine:
>
> Result:
> fdisk/mkfs: fdisk can find it, mke2fs works fine.
> mount: can mount it.
> file I/O: dd 90M zero to a file in that disk succeed.
>
> Issues:
> 1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
> dev fd0, sector 0", I guess it is caused by nested KVM that failed
> to kick host kernel?
Did you run without nested KVM?
> 2) in fdisk -l, it shows 512 bytes larger than the parameter I
> specified in fd_dev_size parameter in configfs on host.(shows
> 104858112 bytes, see the invocation script below)
Does targetcli give you the correct size? Also, to narrow the issue down,
you can try other backstores, e.g block or ramdisk.
> ENV:
> nested KVM:
>
> RH6.4
> (Qemu Virtual CPU 1.5.50, Linux 3.10.0.rc3)
> | (100M vhost-scsi hooked with file backend)
> RH6.4
> (Common KVM processer, Linux 3.10.0.rc3,
> qemu-system-x86_64 1.5.50+, 6a4e17711442849bf2cc731ccddef5a2a2d92d29,
> seabios 1.7.2.2, e9725dd76d5d7212cb4a97fd18ff2599538955cf)
> |
> Fefora 18
> (Intel Xeon X5650, Linux version 3.8.11-200.fc18.x86_64,
> QEMU emulator version 1.2.2)
>
> Invocation details:
> On RH6.4 host:
> 1 with root, execute following script to prepare configfs system:
>
> FILEIO=fileio_1
> IMAGE=/home/xiawenc/Work/qemu/test/test1.raw
> SIZE=104857600
> QEMU_WWPN=naa.600140554cf3a1fe
> NEXUS=naa.60014053226f03f8
>
> mkdir -p /sys/kernel/config/target/core/$FILEIO/fileio
> echo "fd_dev_name=$IMAGE,fd_dev_size=$SIZE" >
> /sys/kernel/config/target/core/$FILEIO/fileio/control
> echo 1 > /sys/kernel/config/target/core/$FILEIO/fileio/enable
>
> mkdir -p /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/lun/lun_0
> ln -sf /sys/kernel/config/target/core/$FILEIO/fileio/ /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/lun/lun_0/virtual_scsi_port
> echo $NEXUS > /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/nexus
>
> 2 invoke qemu, test_guest_RH64.qcow2 is a pre-made disk containing
> RH6.4 system:
>
> x86_64-softmmu/qemu-system-x86_64 --enablem 1024 -drive
> file=/mnt/nfs/test_guest_RH64.qcow2,if=ide,cache=writethrough -vnc
> 0.0.0.0:10 -L mybios/ -device
> vhost-scsi-pci,wwpn=naa.600140554cf3a1fe,event_idx=off
>
>
> --
> Best Regards
>
> Wenchao Xia
>
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-29 9:05 ` Wenchao Xia
2013-05-29 9:27 ` Asias He
@ 2013-05-29 15:10 ` Badari Pulavarty
2013-05-29 22:17 ` Asias He
2013-05-30 2:09 ` [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module Wenchao Xia
1 sibling, 2 replies; 56+ messages in thread
From: Badari Pulavarty @ 2013-05-29 15:10 UTC (permalink / raw)
To: Wenchao Xia
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, nab,
Paolo Bonzini, Asias He
On 05/29/2013 02:05 AM, Wenchao Xia wrote:
> 于 2013-5-28 17:00, Wenchao Xia 写道:
>> 于 2013-5-28 16:33, Asias He 写道:
>>> On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
>>>> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
>>>>>>> From: Nicholas Bellinger <nab@linux-iscsi.org>
>>>>>>>
>>>>>>> The WWPN specified in configfs is passed to "-device
>>>>>>> vhost-scsi-pci".
>>>>>>> The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
>>>>>>> not
>>>>>>> available from the QEMU command-line. Instead, I hardcode it to
>>>>>>> zero.
>>>>>>>
>>>>> Hi, Paolo
>>>>> Any document about how to config it correctly in configfs, before
>>>>> invoking qemu with the WWPN number?
>>>>
>>>> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
>>>> iSCSI for example) so it's quite simple. Here is an example:
>>>>
>>>> cd /sys/kernel/config/target
>>>> mkdir -p core/fileio_0/fileio
>>>> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
>>>> core/fileio_0/fileio/control
>>>> echo 1 > core/fileio_0/fileio/enable
>>>> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
>>>> cd vhost/naa.600140554cf3a18e/tpgt_0
>>>> ln -sf ../../../../../core/fileio_0/fileio/
>>>> lun/lun_0/virtual_scsi_port
>>>> echo naa.60014053226f0388 > nexus
>>>>
>>>> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
>>>> target WWN that you have to pass to "-device vhost-scsi-pci".
>>>>
>>>> Paolo
>>>
>>> For me, I always use targetcli utils instead of the sysfs interface.
>>> targetcli in F18 has vhost support now.
>>>
>> Thanks very much for above information, I'll try it for test.
>>
> I have done a basic test of vhost-scsi, following is the result I'd
> like to post, generally it seems fine:
>
> Result:
> fdisk/mkfs: fdisk can find it, mke2fs works fine.
> mount: can mount it.
> file I/O: dd 90M zero to a file in that disk succeed.
I tried without nested kvm.
>
> Issues:
> 1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
> dev fd0, sector 0", I guess it is caused by nested KVM that failed
> to kick host kernel?
I don't see this issue. Are you sure "fd0" is actually the scsi device ?
what is "fd0" ?
> 2) in fdisk -l, it shows 512 bytes larger than the parameter I
> specified in fd_dev_size parameter in configfs on host.(shows
> 104858112 bytes, see the invocation script below)
>
I see the same. For some reason "fdisk -l" in the VM shows
512-bytes more than the actual size for the file (on the host).
Thanks,
Badari
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-29 15:10 ` Badari Pulavarty
@ 2013-05-29 22:17 ` Asias He
2013-05-30 4:29 ` Nicholas A. Bellinger
2013-05-30 2:09 ` [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module Wenchao Xia
1 sibling, 1 reply; 56+ messages in thread
From: Asias He @ 2013-05-29 22:17 UTC (permalink / raw)
To: Badari Pulavarty
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, nab,
Paolo Bonzini, Wenchao Xia
On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
> On 05/29/2013 02:05 AM, Wenchao Xia wrote:
> >于 2013-5-28 17:00, Wenchao Xia 写道:
> >>于 2013-5-28 16:33, Asias He 写道:
> >>>On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
> >>>>Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> >>>>>>>From: Nicholas Bellinger <nab@linux-iscsi.org>
> >>>>>>>
> >>>>>>>The WWPN specified in configfs is passed to "-device
> >>>>>>>vhost-scsi-pci".
> >>>>>>>The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
> >>>>>>>not
> >>>>>>>available from the QEMU command-line. Instead, I hardcode it to
> >>>>>>>zero.
> >>>>>>>
> >>>>>Hi, Paolo
> >>>>> Any document about how to config it correctly in configfs, before
> >>>>>invoking qemu with the WWPN number?
> >>>>
> >>>>Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> >>>>iSCSI for example) so it's quite simple. Here is an example:
> >>>>
> >>>>cd /sys/kernel/config/target
> >>>>mkdir -p core/fileio_0/fileio
> >>>>echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> >>>>core/fileio_0/fileio/control
> >>>>echo 1 > core/fileio_0/fileio/enable
> >>>>mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> >>>>cd vhost/naa.600140554cf3a18e/tpgt_0
> >>>>ln -sf ../../../../../core/fileio_0/fileio/
> >>>>lun/lun_0/virtual_scsi_port
> >>>>echo naa.60014053226f0388 > nexus
> >>>>
> >>>>The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> >>>>target WWN that you have to pass to "-device vhost-scsi-pci".
> >>>>
> >>>>Paolo
> >>>
> >>>For me, I always use targetcli utils instead of the sysfs interface.
> >>>targetcli in F18 has vhost support now.
> >>>
> >> Thanks very much for above information, I'll try it for test.
> >>
> > I have done a basic test of vhost-scsi, following is the result I'd
> >like to post, generally it seems fine:
> >
> >Result:
> > fdisk/mkfs: fdisk can find it, mke2fs works fine.
> > mount: can mount it.
> > file I/O: dd 90M zero to a file in that disk succeed.
>
>
>
> I tried without nested kvm.
>
> >
> >Issues:
> > 1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
> >dev fd0, sector 0", I guess it is caused by nested KVM that failed
> >to kick host kernel?
>
>
> I don't see this issue. Are you sure "fd0" is actually the scsi device ?
> what is "fd0" ?
>
> > 2) in fdisk -l, it shows 512 bytes larger than the parameter I
> >specified in fd_dev_size parameter in configfs on host.(shows
> >104858112 bytes, see the invocation script below)
> >
>
> I see the same. For some reason "fdisk -l" in the VM shows
> 512-bytes more than the actual size for the file (on the host).
Hmm, interesting. Will look into it.
Nick, Any ideas here?
> Thanks,
> Badari
>
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-29 22:17 ` Asias He
@ 2013-05-30 4:29 ` Nicholas A. Bellinger
2013-05-30 5:36 ` Nicholas A. Bellinger
0 siblings, 1 reply; 56+ messages in thread
From: Nicholas A. Bellinger @ 2013-05-30 4:29 UTC (permalink / raw)
To: Asias He
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, target-devel,
Badari Pulavarty, Paolo Bonzini, Wenchao Xia
On Thu, 2013-05-30 at 06:17 +0800, Asias He wrote:
> On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
> > On 05/29/2013 02:05 AM, Wenchao Xia wrote:
> > >于 2013-5-28 17:00, Wenchao Xia 写道:
<SNIP>
> > > I have done a basic test of vhost-scsi, following is the result I'd
> > >like to post, generally it seems fine:
> > >
> > >Result:
> > > fdisk/mkfs: fdisk can find it, mke2fs works fine.
> > > mount: can mount it.
> > > file I/O: dd 90M zero to a file in that disk succeed.
> >
> >
> >
> > I tried without nested kvm.
> >
> > >
> > >Issues:
> > > 1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
> > >dev fd0, sector 0", I guess it is caused by nested KVM that failed
> > >to kick host kernel?
> >
> >
> > I don't see this issue. Are you sure "fd0" is actually the scsi device ?
> > what is "fd0" ?
> >
> > > 2) in fdisk -l, it shows 512 bytes larger than the parameter I
> > >specified in fd_dev_size parameter in configfs on host.(shows
> > >104858112 bytes, see the invocation script below)
> > >
> >
> > I see the same. For some reason "fdisk -l" in the VM shows
> > 512-bytes more than the actual size for the file (on the host).
>
> Hmm, interesting. Will look into it.
>
> Nick, Any ideas here?
>
Mmm, fd_get_blocks() is not returning the expected minus one logical
blocks with a !S_ISBLK() setup.
This is happening for every other backend ->get_blocks() call already,
and should be happening for the fd_dev_size case as well.
Applying the following to target-pending.git now.
diff --git a/drivers/target/target_core_file.c b/drivers/target/target_core_file.c
index 1b1d544..8a2ac90 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -694,11 +694,12 @@ static sector_t fd_get_blocks(struct se_device *dev)
* to handle underlying block_device resize operations.
*/
if (S_ISBLK(i->i_mode))
- dev_size = (i_size_read(i) - fd_dev->fd_block_size);
+ dev_size = i_size_read(i);
else
dev_size = fd_dev->fd_dev_size;
- return div_u64(dev_size, dev->dev_attrib.block_size);
+ return div_u64(dev_size - fd_dev->fd_block_size,
+ dev->dev_attrib.block_size);
}
static struct sbc_ops fd_sbc_ops = {
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-30 4:29 ` Nicholas A. Bellinger
@ 2013-05-30 5:36 ` Nicholas A. Bellinger
2013-05-30 18:00 ` Badari Pulavarty
2013-06-06 22:53 ` [Qemu-devel] vhost-scsi and pscsi Badari
0 siblings, 2 replies; 56+ messages in thread
From: Nicholas A. Bellinger @ 2013-05-30 5:36 UTC (permalink / raw)
To: Asias He
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, target-devel,
Badari Pulavarty, Paolo Bonzini, Wenchao Xia
On Wed, 2013-05-29 at 21:29 -0700, Nicholas A. Bellinger wrote:
> On Thu, 2013-05-30 at 06:17 +0800, Asias He wrote:
> > On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
> > > On 05/29/2013 02:05 AM, Wenchao Xia wrote:
> > > >于 2013-5-28 17:00, Wenchao Xia 写道:
>
> <SNIP>
>
> > > > I have done a basic test of vhost-scsi, following is the result I'd
> > > >like to post, generally it seems fine:
> > > >
> > > >Result:
> > > > fdisk/mkfs: fdisk can find it, mke2fs works fine.
> > > > mount: can mount it.
> > > > file I/O: dd 90M zero to a file in that disk succeed.
> > >
> > >
> > >
> > > I tried without nested kvm.
> > >
> > > >
> > > >Issues:
> > > > 1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
> > > >dev fd0, sector 0", I guess it is caused by nested KVM that failed
> > > >to kick host kernel?
> > >
> > >
> > > I don't see this issue. Are you sure "fd0" is actually the scsi device ?
> > > what is "fd0" ?
> > >
> > > > 2) in fdisk -l, it shows 512 bytes larger than the parameter I
> > > >specified in fd_dev_size parameter in configfs on host.(shows
> > > >104858112 bytes, see the invocation script below)
> > > >
> > >
> > > I see the same. For some reason "fdisk -l" in the VM shows
> > > 512-bytes more than the actual size for the file (on the host).
> >
> > Hmm, interesting. Will look into it.
> >
> > Nick, Any ideas here?
> >
>
> Mmm, fd_get_blocks() is not returning the expected minus one logical
> blocks with a !S_ISBLK() setup.
>
> This is happening for every other backend ->get_blocks() call already,
> and should be happening for the fd_dev_size case as well.
>
> Applying the following to target-pending.git now.
>
Actually sorry, that last patch is not correct..
Here's a better one to properly set fd_dev->fd_block_size at configure
time, and use dev_attrib.block_size in fd_get_blocks() to allow for user
defined block_sizes.
Thanks,
--nab
commit 9e309f9307fe644dee8718980bfcb77de91ce38e
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Wed May 29 21:35:23 2013 -0700
target/file: Fix off-by-one READ_CAPACITY bug for !S_ISBLK export
This patch fixes a bug where FILEIO was incorrectly reporting the number
of logical blocks (+ 1) when using non struct block_device export mode.
It changes fd_get_blocks() to follow all other backend ->get_blocks() cases,
and reduces the calculated dev_size by one dev->dev_attrib.block_size
number of bytes, and fixes the initial block_size assignment within
fd_configure_device()
Reported-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Reported-by: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
diff --git a/drivers/target/target_core_file.c b/drivers/target/target_core_file.c
index 1b1d544..b11890d 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -153,6 +153,7 @@ static int fd_configure_device(struct se_device *dev)
struct request_queue *q = bdev_get_queue(inode->i_bdev);
unsigned long long dev_size;
+ fd_dev->fd_block_size = bdev_logical_block_size(inode->i_bdev);
/*
* Determine the number of bytes from i_size_read() minus
* one (1) logical sector from underlying struct block_device
@@ -199,6 +200,7 @@ static int fd_configure_device(struct se_device *dev)
goto fail;
}
+ fd_dev->fd_block_size = FD_BLOCKSIZE;
/*
* Limit UNMAP emulation to 8k Number of LBAs (NoLB)
*/
@@ -217,9 +219,7 @@ static int fd_configure_device(struct se_device *dev)
dev->dev_attrib.max_write_same_len = 0x1000;
}
- fd_dev->fd_block_size = dev->dev_attrib.hw_block_size;
-
- dev->dev_attrib.hw_block_size = FD_BLOCKSIZE;
+ dev->dev_attrib.hw_block_size = fd_dev->fd_block_size;
dev->dev_attrib.hw_max_sectors = FD_MAX_SECTORS;
dev->dev_attrib.hw_queue_depth = FD_MAX_DEVICE_QUEUE_DEPTH;
@@ -694,11 +694,12 @@ static sector_t fd_get_blocks(struct se_device *dev)
* to handle underlying block_device resize operations.
*/
if (S_ISBLK(i->i_mode))
- dev_size = (i_size_read(i) - fd_dev->fd_block_size);
+ dev_size = i_size_read(i);
else
dev_size = fd_dev->fd_dev_size;
- return div_u64(dev_size, dev->dev_attrib.block_size);
+ return div_u64(dev_size - dev->dev_attrib.block_size,
+ dev->dev_attrib.block_size);
}
static struct sbc_ops fd_sbc_ops = {
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-30 5:36 ` Nicholas A. Bellinger
@ 2013-05-30 18:00 ` Badari Pulavarty
2013-06-06 22:53 ` [Qemu-devel] vhost-scsi and pscsi Badari
1 sibling, 0 replies; 56+ messages in thread
From: Badari Pulavarty @ 2013-05-30 18:00 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, target-devel,
Paolo Bonzini, Asias He, Wenchao Xia
On 05/29/2013 10:36 PM, Nicholas A. Bellinger wrote:
> On Wed, 2013-05-29 at 21:29 -0700, Nicholas A. Bellinger wrote:
>> On Thu, 2013-05-30 at 06:17 +0800, Asias He wrote:
>>> On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
>>>> On 05/29/2013 02:05 AM, Wenchao Xia wrote:
>>>>> 于 2013-5-28 17:00, Wenchao Xia 写道:
>> <SNIP>
>>
>>>>> I have done a basic test of vhost-scsi, following is the result I'd
>>>>> like to post, generally it seems fine:
>>>>>
>>>>> Result:
>>>>> fdisk/mkfs: fdisk can find it, mke2fs works fine.
>>>>> mount: can mount it.
>>>>> file I/O: dd 90M zero to a file in that disk succeed.
>>>>
>>>>
>>>> I tried without nested kvm.
>>>>
>>>>> Issues:
>>>>> 1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
>>>>> dev fd0, sector 0", I guess it is caused by nested KVM that failed
>>>>> to kick host kernel?
>>>>
>>>> I don't see this issue. Are you sure "fd0" is actually the scsi device ?
>>>> what is "fd0" ?
>>>>
>>>>> 2) in fdisk -l, it shows 512 bytes larger than the parameter I
>>>>> specified in fd_dev_size parameter in configfs on host.(shows
>>>>> 104858112 bytes, see the invocation script below)
>>>>>
>>>> I see the same. For some reason "fdisk -l" in the VM shows
>>>> 512-bytes more than the actual size for the file (on the host).
>>> Hmm, interesting. Will look into it.
>>>
>>> Nick, Any ideas here?
>>>
>> Mmm, fd_get_blocks() is not returning the expected minus one logical
>> blocks with a !S_ISBLK() setup.
>>
>> This is happening for every other backend ->get_blocks() call already,
>> and should be happening for the fd_dev_size case as well.
>>
>> Applying the following to target-pending.git now.
>>
> Actually sorry, that last patch is not correct..
>
> Here's a better one to properly set fd_dev->fd_block_size at configure
> time, and use dev_attrib.block_size in fd_get_blocks() to allow for user
> defined block_sizes.
>
> Thanks,
>
> --nab
>
> commit 9e309f9307fe644dee8718980bfcb77de91ce38e
> Author: Nicholas Bellinger <nab@linux-iscsi.org>
> Date: Wed May 29 21:35:23 2013 -0700
>
> target/file: Fix off-by-one READ_CAPACITY bug for !S_ISBLK export
>
> This patch fixes a bug where FILEIO was incorrectly reporting the number
> of logical blocks (+ 1) when using non struct block_device export mode.
>
> It changes fd_get_blocks() to follow all other backend ->get_blocks() cases,
> and reduces the calculated dev_size by one dev->dev_attrib.block_size
> number of bytes, and fixes the initial block_size assignment within
> fd_configure_device()
>
> Reported-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
> Reported-by: Badari Pulavarty <pbadari@us.ibm.com>
> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>
> diff --git a/drivers/target/target_core_file.c b/drivers/target/target_core_file.c
> index 1b1d544..b11890d 100644
> --- a/drivers/target/target_core_file.c
> +++ b/drivers/target/target_core_file.c
> @@ -153,6 +153,7 @@ static int fd_configure_device(struct se_device *dev)
> struct request_queue *q = bdev_get_queue(inode->i_bdev);
> unsigned long long dev_size;
>
> + fd_dev->fd_block_size = bdev_logical_block_size(inode->i_bdev);
> /*
> * Determine the number of bytes from i_size_read() minus
> * one (1) logical sector from underlying struct block_device
> @@ -199,6 +200,7 @@ static int fd_configure_device(struct se_device *dev)
> goto fail;
> }
>
> + fd_dev->fd_block_size = FD_BLOCKSIZE;
> /*
> * Limit UNMAP emulation to 8k Number of LBAs (NoLB)
> */
> @@ -217,9 +219,7 @@ static int fd_configure_device(struct se_device *dev)
> dev->dev_attrib.max_write_same_len = 0x1000;
> }
>
> - fd_dev->fd_block_size = dev->dev_attrib.hw_block_size;
> -
> - dev->dev_attrib.hw_block_size = FD_BLOCKSIZE;
> + dev->dev_attrib.hw_block_size = fd_dev->fd_block_size;
> dev->dev_attrib.hw_max_sectors = FD_MAX_SECTORS;
> dev->dev_attrib.hw_queue_depth = FD_MAX_DEVICE_QUEUE_DEPTH;
>
> @@ -694,11 +694,12 @@ static sector_t fd_get_blocks(struct se_device *dev)
> * to handle underlying block_device resize operations.
> */
> if (S_ISBLK(i->i_mode))
> - dev_size = (i_size_read(i) - fd_dev->fd_block_size);
> + dev_size = i_size_read(i);
> else
> dev_size = fd_dev->fd_dev_size;
>
> - return div_u64(dev_size, dev->dev_attrib.block_size);
> + return div_u64(dev_size - dev->dev_attrib.block_size,
> + dev->dev_attrib.block_size);
> }
>
> static struct sbc_ops fd_sbc_ops = {
>
>
Verified and it shows the correct value now.
Thanks,
Badari
^ permalink raw reply [flat|nested] 56+ messages in thread* [Qemu-devel] vhost-scsi and pscsi
2013-05-30 5:36 ` Nicholas A. Bellinger
2013-05-30 18:00 ` Badari Pulavarty
@ 2013-06-06 22:53 ` Badari
1 sibling, 0 replies; 56+ messages in thread
From: Badari @ 2013-06-06 22:53 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: Paolo Bonzini, Asias He, qemu-devel
Hi Nicholas,
I am trying to test vhost-scsi with pscsi lio. I am able to create a
target and
pass it to QEMU. I don't see any error from tcm_vhost or qemu. But the guest
VM doesn't see any SCSI device.
What am I missing ? Here is how I am using pscsi target.
wwpn="naa.6001405bd4e8476e"
tpgt=/sys/kernel/config/target/vhost/$wwpn/tpgt_0
nexus=$tpgt/nexus
mkdir -p $tpgt
echo -n $wwpn > $nexus
n=0
lun=$tpgt/lun/lun_${n}
data=/sys/kernel/config/target/core/pscsi_0/data_${n}
dsk=/dev/sdf
mkdir -p $lun
mkdir -p $data
echo -n ${dsk} > $data/udev_path
echo "scsi_host_id=1,scsi_channel_id=0,scsi_target_id=2,scsi_lun_id=0" >
$data/control
echo -n 1 > $data/enable
ln -s $data $lun
Thanks,
Badari
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-29 15:10 ` Badari Pulavarty
2013-05-29 22:17 ` Asias He
@ 2013-05-30 2:09 ` Wenchao Xia
1 sibling, 0 replies; 56+ messages in thread
From: Wenchao Xia @ 2013-05-30 2:09 UTC (permalink / raw)
To: Badari Pulavarty
Cc: Anthony Liguori, Michael S. Tsirkin, qemu-devel, nab,
Paolo Bonzini, Asias He
于 2013-5-29 23:10, Badari Pulavarty 写道:
> On 05/29/2013 02:05 AM, Wenchao Xia wrote:
>> 于 2013-5-28 17:00, Wenchao Xia 写道:
>>> 于 2013-5-28 16:33, Asias He 写道:
>>>> On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
>>>>> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
>>>>>>>> From: Nicholas Bellinger <nab@linux-iscsi.org>
>>>>>>>>
>>>>>>>> The WWPN specified in configfs is passed to "-device
>>>>>>>> vhost-scsi-pci".
>>>>>>>> The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
>>>>>>>> not
>>>>>>>> available from the QEMU command-line. Instead, I hardcode it to
>>>>>>>> zero.
>>>>>>>>
>>>>>> Hi, Paolo
>>>>>> Any document about how to config it correctly in configfs, before
>>>>>> invoking qemu with the WWPN number?
>>>>>
>>>>> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
>>>>> iSCSI for example) so it's quite simple. Here is an example:
>>>>>
>>>>> cd /sys/kernel/config/target
>>>>> mkdir -p core/fileio_0/fileio
>>>>> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
>>>>> core/fileio_0/fileio/control
>>>>> echo 1 > core/fileio_0/fileio/enable
>>>>> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
>>>>> cd vhost/naa.600140554cf3a18e/tpgt_0
>>>>> ln -sf ../../../../../core/fileio_0/fileio/
>>>>> lun/lun_0/virtual_scsi_port
>>>>> echo naa.60014053226f0388 > nexus
>>>>>
>>>>> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
>>>>> target WWN that you have to pass to "-device vhost-scsi-pci".
>>>>>
>>>>> Paolo
>>>>
>>>> For me, I always use targetcli utils instead of the sysfs interface.
>>>> targetcli in F18 has vhost support now.
>>>>
>>> Thanks very much for above information, I'll try it for test.
>>>
>> I have done a basic test of vhost-scsi, following is the result I'd
>> like to post, generally it seems fine:
>>
>> Result:
>> fdisk/mkfs: fdisk can find it, mke2fs works fine.
>> mount: can mount it.
>> file I/O: dd 90M zero to a file in that disk succeed.
>
>
>
> I tried without nested kvm.
>
>>
>> Issues:
>> 1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
>> dev fd0, sector 0", I guess it is caused by nested KVM that failed
>> to kick host kernel?
>
>
> I don't see this issue. Are you sure "fd0" is actually the scsi device ?
> what is "fd0" ?
>
I am not sure, it just come out from dmesg when fdisk -l hung, and
following line is "sdb" which is the vhost-scsi device, and fdisk
printing stopped before "sdb" for a few seconds, so I think it's it.
it happened once after my partition operation.
My instinct opinion is it happens only in nested KVM when host
missed a kick, since following I/O can succeed. Sadly I have no
bare-metal at hand to test as a comparation.
>> 2) in fdisk -l, it shows 512 bytes larger than the parameter I
>> specified in fd_dev_size parameter in configfs on host.(shows
>> 104858112 bytes, see the invocation script below)
>>
>
> I see the same. For some reason "fdisk -l" in the VM shows
> 512-bytes more than the actual size for the file (on the host).
>
> Thanks,
> Badari
>
--
Best Regards
Wenchao Xia
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-05-28 8:01 ` Paolo Bonzini
2013-05-28 8:33 ` Asias He
@ 2013-06-19 12:55 ` Libaiqing
2013-06-20 1:33 ` Asias He
1 sibling, 1 reply; 56+ messages in thread
From: Libaiqing @ 2013-06-19 12:55 UTC (permalink / raw)
To: Paolo Bonzini, Wenchao Xia
Cc: asias@redhat.com, Haofeng, qemu-devel@nongnu.org,
nab@linux-iscsi.org, Michael S. Tsirkin
Hi paolo,
The vhost-scsi device can be used as boot device?
I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
Could you give me some advise to debug this problem ? I can provide more information if need.
Regards,
baiqing
> -----Original Message-----
> From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org] On
> Behalf Of Paolo Bonzini
> Sent: Tuesday, May 28, 2013 4:01 PM
> To: Wenchao Xia
> Cc: asias@redhat.com; qemu-devel@nongnu.org; nab@linux-iscsi.org;
> Michael S. Tsirkin
> Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> tcm_vhost Linux kernel module
>
> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> >> >
> >> > The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
> >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
> >> > available from the QEMU command-line. Instead, I hardcode it to
> zero.
> >> >
> > Hi, Paolo
> > Any document about how to config it correctly in configfs, before
> > invoking qemu with the WWPN number?
>
> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> iSCSI for example) so it's quite simple. Here is an example:
>
> cd /sys/kernel/config/target
> mkdir -p core/fileio_0/fileio
> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> core/fileio_0/fileio/control
> echo 1 > core/fileio_0/fileio/enable
> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> cd vhost/naa.600140554cf3a18e/tpgt_0
> ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> echo naa.60014053226f0388 > nexus
>
> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> target WWN that you have to pass to "-device vhost-scsi-pci".
>
> Paolo
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-06-19 12:55 ` Libaiqing
@ 2013-06-20 1:33 ` Asias He
2013-06-20 3:22 ` Wenchao Xia
2013-06-20 8:49 ` Libaiqing
0 siblings, 2 replies; 56+ messages in thread
From: Asias He @ 2013-06-20 1:33 UTC (permalink / raw)
To: Libaiqing
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> Hi paolo,
> The vhost-scsi device can be used as boot device?
> I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> Could you give me some advise to debug this problem ? I can provide more information if need.
Boot from vhost-scsi is supposed to work. The seabios you used should be
fine which contains the fixes for vhost-scsi.
Instead of playing with the /sys/kernel/config/target directly, I really
recommend using targetcli utils.
Nab, I think we really should write some docs for people to use
vhost-scsi.
This is how I install and use targetcli in RHEL6. Note you need upstream
kernel and qemu bits for vhost-scsi.
# yum groupinstall 'Development tools'
# yum install python-devel epydoc python-simpleparse
# git clone git://github.com/agrover/rtslib-fb.git
# git clone git://github.com/agrover/targetcli-fb.git
# git clone git://github.com/agrover/configshell-fb.git
# for i in rtslib-fb configshell-fb targetcli-fb; do
make -C $i rpm
yum localinstall $i/dist/*.noarch.rpm
done
In targetcli, create a backstore and vhost wwpn, e.g.
# targetcli
/> /backstores/ramdisk create r0 1g
/> /vhost create
/> cd /vhost/naa.500140527cb6616b/tpg1/luns
/> create /backstores/ramdisk/r0
# qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
Hope this helps.
> Regards,
> baiqing
>
> > -----Original Message-----
> > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org] On
> > Behalf Of Paolo Bonzini
> > Sent: Tuesday, May 28, 2013 4:01 PM
> > To: Wenchao Xia
> > Cc: asias@redhat.com; qemu-devel@nongnu.org; nab@linux-iscsi.org;
> > Michael S. Tsirkin
> > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> > tcm_vhost Linux kernel module
> >
> > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > >> >
> > >> > The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
> > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
> > >> > available from the QEMU command-line. Instead, I hardcode it to
> > zero.
> > >> >
> > > Hi, Paolo
> > > Any document about how to config it correctly in configfs, before
> > > invoking qemu with the WWPN number?
> >
> > Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> > iSCSI for example) so it's quite simple. Here is an example:
> >
> > cd /sys/kernel/config/target
> > mkdir -p core/fileio_0/fileio
> > echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > core/fileio_0/fileio/control
> > echo 1 > core/fileio_0/fileio/enable
> > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > cd vhost/naa.600140554cf3a18e/tpgt_0
> > ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> > echo naa.60014053226f0388 > nexus
> >
> > The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> > target WWN that you have to pass to "-device vhost-scsi-pci".
> >
> > Paolo
>
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-06-20 1:33 ` Asias He
@ 2013-06-20 3:22 ` Wenchao Xia
2013-06-20 8:49 ` Libaiqing
1 sibling, 0 replies; 56+ messages in thread
From: Wenchao Xia @ 2013-06-20 3:22 UTC (permalink / raw)
To: Asias He
Cc: Libaiqing, Michael S. Tsirkin, qemu-devel@nongnu.org,
nab@linux-iscsi.org, Haofeng, Paolo Bonzini
于 2013-6-20 9:33, Asias He 写道:
> On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
>> Hi paolo,
>> The vhost-scsi device can be used as boot device?
>> I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
>> Could you give me some advise to debug this problem ? I can provide more information if need.
>
> Boot from vhost-scsi is supposed to work. The seabios you used should be
> fine which contains the fixes for vhost-scsi.
>
> Instead of playing with the /sys/kernel/config/target directly, I really
> recommend using targetcli utils.
>
> Nab, I think we really should write some docs for people to use
> vhost-scsi.
A section in qemu-options.hx would be great, currently an example is
good enough to me.
>
> This is how I install and use targetcli in RHEL6. Note you need upstream
> kernel and qemu bits for vhost-scsi.
>
> # yum groupinstall 'Development tools'
> # yum install python-devel epydoc python-simpleparse
>
> # git clone git://github.com/agrover/rtslib-fb.git
> # git clone git://github.com/agrover/targetcli-fb.git
> # git clone git://github.com/agrover/configshell-fb.git
> # for i in rtslib-fb configshell-fb targetcli-fb; do
> make -C $i rpm
> yum localinstall $i/dist/*.noarch.rpm
> done
>
> In targetcli, create a backstore and vhost wwpn, e.g.
> # targetcli
> /> /backstores/ramdisk create r0 1g
> /> /vhost create
> /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> /> create /backstores/ramdisk/r0
>
> # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
>
> Hope this helps.
>
>> Regards,
>> baiqing
>>
>>> -----Original Message-----
>>> From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
>>> [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org] On
>>> Behalf Of Paolo Bonzini
>>> Sent: Tuesday, May 28, 2013 4:01 PM
>>> To: Wenchao Xia
>>> Cc: asias@redhat.com; qemu-devel@nongnu.org; nab@linux-iscsi.org;
>>> Michael S. Tsirkin
>>> Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
>>> tcm_vhost Linux kernel module
>>>
>>> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
>>>>>> From: Nicholas Bellinger <nab@linux-iscsi.org>
>>>>>>
>>>>>> The WWPN specified in configfs is passed to "-device vhost-scsi-pci".
>>>>>> The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
>>>>>> available from the QEMU command-line. Instead, I hardcode it to
>>> zero.
>>>>>>
>>>> Hi, Paolo
>>>> Any document about how to config it correctly in configfs, before
>>>> invoking qemu with the WWPN number?
>>>
>>> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
>>> iSCSI for example) so it's quite simple. Here is an example:
>>>
>>> cd /sys/kernel/config/target
>>> mkdir -p core/fileio_0/fileio
>>> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
>>> core/fileio_0/fileio/control
>>> echo 1 > core/fileio_0/fileio/enable
>>> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
>>> cd vhost/naa.600140554cf3a18e/tpgt_0
>>> ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
>>> echo naa.60014053226f0388 > nexus
>>>
>>> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
>>> target WWN that you have to pass to "-device vhost-scsi-pci".
>>>
>>> Paolo
>>
>
--
Best Regards
Wenchao Xia
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-06-20 1:33 ` Asias He
2013-06-20 3:22 ` Wenchao Xia
@ 2013-06-20 8:49 ` Libaiqing
2013-06-20 9:38 ` Asias He
1 sibling, 1 reply; 56+ messages in thread
From: Libaiqing @ 2013-06-20 8:49 UTC (permalink / raw)
To: Asias He
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
Hi Asias,
Thanks for your config.
According to you config,I test booting from vhost device with upstream kernel and qemu,but failed.
1 installing guest from cdrom,ok.
2 booting vhost-scsi,guest fs error occurs.
3 using fileio backstores,the error is same..
4 rebooting guest,a log printed:
(qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
5 using upstream seabios,core dumped.
Could you give me some advise to debug this problem ? I can provide more information if need.
The qemu cmd:
[root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm -name fedora -M pc -m 1024 -smp 2 -drive file=/home/fedora18.iso,if=ide,media=cdrom -device vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga qxl -vnc :1
The vnc output:
Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED INCONSISTENCY;RUN FSCK MANUALLY.
Dracut-initqueue[189]: Warning: e2fsck returned with 4
Dracut-initqueue[189]: Warning: ***An error occurred during the file system check.
The guest kernel log:
Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
Kernel: scsi2 : Virtio SCSI HBA
Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
Kernel: sd 2:0:1:0: [sda]write protect is off
Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
Kernel: sda sda1 sda2
Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
Dracut-initqueue[189]: Scanning devices sda2 for LVM
Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
Dracut-initqueue[189]: inactive '/dev/fedora/root'...
The info of host:
[root@fedora121 x86_64-softmmu]# uname -a
Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
vhost_scsi 49456 5
target_core_mod 282163 14 target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vhost_scsi
[root@fedora121 x86_64-softmmu]# targetcli
targetcli shell version v2.1.fb26
Copyright 2011 by RisingTide Systems LLC and others.
For help on commands, type 'help'.
/> ls
o- / ......................................................................................................................... [...]
o- backstores .............................................................................................................. [...]
| o- block .................................................................................................. [Storage Objects: 0]
| o- fileio ................................................................................................. [Storage Objects: 0]
| o- pscsi .................................................................................................. [Storage Objects: 0]
| o- ramdisk ................................................................................................ [Storage Objects: 1]
| o- r0 ................................................................................................... [(6.0GiB) activated]
o- iscsi ............................................................................................................ [Targets: 0]
o- loopback ......................................................................................................... [Targets: 0]
o- vhost ............................................................................................................ [Targets: 1]
o- naa.50014057133e25dc .............................................................................................. [TPGs: 1]
o- tpg1 ............................................................................................... [naa.5001405a70ac3421]
o- acls .......................................................................................................... [ACLs: 0]
o- luns .......................................................................................................... [LUNs: 1]
o- lun0 ..................................................................................................... [ramdisk/r0]
Regards,
baiqing
> -----Original Message-----
> From: Asias He [mailto:asias@redhat.com]
> Sent: Thursday, June 20, 2013 9:34 AM
> To: Libaiqing
> Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> tcm_vhost Linux kernel module
>
> On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > Hi paolo,
> > The vhost-scsi device can be used as boot device?
> > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > Could you give me some advise to debug this problem ? I can provide
> more information if need.
>
> Boot from vhost-scsi is supposed to work. The seabios you used should be
> fine which contains the fixes for vhost-scsi.
>
> Instead of playing with the /sys/kernel/config/target directly, I really
> recommend using targetcli utils.
>
> Nab, I think we really should write some docs for people to use
> vhost-scsi.
>
> This is how I install and use targetcli in RHEL6. Note you need upstream
> kernel and qemu bits for vhost-scsi.
>
> # yum groupinstall 'Development tools'
> # yum install python-devel epydoc python-simpleparse
>
> # git clone git://github.com/agrover/rtslib-fb.git
> # git clone git://github.com/agrover/targetcli-fb.git
> # git clone git://github.com/agrover/configshell-fb.git
> # for i in rtslib-fb configshell-fb targetcli-fb; do
> make -C $i rpm
> yum localinstall $i/dist/*.noarch.rpm
> done
>
> In targetcli, create a backstore and vhost wwpn, e.g.
> # targetcli
> /> /backstores/ramdisk create r0 1g
> /> /vhost create
> /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> /> create /backstores/ramdisk/r0
>
> # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
>
> Hope this helps.
>
> > Regards,
> > baiqing
> >
> > > -----Original Message-----
> > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org] On
> > > Behalf Of Paolo Bonzini
> > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > To: Wenchao Xia
> > > Cc: asias@redhat.com; qemu-devel@nongnu.org; nab@linux-iscsi.org;
> > > Michael S. Tsirkin
> > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting
> the
> > > tcm_vhost Linux kernel module
> > >
> > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > >> >
> > > >> > The WWPN specified in configfs is passed to "-device
> vhost-scsi-pci".
> > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
> > > >> > available from the QEMU command-line. Instead, I hardcode it to
> > > zero.
> > > >> >
> > > > Hi, Paolo
> > > > Any document about how to config it correctly in configfs, before
> > > > invoking qemu with the WWPN number?
> > >
> > > Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> > > iSCSI for example) so it's quite simple. Here is an example:
> > >
> > > cd /sys/kernel/config/target
> > > mkdir -p core/fileio_0/fileio
> > > echo
> 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > core/fileio_0/fileio/control
> > > echo 1 > core/fileio_0/fileio/enable
> > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> > > echo naa.60014053226f0388 > nexus
> > >
> > > The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > >
> > > Paolo
> >
>
> --
> Asias
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-06-20 8:49 ` Libaiqing
@ 2013-06-20 9:38 ` Asias He
2013-06-21 10:16 ` Libaiqing
0 siblings, 1 reply; 56+ messages in thread
From: Asias He @ 2013-06-20 9:38 UTC (permalink / raw)
To: Libaiqing
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> Hi Asias,
> Thanks for your config.
> According to you config,I test booting from vhost device with upstream kernel and qemu,but failed.
>
> 1 installing guest from cdrom,ok.
> 2 booting vhost-scsi,guest fs error occurs.
> 3 using fileio backstores,the error is same..
> 4 rebooting guest,a log printed:
> (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
Paolo, I remember you fixed a similar issue?
> 5 using upstream seabios,core dumped.
>
> Could you give me some advise to debug this problem ? I can provide more information if need.
Can you show me qemu commit id you used? Can you verity that if using the
host kernel for guest helps? Does booting directly (without the install
and reboot process) work?
> The qemu cmd:
> [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm -name fedora -M pc -m 1024 -smp 2 -drive file=/home/fedora18.iso,if=ide,media=cdrom -device vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga qxl -vnc :1
>
> The vnc output:
> Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED INCONSISTENCY;RUN FSCK MANUALLY.
> Dracut-initqueue[189]: Warning: e2fsck returned with 4
> Dracut-initqueue[189]: Warning: ***An error occurred during the file system check.
>
> The guest kernel log:
> Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> Kernel: scsi2 : Virtio SCSI HBA
> Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> Kernel: sd 2:0:1:0: [sda]write protect is off
> Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> Kernel: sda sda1 sda2
> Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> Dracut-initqueue[189]: Scanning devices sda2 for LVM
> Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> Dracut-initqueue[189]: inactive '/dev/fedora/root'...
>
> The info of host:
> [root@fedora121 x86_64-softmmu]# uname -a
> Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
> [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> vhost_scsi 49456 5
> target_core_mod 282163 14 target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vhost_scsi
> [root@fedora121 x86_64-softmmu]# targetcli
> targetcli shell version v2.1.fb26
> Copyright 2011 by RisingTide Systems LLC and others.
> For help on commands, type 'help'.
>
> /> ls
> o- / ......................................................................................................................... [...]
> o- backstores .............................................................................................................. [...]
> | o- block .................................................................................................. [Storage Objects: 0]
> | o- fileio ................................................................................................. [Storage Objects: 0]
> | o- pscsi .................................................................................................. [Storage Objects: 0]
> | o- ramdisk ................................................................................................ [Storage Objects: 1]
> | o- r0 ................................................................................................... [(6.0GiB) activated]
> o- iscsi ............................................................................................................ [Targets: 0]
> o- loopback ......................................................................................................... [Targets: 0]
> o- vhost ............................................................................................................ [Targets: 1]
> o- naa.50014057133e25dc .............................................................................................. [TPGs: 1]
> o- tpg1 ............................................................................................... [naa.5001405a70ac3421]
> o- acls .......................................................................................................... [ACLs: 0]
> o- luns .......................................................................................................... [LUNs: 1]
> o- lun0 ..................................................................................................... [ramdisk/r0]
>
> Regards,
> baiqing
> > -----Original Message-----
> > From: Asias He [mailto:asias@redhat.com]
> > Sent: Thursday, June 20, 2013 9:34 AM
> > To: Libaiqing
> > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> > tcm_vhost Linux kernel module
> >
> > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > Hi paolo,
> > > The vhost-scsi device can be used as boot device?
> > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > Could you give me some advise to debug this problem ? I can provide
> > more information if need.
> >
> > Boot from vhost-scsi is supposed to work. The seabios you used should be
> > fine which contains the fixes for vhost-scsi.
> >
> > Instead of playing with the /sys/kernel/config/target directly, I really
> > recommend using targetcli utils.
> >
> > Nab, I think we really should write some docs for people to use
> > vhost-scsi.
> >
> > This is how I install and use targetcli in RHEL6. Note you need upstream
> > kernel and qemu bits for vhost-scsi.
> >
> > # yum groupinstall 'Development tools'
> > # yum install python-devel epydoc python-simpleparse
> >
> > # git clone git://github.com/agrover/rtslib-fb.git
> > # git clone git://github.com/agrover/targetcli-fb.git
> > # git clone git://github.com/agrover/configshell-fb.git
> > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > make -C $i rpm
> > yum localinstall $i/dist/*.noarch.rpm
> > done
> >
> > In targetcli, create a backstore and vhost wwpn, e.g.
> > # targetcli
> > /> /backstores/ramdisk create r0 1g
> > /> /vhost create
> > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > /> create /backstores/ramdisk/r0
> >
> > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> >
> > Hope this helps.
> >
> > > Regards,
> > > baiqing
> > >
> > > > -----Original Message-----
> > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org] On
> > > > Behalf Of Paolo Bonzini
> > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > To: Wenchao Xia
> > > > Cc: asias@redhat.com; qemu-devel@nongnu.org; nab@linux-iscsi.org;
> > > > Michael S. Tsirkin
> > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting
> > the
> > > > tcm_vhost Linux kernel module
> > > >
> > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > >> >
> > > > >> > The WWPN specified in configfs is passed to "-device
> > vhost-scsi-pci".
> > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
> > > > >> > available from the QEMU command-line. Instead, I hardcode it to
> > > > zero.
> > > > >> >
> > > > > Hi, Paolo
> > > > > Any document about how to config it correctly in configfs, before
> > > > > invoking qemu with the WWPN number?
> > > >
> > > > Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> > > > iSCSI for example) so it's quite simple. Here is an example:
> > > >
> > > > cd /sys/kernel/config/target
> > > > mkdir -p core/fileio_0/fileio
> > > > echo
> > 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > core/fileio_0/fileio/control
> > > > echo 1 > core/fileio_0/fileio/enable
> > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> > > > echo naa.60014053226f0388 > nexus
> > > >
> > > > The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > >
> > > > Paolo
> > >
> >
> > --
> > Asias
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-06-20 9:38 ` Asias He
@ 2013-06-21 10:16 ` Libaiqing
2013-07-03 3:08 ` Libaiqing
2013-07-03 3:23 ` Asias He
0 siblings, 2 replies; 56+ messages in thread
From: Libaiqing @ 2013-06-21 10:16 UTC (permalink / raw)
To: Asias He
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
Hi Asias,
> -----Original Message-----
> From: Asias He [mailto:asias@redhat.com]
> Sent: Thursday, June 20, 2013 5:39 PM
> To: Libaiqing
> Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> tcm_vhost Linux kernel module
>
> On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > Hi Asias,
> > Thanks for your config.
> > According to you config,I test booting from vhost device with
> upstream kernel and qemu,but failed.
> >
> > 1 installing guest from cdrom,ok.
> > 2 booting vhost-scsi,guest fs error occurs.
> > 3 using fileio backstores,the error is same..
> > 4 rebooting guest,a log printed:
> > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object
> 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
>
> Paolo, I remember you fixed a similar issue?
>
> > 5 using upstream seabios,core dumped.
> >
> > Could you give me some advise to debug this problem ? I can provide
> more information if need.
>
> Can you show me qemu commit id you used? Can you verity that if using the
> host kernel for guest helps? Does booting directly (without the install
> and reboot process) work?
Qemu commit id is "commit 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
Guest kernel updateing is useless.
Booting directly doesn't work too.
> > The qemu cmd:
> > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm
> -name fedora -M pc -m 1024 -smp 2 -drive
> file=/home/fedora18.iso,if=ide,media=cdrom -device
> vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga qxl
> -vnc :1
> >
> > The vnc output:
> > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> INCONSISTENCY;RUN FSCK MANUALLY.
> > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> system check.
> >
> > The guest kernel log:
> > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > Kernel: scsi2 : Virtio SCSI HBA
> > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > Kernel: sd 2:0:1:0: [sda]write protect is off
> > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > Kernel: sda sda1 sda2
> > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> >
> > The info of host:
> > [root@fedora121 x86_64-softmmu]# uname -a
> > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64
> x86_64 x86_64 GNU/Linux
> > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > vhost_scsi 49456 5
> > target_core_mod 282163 14
> target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> ost_scsi
> > [root@fedora121 x86_64-softmmu]# targetcli
> > targetcli shell version v2.1.fb26
> > Copyright 2011 by RisingTide Systems LLC and others.
> > For help on commands, type 'help'.
> >
> > /> ls
> > o-
> / ..............................................................................................................
> ........... [...]
> > o-
> backstores ...............................................................................................
> ............... [...]
> > | o-
> block ..................................................................................................
> [Storage Objects: 0]
> > | o-
> fileio .................................................................................................
> [Storage Objects: 0]
> > | o-
> pscsi ..................................................................................................
> [Storage Objects: 0]
> > | o-
> ramdisk ................................................................................................
> [Storage Objects: 1]
> > | o-
> r0 ...................................................................................................
> [(6.0GiB) activated]
> > o-
> iscsi .........................................................................................................
> ... [Targets: 0]
> > o-
> loopback ..................................................................................................
> ....... [Targets: 0]
> > o-
> vhost .......................................................................................................
> ..... [Targets: 1]
> > o-
> naa.50014057133e25dc ............................................................................
> .................. [TPGs: 1]
> > o-
> tpg1 ...............................................................................................
> [naa.5001405a70ac3421]
> > o-
> acls ..........................................................................................................
> [ACLs: 0]
> > o-
> luns ..........................................................................................................
> [LUNs: 1]
> > o-
> lun0 .....................................................................................................
> [ramdisk/r0]
> >
> > Regards,
> > baiqing
> > > -----Original Message-----
> > > From: Asias He [mailto:asias@redhat.com]
> > > Sent: Thursday, June 20, 2013 9:34 AM
> > > To: Libaiqing
> > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting
> the
> > > tcm_vhost Linux kernel module
> > >
> > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > Hi paolo,
> > > > The vhost-scsi device can be used as boot device?
> > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > Could you give me some advise to debug this problem ? I can
> provide
> > > more information if need.
> > >
> > > Boot from vhost-scsi is supposed to work. The seabios you used should
> be
> > > fine which contains the fixes for vhost-scsi.
> > >
> > > Instead of playing with the /sys/kernel/config/target directly, I really
> > > recommend using targetcli utils.
> > >
> > > Nab, I think we really should write some docs for people to use
> > > vhost-scsi.
> > >
> > > This is how I install and use targetcli in RHEL6. Note you need upstream
> > > kernel and qemu bits for vhost-scsi.
> > >
> > > # yum groupinstall 'Development tools'
> > > # yum install python-devel epydoc python-simpleparse
> > >
> > > # git clone git://github.com/agrover/rtslib-fb.git
> > > # git clone git://github.com/agrover/targetcli-fb.git
> > > # git clone git://github.com/agrover/configshell-fb.git
> > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > make -C $i rpm
> > > yum localinstall $i/dist/*.noarch.rpm
> > > done
> > >
> > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > # targetcli
> > > /> /backstores/ramdisk create r0 1g
> > > /> /vhost create
> > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > /> create /backstores/ramdisk/r0
> > >
> > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > >
> > > Hope this helps.
> > >
> > > > Regards,
> > > > baiqing
> > > >
> > > > > -----Original Message-----
> > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> On
> > > > > Behalf Of Paolo Bonzini
> > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > To: Wenchao Xia
> > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> nab@linux-iscsi.org;
> > > > > Michael S. Tsirkin
> > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> supporting
> > > the
> > > > > tcm_vhost Linux kernel module
> > > > >
> > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > >> >
> > > > > >> > The WWPN specified in configfs is passed to "-device
> > > vhost-scsi-pci".
> > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
> not
> > > > > >> > available from the QEMU command-line. Instead, I hardcode it
> to
> > > > > zero.
> > > > > >> >
> > > > > > Hi, Paolo
> > > > > > Any document about how to config it correctly in configfs,
> before
> > > > > > invoking qemu with the WWPN number?
> > > > >
> > > > > Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > >
> > > > > cd /sys/kernel/config/target
> > > > > mkdir -p core/fileio_0/fileio
> > > > > echo
> > > 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > core/fileio_0/fileio/control
> > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> > > > > echo naa.60014053226f0388 > nexus
> > > > >
> > > > > The "nexus" value is the initiator WWN. naa.600140554cf3a18e is
> the
> > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > >
> > > > > Paolo
> > > >
> > >
> > > --
> > > Asias
>
> --
> Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-06-21 10:16 ` Libaiqing
@ 2013-07-03 3:08 ` Libaiqing
2013-07-03 3:18 ` Asias He
2013-07-03 3:23 ` Asias He
1 sibling, 1 reply; 56+ messages in thread
From: Libaiqing @ 2013-07-03 3:08 UTC (permalink / raw)
To: Asias He; +Cc: qemu-devel@nongnu.org, Haofeng
Hi asias,
I'm testing vhost-blk,for comparimg the performance with virtio-blk.
I got the kernel patch from this mail: https://lkml.org/lkml/2012/12/1/174
And I got the userspace code for qemu from this git: https://github.com/asias/qemu/tree/blk.vhost-blk;
Used vhost-blk device as non-bootable device,the configuration is :
Qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/home/fedora188.img,if=virtio,index=0,format=raw -drive file=/home/fedora18.img,if=virtio,index=1,format=raw,id=hd,vhost=on -monitor stdio -vga qxl -vnc :1 -device usb-tablet,id=input0
On fedora17 host,I used kernel 3.6.3 for building vhos_blk module,but the vm will hang when vm starting.
1 Is there any new patch for kernel 3.8 3.10?
2 which version of the kernel is suitable for the current kernel patch?
Could you give me some advise to debug this problem ? I can provide more information if need.
Or could you give me some advise to run vhost-blk,such as RHEL version,kernel version and so on?
Thanks
Baiqing.
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-03 3:08 ` Libaiqing
@ 2013-07-03 3:18 ` Asias He
0 siblings, 0 replies; 56+ messages in thread
From: Asias He @ 2013-07-03 3:18 UTC (permalink / raw)
To: Libaiqing; +Cc: qemu-devel@nongnu.org, Haofeng
On Wed, Jul 03, 2013 at 03:08:34AM +0000, Libaiqing wrote:
> Hi asias,
> I'm testing vhost-blk,for comparimg the performance with virtio-blk.
> I got the kernel patch from this mail: https://lkml.org/lkml/2012/12/1/174
You can find the latest vhost-blk kernel bits here:
git://github.com/asias/linux.git blk.vhost-blk
> And I got the userspace code for qemu from this git: https://github.com/asias/qemu/tree/blk.vhost-blk;
> Used vhost-blk device as non-bootable device,the configuration is :
> Qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/home/fedora188.img,if=virtio,index=0,format=raw -drive file=/home/fedora18.img,if=virtio,index=1,format=raw,id=hd,vhost=on -monitor stdio -vga qxl -vnc :1 -device usb-tablet,id=input0
Please use raw block device for vhost-blk.
> On fedora17 host,I used kernel 3.6.3 for building vhos_blk module,but the vm will hang when vm starting.
>
> 1 Is there any new patch for kernel 3.8 3.10?
> 2 which version of the kernel is suitable for the current kernel patch?
>
> Could you give me some advise to debug this problem ? I can provide more information if need.
> Or could you give me some advise to run vhost-blk,such as RHEL version,kernel version and so on?
I recommend you to use the kernel I provided above for both guest and
host.
> Thanks
> Baiqing.
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-06-21 10:16 ` Libaiqing
2013-07-03 3:08 ` Libaiqing
@ 2013-07-03 3:23 ` Asias He
2013-07-03 8:08 ` Asias He
1 sibling, 1 reply; 56+ messages in thread
From: Asias He @ 2013-07-03 3:23 UTC (permalink / raw)
To: Libaiqing
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
On Fri, Jun 21, 2013 at 10:16:48AM +0000, Libaiqing wrote:
> Hi Asias,
>
> > -----Original Message-----
> > From: Asias He [mailto:asias@redhat.com]
> > Sent: Thursday, June 20, 2013 5:39 PM
> > To: Libaiqing
> > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> > tcm_vhost Linux kernel module
> >
> > On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > > Hi Asias,
> > > Thanks for your config.
> > > According to you config,I test booting from vhost device with
> > upstream kernel and qemu,but failed.
> > >
> > > 1 installing guest from cdrom,ok.
> > > 2 booting vhost-scsi,guest fs error occurs.
> > > 3 using fileio backstores,the error is same..
> > > 4 rebooting guest,a log printed:
> > > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object
> > 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
> >
> > Paolo, I remember you fixed a similar issue?
> >
> > > 5 using upstream seabios,core dumped.
> > >
> > > Could you give me some advise to debug this problem ? I can provide
> > more information if need.
> >
> > Can you show me qemu commit id you used? Can you verity that if using the
> > host kernel for guest helps? Does booting directly (without the install
> > and reboot process) work?
> Qemu commit id is "commit 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
>
> Guest kernel updateing is useless.
>
> Booting directly doesn't work too.
Hello Libaiqing,
Sorry for the delay. I will try to reproduce it myself.
>
> > > The qemu cmd:
> > > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm
> > -name fedora -M pc -m 1024 -smp 2 -drive
> > file=/home/fedora18.iso,if=ide,media=cdrom -device
> > vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga qxl
> > -vnc :1
> > >
> > > The vnc output:
> > > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> > INCONSISTENCY;RUN FSCK MANUALLY.
> > > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> > system check.
> > >
> > > The guest kernel log:
> > > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > > Kernel: scsi2 : Virtio SCSI HBA
> > > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > > Kernel: sd 2:0:1:0: [sda]write protect is off
> > > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > > Kernel: sda sda1 sda2
> > > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> > >
> > > The info of host:
> > > [root@fedora121 x86_64-softmmu]# uname -a
> > > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64
> > x86_64 x86_64 GNU/Linux
> > > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > > vhost_scsi 49456 5
> > > target_core_mod 282163 14
> > target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> > ost_scsi
> > > [root@fedora121 x86_64-softmmu]# targetcli
> > > targetcli shell version v2.1.fb26
> > > Copyright 2011 by RisingTide Systems LLC and others.
> > > For help on commands, type 'help'.
> > >
> > > /> ls
> > > o-
> > / ..............................................................................................................
> > ........... [...]
> > > o-
> > backstores ...............................................................................................
> > ............... [...]
> > > | o-
> > block ..................................................................................................
> > [Storage Objects: 0]
> > > | o-
> > fileio .................................................................................................
> > [Storage Objects: 0]
> > > | o-
> > pscsi ..................................................................................................
> > [Storage Objects: 0]
> > > | o-
> > ramdisk ................................................................................................
> > [Storage Objects: 1]
> > > | o-
> > r0 ...................................................................................................
> > [(6.0GiB) activated]
> > > o-
> > iscsi .........................................................................................................
> > ... [Targets: 0]
> > > o-
> > loopback ..................................................................................................
> > ....... [Targets: 0]
> > > o-
> > vhost .......................................................................................................
> > ..... [Targets: 1]
> > > o-
> > naa.50014057133e25dc ............................................................................
> > .................. [TPGs: 1]
> > > o-
> > tpg1 ...............................................................................................
> > [naa.5001405a70ac3421]
> > > o-
> > acls ..........................................................................................................
> > [ACLs: 0]
> > > o-
> > luns ..........................................................................................................
> > [LUNs: 1]
> > > o-
> > lun0 .....................................................................................................
> > [ramdisk/r0]
> > >
> > > Regards,
> > > baiqing
> > > > -----Original Message-----
> > > > From: Asias He [mailto:asias@redhat.com]
> > > > Sent: Thursday, June 20, 2013 9:34 AM
> > > > To: Libaiqing
> > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting
> > the
> > > > tcm_vhost Linux kernel module
> > > >
> > > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > > Hi paolo,
> > > > > The vhost-scsi device can be used as boot device?
> > > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > > Could you give me some advise to debug this problem ? I can
> > provide
> > > > more information if need.
> > > >
> > > > Boot from vhost-scsi is supposed to work. The seabios you used should
> > be
> > > > fine which contains the fixes for vhost-scsi.
> > > >
> > > > Instead of playing with the /sys/kernel/config/target directly, I really
> > > > recommend using targetcli utils.
> > > >
> > > > Nab, I think we really should write some docs for people to use
> > > > vhost-scsi.
> > > >
> > > > This is how I install and use targetcli in RHEL6. Note you need upstream
> > > > kernel and qemu bits for vhost-scsi.
> > > >
> > > > # yum groupinstall 'Development tools'
> > > > # yum install python-devel epydoc python-simpleparse
> > > >
> > > > # git clone git://github.com/agrover/rtslib-fb.git
> > > > # git clone git://github.com/agrover/targetcli-fb.git
> > > > # git clone git://github.com/agrover/configshell-fb.git
> > > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > > make -C $i rpm
> > > > yum localinstall $i/dist/*.noarch.rpm
> > > > done
> > > >
> > > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > > # targetcli
> > > > /> /backstores/ramdisk create r0 1g
> > > > /> /vhost create
> > > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > > /> create /backstores/ramdisk/r0
> > > >
> > > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > > >
> > > > Hope this helps.
> > > >
> > > > > Regards,
> > > > > baiqing
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> > On
> > > > > > Behalf Of Paolo Bonzini
> > > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > > To: Wenchao Xia
> > > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> > nab@linux-iscsi.org;
> > > > > > Michael S. Tsirkin
> > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > supporting
> > > > the
> > > > > > tcm_vhost Linux kernel module
> > > > > >
> > > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > > >> >
> > > > > > >> > The WWPN specified in configfs is passed to "-device
> > > > vhost-scsi-pci".
> > > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
> > not
> > > > > > >> > available from the QEMU command-line. Instead, I hardcode it
> > to
> > > > > > zero.
> > > > > > >> >
> > > > > > > Hi, Paolo
> > > > > > > Any document about how to config it correctly in configfs,
> > before
> > > > > > > invoking qemu with the WWPN number?
> > > > > >
> > > > > > Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> > > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > > >
> > > > > > cd /sys/kernel/config/target
> > > > > > mkdir -p core/fileio_0/fileio
> > > > > > echo
> > > > 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > > core/fileio_0/fileio/control
> > > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > > ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> > > > > > echo naa.60014053226f0388 > nexus
> > > > > >
> > > > > > The "nexus" value is the initiator WWN. naa.600140554cf3a18e is
> > the
> > > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > > >
> > > > > > Paolo
> > > > >
> > > >
> > > > --
> > > > Asias
> >
> > --
> > Asias
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-03 3:23 ` Asias He
@ 2013-07-03 8:08 ` Asias He
2013-07-03 12:33 ` Libaiqing
2013-07-04 7:00 ` Libaiqing
0 siblings, 2 replies; 56+ messages in thread
From: Asias He @ 2013-07-03 8:08 UTC (permalink / raw)
To: Libaiqing
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
> On Fri, Jun 21, 2013 at 10:16:48AM +0000, Libaiqing wrote:
> > Hi Asias,
> >
> > > -----Original Message-----
> > > From: Asias He [mailto:asias@redhat.com]
> > > Sent: Thursday, June 20, 2013 5:39 PM
> > > To: Libaiqing
> > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> > > tcm_vhost Linux kernel module
> > >
> > > On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > > > Hi Asias,
> > > > Thanks for your config.
> > > > According to you config,I test booting from vhost device with
> > > upstream kernel and qemu,but failed.
> > > >
> > > > 1 installing guest from cdrom,ok.
> > > > 2 booting vhost-scsi,guest fs error occurs.
> > > > 3 using fileio backstores,the error is same..
> > > > 4 rebooting guest,a log printed:
> > > > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object
> > > 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
> > >
> > > Paolo, I remember you fixed a similar issue?
> > >
> > > > 5 using upstream seabios,core dumped.
> > > >
> > > > Could you give me some advise to debug this problem ? I can provide
> > > more information if need.
> > >
> > > Can you show me qemu commit id you used? Can you verity that if using the
> > > host kernel for guest helps? Does booting directly (without the install
> > > and reboot process) work?
> > Qemu commit id is "commit 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> >
> > Guest kernel updateing is useless.
> >
> > Booting directly doesn't work too.
>
>
> Hello Libaiqing,
>
> Sorry for the delay. I will try to reproduce it myself.
I tried 1.5.1 and qemu.git/master and your particular commit
4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
All work well for me. I used 3.10.0-rc6 as both and guest kernel.
>
> >
> > > > The qemu cmd:
> > > > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm
> > > -name fedora -M pc -m 1024 -smp 2 -drive
> > > file=/home/fedora18.iso,if=ide,media=cdrom -device
> > > vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga qxl
> > > -vnc :1
> > > >
> > > > The vnc output:
> > > > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> > > INCONSISTENCY;RUN FSCK MANUALLY.
> > > > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > > > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> > > system check.
> > > >
> > > > The guest kernel log:
> > > > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > > > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > > > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > > > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > > > Kernel: scsi2 : Virtio SCSI HBA
> > > > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > > > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > > > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > > > Kernel: sd 2:0:1:0: [sda]write protect is off
> > > > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > > > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > > > Kernel: sda sda1 sda2
> > > > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > > > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > > > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > > > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> > > >
> > > > The info of host:
> > > > [root@fedora121 x86_64-softmmu]# uname -a
> > > > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64
> > > x86_64 x86_64 GNU/Linux
> > > > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > > > vhost_scsi 49456 5
> > > > target_core_mod 282163 14
> > > target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> > > ost_scsi
> > > > [root@fedora121 x86_64-softmmu]# targetcli
> > > > targetcli shell version v2.1.fb26
> > > > Copyright 2011 by RisingTide Systems LLC and others.
> > > > For help on commands, type 'help'.
> > > >
> > > > /> ls
> > > > o-
> > > / ..............................................................................................................
> > > ........... [...]
> > > > o-
> > > backstores ...............................................................................................
> > > ............... [...]
> > > > | o-
> > > block ..................................................................................................
> > > [Storage Objects: 0]
> > > > | o-
> > > fileio .................................................................................................
> > > [Storage Objects: 0]
> > > > | o-
> > > pscsi ..................................................................................................
> > > [Storage Objects: 0]
> > > > | o-
> > > ramdisk ................................................................................................
> > > [Storage Objects: 1]
> > > > | o-
> > > r0 ...................................................................................................
> > > [(6.0GiB) activated]
> > > > o-
> > > iscsi .........................................................................................................
> > > ... [Targets: 0]
> > > > o-
> > > loopback ..................................................................................................
> > > ....... [Targets: 0]
> > > > o-
> > > vhost .......................................................................................................
> > > ..... [Targets: 1]
> > > > o-
> > > naa.50014057133e25dc ............................................................................
> > > .................. [TPGs: 1]
> > > > o-
> > > tpg1 ...............................................................................................
> > > [naa.5001405a70ac3421]
> > > > o-
> > > acls ..........................................................................................................
> > > [ACLs: 0]
> > > > o-
> > > luns ..........................................................................................................
> > > [LUNs: 1]
> > > > o-
> > > lun0 .....................................................................................................
> > > [ramdisk/r0]
> > > >
> > > > Regards,
> > > > baiqing
> > > > > -----Original Message-----
> > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > Sent: Thursday, June 20, 2013 9:34 AM
> > > > > To: Libaiqing
> > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting
> > > the
> > > > > tcm_vhost Linux kernel module
> > > > >
> > > > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > > > Hi paolo,
> > > > > > The vhost-scsi device can be used as boot device?
> > > > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > > > Could you give me some advise to debug this problem ? I can
> > > provide
> > > > > more information if need.
> > > > >
> > > > > Boot from vhost-scsi is supposed to work. The seabios you used should
> > > be
> > > > > fine which contains the fixes for vhost-scsi.
> > > > >
> > > > > Instead of playing with the /sys/kernel/config/target directly, I really
> > > > > recommend using targetcli utils.
> > > > >
> > > > > Nab, I think we really should write some docs for people to use
> > > > > vhost-scsi.
> > > > >
> > > > > This is how I install and use targetcli in RHEL6. Note you need upstream
> > > > > kernel and qemu bits for vhost-scsi.
> > > > >
> > > > > # yum groupinstall 'Development tools'
> > > > > # yum install python-devel epydoc python-simpleparse
> > > > >
> > > > > # git clone git://github.com/agrover/rtslib-fb.git
> > > > > # git clone git://github.com/agrover/targetcli-fb.git
> > > > > # git clone git://github.com/agrover/configshell-fb.git
> > > > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > > > make -C $i rpm
> > > > > yum localinstall $i/dist/*.noarch.rpm
> > > > > done
> > > > >
> > > > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > > > # targetcli
> > > > > /> /backstores/ramdisk create r0 1g
> > > > > /> /vhost create
> > > > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > > > /> create /backstores/ramdisk/r0
> > > > >
> > > > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > > > >
> > > > > Hope this helps.
> > > > >
> > > > > > Regards,
> > > > > > baiqing
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > > > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> > > On
> > > > > > > Behalf Of Paolo Bonzini
> > > > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > > > To: Wenchao Xia
> > > > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> > > nab@linux-iscsi.org;
> > > > > > > Michael S. Tsirkin
> > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > supporting
> > > > > the
> > > > > > > tcm_vhost Linux kernel module
> > > > > > >
> > > > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > > > >> >
> > > > > > > >> > The WWPN specified in configfs is passed to "-device
> > > > > vhost-scsi-pci".
> > > > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
> > > not
> > > > > > > >> > available from the QEMU command-line. Instead, I hardcode it
> > > to
> > > > > > > zero.
> > > > > > > >> >
> > > > > > > > Hi, Paolo
> > > > > > > > Any document about how to config it correctly in configfs,
> > > before
> > > > > > > > invoking qemu with the WWPN number?
> > > > > > >
> > > > > > > Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> > > > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > > > >
> > > > > > > cd /sys/kernel/config/target
> > > > > > > mkdir -p core/fileio_0/fileio
> > > > > > > echo
> > > > > 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > > > core/fileio_0/fileio/control
> > > > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > > > ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> > > > > > > echo naa.60014053226f0388 > nexus
> > > > > > >
> > > > > > > The "nexus" value is the initiator WWN. naa.600140554cf3a18e is
> > > the
> > > > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > > > >
> > > > > > > Paolo
> > > > > >
> > > > >
> > > > > --
> > > > > Asias
> > >
> > > --
> > > Asias
>
> --
> Asias
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-03 8:08 ` Asias He
@ 2013-07-03 12:33 ` Libaiqing
2013-07-04 11:23 ` Paolo Bonzini
2013-07-04 7:00 ` Libaiqing
1 sibling, 1 reply; 56+ messages in thread
From: Libaiqing @ 2013-07-03 12:33 UTC (permalink / raw)
To: Asias He
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
Hi asias,
I got the rootcause:guest was installed on raw img with lvm partition,which vhost does not support.
Now vhost-scsi can be used as bootable device.
Thanks
baiqing
> -----Original Message-----
> From: Asias He [mailto:asias@redhat.com]
> Sent: Wednesday, July 03, 2013 4:09 PM
> To: Libaiqing
> Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> tcm_vhost Linux kernel module
>
> On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
> > On Fri, Jun 21, 2013 at 10:16:48AM +0000, Libaiqing wrote:
> > > Hi Asias,
> > >
> > > > -----Original Message-----
> > > > From: Asias He [mailto:asias@redhat.com]
> > > > Sent: Thursday, June 20, 2013 5:39 PM
> > > > To: Libaiqing
> > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> supporting the
> > > > tcm_vhost Linux kernel module
> > > >
> > > > On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > > > > Hi Asias,
> > > > > Thanks for your config.
> > > > > According to you config,I test booting from vhost device with
> > > > upstream kernel and qemu,but failed.
> > > > >
> > > > > 1 installing guest from cdrom,ok.
> > > > > 2 booting vhost-scsi,guest fs error occurs.
> > > > > 3 using fileio backstores,the error is same..
> > > > > 4 rebooting guest,a log printed:
> > > > > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
> Object
> > > > 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
> > > >
> > > > Paolo, I remember you fixed a similar issue?
> > > >
> > > > > 5 using upstream seabios,core dumped.
> > > > >
> > > > > Could you give me some advise to debug this problem ? I can
> provide
> > > > more information if need.
> > > >
> > > > Can you show me qemu commit id you used? Can you verity that if
> using the
> > > > host kernel for guest helps? Does booting directly (without the install
> > > > and reboot process) work?
> > > Qemu commit id is "commit
> 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> > >
> > > Guest kernel updateing is useless.
> > >
> > > Booting directly doesn't work too.
> >
> >
> > Hello Libaiqing,
> >
> > Sorry for the delay. I will try to reproduce it myself.
>
> I tried 1.5.1 and qemu.git/master and your particular commit
> 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
>
> All work well for me. I used 3.10.0-rc6 as both and guest kernel.
>
> >
> > >
> > > > > The qemu cmd:
> > > > > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
> -enable-kvm
> > > > -name fedora -M pc -m 1024 -smp 2 -drive
> > > > file=/home/fedora18.iso,if=ide,media=cdrom -device
> > > > vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga
> qxl
> > > > -vnc :1
> > > > >
> > > > > The vnc output:
> > > > > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> > > > INCONSISTENCY;RUN FSCK MANUALLY.
> > > > > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > > > > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> > > > system check.
> > > > >
> > > > > The guest kernel log:
> > > > > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > > > > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > > > > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > > > > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > > > > Kernel: scsi2 : Virtio SCSI HBA
> > > > > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > > > > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > > > > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > > > > Kernel: sd 2:0:1:0: [sda]write protect is off
> > > > > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > > > > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > > > > Kernel: sda sda1 sda2
> > > > > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > > > > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > > > > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > > > > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> > > > >
> > > > > The info of host:
> > > > > [root@fedora121 x86_64-softmmu]# uname -a
> > > > > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013
> x86_64
> > > > x86_64 x86_64 GNU/Linux
> > > > > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > > > > vhost_scsi 49456 5
> > > > > target_core_mod 282163 14
> > > >
> target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> > > > ost_scsi
> > > > > [root@fedora121 x86_64-softmmu]# targetcli
> > > > > targetcli shell version v2.1.fb26
> > > > > Copyright 2011 by RisingTide Systems LLC and others.
> > > > > For help on commands, type 'help'.
> > > > >
> > > > > /> ls
> > > > > o-
> > > >
> / ..............................................................................................................
> > > > ........... [...]
> > > > > o-
> > > >
> backstores ...............................................................................................
> > > > ............... [...]
> > > > > | o-
> > > >
> block ..................................................................................................
> > > > [Storage Objects: 0]
> > > > > | o-
> > > >
> fileio .................................................................................................
> > > > [Storage Objects: 0]
> > > > > | o-
> > > >
> pscsi ..................................................................................................
> > > > [Storage Objects: 0]
> > > > > | o-
> > > >
> ramdisk ................................................................................................
> > > > [Storage Objects: 1]
> > > > > | o-
> > > > r0 ...................................................................................................
> > > > [(6.0GiB) activated]
> > > > > o-
> > > >
> iscsi .........................................................................................................
> > > > ... [Targets: 0]
> > > > > o-
> > > >
> loopback ..................................................................................................
> > > > ....... [Targets: 0]
> > > > > o-
> > > >
> vhost .......................................................................................................
> > > > ..... [Targets: 1]
> > > > > o-
> > > >
> naa.50014057133e25dc ............................................................................
> > > > .................. [TPGs: 1]
> > > > > o-
> > > > tpg1 ...............................................................................................
> > > > [naa.5001405a70ac3421]
> > > > > o-
> > > >
> acls .........................................................................................................
> .
> > > > [ACLs: 0]
> > > > > o-
> > > >
> luns .........................................................................................................
> .
> > > > [LUNs: 1]
> > > > > o-
> > > >
> lun0 .....................................................................................................
> > > > [ramdisk/r0]
> > > > >
> > > > > Regards,
> > > > > baiqing
> > > > > > -----Original Message-----
> > > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > > Sent: Thursday, June 20, 2013 9:34 AM
> > > > > > To: Libaiqing
> > > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> supporting
> > > > the
> > > > > > tcm_vhost Linux kernel module
> > > > > >
> > > > > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > > > > Hi paolo,
> > > > > > > The vhost-scsi device can be used as boot device?
> > > > > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > > > > Could you give me some advise to debug this problem ? I can
> > > > provide
> > > > > > more information if need.
> > > > > >
> > > > > > Boot from vhost-scsi is supposed to work. The seabios you used
> should
> > > > be
> > > > > > fine which contains the fixes for vhost-scsi.
> > > > > >
> > > > > > Instead of playing with the /sys/kernel/config/target directly, I
> really
> > > > > > recommend using targetcli utils.
> > > > > >
> > > > > > Nab, I think we really should write some docs for people to use
> > > > > > vhost-scsi.
> > > > > >
> > > > > > This is how I install and use targetcli in RHEL6. Note you need
> upstream
> > > > > > kernel and qemu bits for vhost-scsi.
> > > > > >
> > > > > > # yum groupinstall 'Development tools'
> > > > > > # yum install python-devel epydoc python-simpleparse
> > > > > >
> > > > > > # git clone git://github.com/agrover/rtslib-fb.git
> > > > > > # git clone git://github.com/agrover/targetcli-fb.git
> > > > > > # git clone git://github.com/agrover/configshell-fb.git
> > > > > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > > > > make -C $i rpm
> > > > > > yum localinstall $i/dist/*.noarch.rpm
> > > > > > done
> > > > > >
> > > > > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > > > > # targetcli
> > > > > > /> /backstores/ramdisk create r0 1g
> > > > > > /> /vhost create
> > > > > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > > > > /> create /backstores/ramdisk/r0
> > > > > >
> > > > > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > > > > >
> > > > > > Hope this helps.
> > > > > >
> > > > > > > Regards,
> > > > > > > baiqing
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > > > >
> [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> > > > On
> > > > > > > > Behalf Of Paolo Bonzini
> > > > > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > > > > To: Wenchao Xia
> > > > > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> > > > nab@linux-iscsi.org;
> > > > > > > > Michael S. Tsirkin
> > > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > > supporting
> > > > > > the
> > > > > > > > tcm_vhost Linux kernel module
> > > > > > > >
> > > > > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > > > > >> >
> > > > > > > > >> > The WWPN specified in configfs is passed to "-device
> > > > > > vhost-scsi-pci".
> > > > > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now,
> so it is
> > > > not
> > > > > > > > >> > available from the QEMU command-line. Instead, I
> hardcode it
> > > > to
> > > > > > > > zero.
> > > > > > > > >> >
> > > > > > > > > Hi, Paolo
> > > > > > > > > Any document about how to config it correctly in configfs,
> > > > before
> > > > > > > > > invoking qemu with the WWPN number?
> > > > > > > >
> > > > > > > > Unfortunately no, but vhost-scsi doesn't have many knobs
> (unlike
> > > > > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > > > > >
> > > > > > > > cd /sys/kernel/config/target
> > > > > > > > mkdir -p core/fileio_0/fileio
> > > > > > > > echo
> > > > > >
> 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > > > > core/fileio_0/fileio/control
> > > > > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > > > > ln -sf ../../../../../core/fileio_0/fileio/
> lun/lun_0/virtual_scsi_port
> > > > > > > > echo naa.60014053226f0388 > nexus
> > > > > > > >
> > > > > > > > The "nexus" value is the initiator WWN.
> naa.600140554cf3a18e is
> > > > the
> > > > > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > > > > >
> > > > > > > > Paolo
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Asias
> > > >
> > > > --
> > > > Asias
> >
> > --
> > Asias
>
> --
> Asias
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-03 12:33 ` Libaiqing
@ 2013-07-04 11:23 ` Paolo Bonzini
2013-07-08 0:59 ` Libaiqing
0 siblings, 1 reply; 56+ messages in thread
From: Paolo Bonzini @ 2013-07-04 11:23 UTC (permalink / raw)
To: Libaiqing
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Asias He, Wenchao Xia
Il 03/07/2013 14:33, Libaiqing ha scritto:
> Hi asias,
> I got the rootcause:guest was installed on raw img with lvm partition,which vhost does not support.
You mean LVM in the host or the guest? I guess in the host, but I'd
rather make sure because otherwise you've found a bug.
Paolo
> Now vhost-scsi can be used as bootable device.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-04 11:23 ` Paolo Bonzini
@ 2013-07-08 0:59 ` Libaiqing
0 siblings, 0 replies; 56+ messages in thread
From: Libaiqing @ 2013-07-08 0:59 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Asias He, Wenchao Xia
Hi paolo,
Sorry for the late reply.
LVM partition is in guest.So when booting for vhost-scsi,the guest always reports the fs is broken,and enters the emergency mode.
I can provide more information if need.
Thanks
Baiqing.
> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Thursday, July 04, 2013 7:24 PM
> To: Libaiqing
> Cc: Asias He; Wenchao Xia; qemu-devel@nongnu.org; nab@linux-iscsi.org;
> Michael S. Tsirkin; Haofeng
> Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> tcm_vhost Linux kernel module
>
> Il 03/07/2013 14:33, Libaiqing ha scritto:
> > Hi asias,
> > I got the rootcause:guest was installed on raw img with lvm
> partition,which vhost does not support.
>
> You mean LVM in the host or the guest? I guess in the host, but I'd
> rather make sure because otherwise you've found a bug.
>
> Paolo
>
> > Now vhost-scsi can be used as bootable device.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-03 8:08 ` Asias He
2013-07-03 12:33 ` Libaiqing
@ 2013-07-04 7:00 ` Libaiqing
2013-07-05 0:00 ` Asias He
2013-07-05 6:52 ` Asias He
1 sibling, 2 replies; 56+ messages in thread
From: Libaiqing @ 2013-07-04 7:00 UTC (permalink / raw)
To: Asias He
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
Hi asias,
1 Window can not boot from vhost-scsi device;
2 A non-bootable vhost-scsi device can not be driven by windows guest.(I used the driver virtio-win-0.1-59 version.)
Do you have any plan about these?
Thanks,
Baiqing.
> -----Original Message-----
> From: Asias He [mailto:asias@redhat.com]
> Sent: Wednesday, July 03, 2013 4:09 PM
> To: Libaiqing
> Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> tcm_vhost Linux kernel module
>
> On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
> > On Fri, Jun 21, 2013 at 10:16:48AM +0000, Libaiqing wrote:
> > > Hi Asias,
> > >
> > > > -----Original Message-----
> > > > From: Asias He [mailto:asias@redhat.com]
> > > > Sent: Thursday, June 20, 2013 5:39 PM
> > > > To: Libaiqing
> > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> supporting the
> > > > tcm_vhost Linux kernel module
> > > >
> > > > On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > > > > Hi Asias,
> > > > > Thanks for your config.
> > > > > According to you config,I test booting from vhost device with
> > > > upstream kernel and qemu,but failed.
> > > > >
> > > > > 1 installing guest from cdrom,ok.
> > > > > 2 booting vhost-scsi,guest fs error occurs.
> > > > > 3 using fileio backstores,the error is same..
> > > > > 4 rebooting guest,a log printed:
> > > > > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
> Object
> > > > 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
> > > >
> > > > Paolo, I remember you fixed a similar issue?
> > > >
> > > > > 5 using upstream seabios,core dumped.
> > > > >
> > > > > Could you give me some advise to debug this problem ? I can
> provide
> > > > more information if need.
> > > >
> > > > Can you show me qemu commit id you used? Can you verity that if
> using the
> > > > host kernel for guest helps? Does booting directly (without the install
> > > > and reboot process) work?
> > > Qemu commit id is "commit
> 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> > >
> > > Guest kernel updateing is useless.
> > >
> > > Booting directly doesn't work too.
> >
> >
> > Hello Libaiqing,
> >
> > Sorry for the delay. I will try to reproduce it myself.
>
> I tried 1.5.1 and qemu.git/master and your particular commit
> 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
>
> All work well for me. I used 3.10.0-rc6 as both and guest kernel.
>
> >
> > >
> > > > > The qemu cmd:
> > > > > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
> -enable-kvm
> > > > -name fedora -M pc -m 1024 -smp 2 -drive
> > > > file=/home/fedora18.iso,if=ide,media=cdrom -device
> > > > vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga
> qxl
> > > > -vnc :1
> > > > >
> > > > > The vnc output:
> > > > > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> > > > INCONSISTENCY;RUN FSCK MANUALLY.
> > > > > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > > > > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> > > > system check.
> > > > >
> > > > > The guest kernel log:
> > > > > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > > > > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > > > > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > > > > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > > > > Kernel: scsi2 : Virtio SCSI HBA
> > > > > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > > > > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > > > > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > > > > Kernel: sd 2:0:1:0: [sda]write protect is off
> > > > > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > > > > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > > > > Kernel: sda sda1 sda2
> > > > > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > > > > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > > > > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > > > > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> > > > >
> > > > > The info of host:
> > > > > [root@fedora121 x86_64-softmmu]# uname -a
> > > > > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013
> x86_64
> > > > x86_64 x86_64 GNU/Linux
> > > > > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > > > > vhost_scsi 49456 5
> > > > > target_core_mod 282163 14
> > > >
> target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> > > > ost_scsi
> > > > > [root@fedora121 x86_64-softmmu]# targetcli
> > > > > targetcli shell version v2.1.fb26
> > > > > Copyright 2011 by RisingTide Systems LLC and others.
> > > > > For help on commands, type 'help'.
> > > > >
> > > > > /> ls
> > > > > o-
> > > >
> / ..............................................................................................................
> > > > ........... [...]
> > > > > o-
> > > >
> backstores ...............................................................................................
> > > > ............... [...]
> > > > > | o-
> > > >
> block ..................................................................................................
> > > > [Storage Objects: 0]
> > > > > | o-
> > > >
> fileio .................................................................................................
> > > > [Storage Objects: 0]
> > > > > | o-
> > > >
> pscsi ..................................................................................................
> > > > [Storage Objects: 0]
> > > > > | o-
> > > >
> ramdisk ................................................................................................
> > > > [Storage Objects: 1]
> > > > > | o-
> > > > r0 ...................................................................................................
> > > > [(6.0GiB) activated]
> > > > > o-
> > > >
> iscsi .........................................................................................................
> > > > ... [Targets: 0]
> > > > > o-
> > > >
> loopback ..................................................................................................
> > > > ....... [Targets: 0]
> > > > > o-
> > > >
> vhost .......................................................................................................
> > > > ..... [Targets: 1]
> > > > > o-
> > > >
> naa.50014057133e25dc ............................................................................
> > > > .................. [TPGs: 1]
> > > > > o-
> > > > tpg1 ...............................................................................................
> > > > [naa.5001405a70ac3421]
> > > > > o-
> > > >
> acls .........................................................................................................
> .
> > > > [ACLs: 0]
> > > > > o-
> > > >
> luns .........................................................................................................
> .
> > > > [LUNs: 1]
> > > > > o-
> > > >
> lun0 .....................................................................................................
> > > > [ramdisk/r0]
> > > > >
> > > > > Regards,
> > > > > baiqing
> > > > > > -----Original Message-----
> > > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > > Sent: Thursday, June 20, 2013 9:34 AM
> > > > > > To: Libaiqing
> > > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> supporting
> > > > the
> > > > > > tcm_vhost Linux kernel module
> > > > > >
> > > > > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > > > > Hi paolo,
> > > > > > > The vhost-scsi device can be used as boot device?
> > > > > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > > > > Could you give me some advise to debug this problem ? I can
> > > > provide
> > > > > > more information if need.
> > > > > >
> > > > > > Boot from vhost-scsi is supposed to work. The seabios you used
> should
> > > > be
> > > > > > fine which contains the fixes for vhost-scsi.
> > > > > >
> > > > > > Instead of playing with the /sys/kernel/config/target directly, I
> really
> > > > > > recommend using targetcli utils.
> > > > > >
> > > > > > Nab, I think we really should write some docs for people to use
> > > > > > vhost-scsi.
> > > > > >
> > > > > > This is how I install and use targetcli in RHEL6. Note you need
> upstream
> > > > > > kernel and qemu bits for vhost-scsi.
> > > > > >
> > > > > > # yum groupinstall 'Development tools'
> > > > > > # yum install python-devel epydoc python-simpleparse
> > > > > >
> > > > > > # git clone git://github.com/agrover/rtslib-fb.git
> > > > > > # git clone git://github.com/agrover/targetcli-fb.git
> > > > > > # git clone git://github.com/agrover/configshell-fb.git
> > > > > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > > > > make -C $i rpm
> > > > > > yum localinstall $i/dist/*.noarch.rpm
> > > > > > done
> > > > > >
> > > > > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > > > > # targetcli
> > > > > > /> /backstores/ramdisk create r0 1g
> > > > > > /> /vhost create
> > > > > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > > > > /> create /backstores/ramdisk/r0
> > > > > >
> > > > > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > > > > >
> > > > > > Hope this helps.
> > > > > >
> > > > > > > Regards,
> > > > > > > baiqing
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > > > >
> [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> > > > On
> > > > > > > > Behalf Of Paolo Bonzini
> > > > > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > > > > To: Wenchao Xia
> > > > > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> > > > nab@linux-iscsi.org;
> > > > > > > > Michael S. Tsirkin
> > > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > > supporting
> > > > > > the
> > > > > > > > tcm_vhost Linux kernel module
> > > > > > > >
> > > > > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > > > > >> >
> > > > > > > > >> > The WWPN specified in configfs is passed to "-device
> > > > > > vhost-scsi-pci".
> > > > > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now,
> so it is
> > > > not
> > > > > > > > >> > available from the QEMU command-line. Instead, I
> hardcode it
> > > > to
> > > > > > > > zero.
> > > > > > > > >> >
> > > > > > > > > Hi, Paolo
> > > > > > > > > Any document about how to config it correctly in configfs,
> > > > before
> > > > > > > > > invoking qemu with the WWPN number?
> > > > > > > >
> > > > > > > > Unfortunately no, but vhost-scsi doesn't have many knobs
> (unlike
> > > > > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > > > > >
> > > > > > > > cd /sys/kernel/config/target
> > > > > > > > mkdir -p core/fileio_0/fileio
> > > > > > > > echo
> > > > > >
> 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > > > > core/fileio_0/fileio/control
> > > > > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > > > > ln -sf ../../../../../core/fileio_0/fileio/
> lun/lun_0/virtual_scsi_port
> > > > > > > > echo naa.60014053226f0388 > nexus
> > > > > > > >
> > > > > > > > The "nexus" value is the initiator WWN.
> naa.600140554cf3a18e is
> > > > the
> > > > > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > > > > >
> > > > > > > > Paolo
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Asias
> > > >
> > > > --
> > > > Asias
> >
> > --
> > Asias
>
> --
> Asias
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-04 7:00 ` Libaiqing
@ 2013-07-05 0:00 ` Asias He
2013-07-05 6:52 ` Asias He
1 sibling, 0 replies; 56+ messages in thread
From: Asias He @ 2013-07-05 0:00 UTC (permalink / raw)
To: Libaiqing
Cc: Michael S. Tsirkin, qemu-devel@nongnu.org, nab@linux-iscsi.org,
Haofeng, Paolo Bonzini, Wenchao Xia
On Thu, Jul 04, 2013 at 07:00:49AM +0000, Libaiqing wrote:
> Hi asias,
> 1 Window can not boot from vhost-scsi device;
> 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I used the driver virtio-win-0.1-59 version.)
>
> Do you have any plan about these?
Thanks for testing. I will take a look.
>
> Thanks,
> Baiqing.
> > -----Original Message-----
> > From: Asias He [mailto:asias@redhat.com]
> > Sent: Wednesday, July 03, 2013 4:09 PM
> > To: Libaiqing
> > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> > tcm_vhost Linux kernel module
> >
> > On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
> > > On Fri, Jun 21, 2013 at 10:16:48AM +0000, Libaiqing wrote:
> > > > Hi Asias,
> > > >
> > > > > -----Original Message-----
> > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > Sent: Thursday, June 20, 2013 5:39 PM
> > > > > To: Libaiqing
> > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > supporting the
> > > > > tcm_vhost Linux kernel module
> > > > >
> > > > > On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > > > > > Hi Asias,
> > > > > > Thanks for your config.
> > > > > > According to you config,I test booting from vhost device with
> > > > > upstream kernel and qemu,but failed.
> > > > > >
> > > > > > 1 installing guest from cdrom,ok.
> > > > > > 2 booting vhost-scsi,guest fs error occurs.
> > > > > > 3 using fileio backstores,the error is same..
> > > > > > 4 rebooting guest,a log printed:
> > > > > > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
> > Object
> > > > > 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
> > > > >
> > > > > Paolo, I remember you fixed a similar issue?
> > > > >
> > > > > > 5 using upstream seabios,core dumped.
> > > > > >
> > > > > > Could you give me some advise to debug this problem ? I can
> > provide
> > > > > more information if need.
> > > > >
> > > > > Can you show me qemu commit id you used? Can you verity that if
> > using the
> > > > > host kernel for guest helps? Does booting directly (without the install
> > > > > and reboot process) work?
> > > > Qemu commit id is "commit
> > 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> > > >
> > > > Guest kernel updateing is useless.
> > > >
> > > > Booting directly doesn't work too.
> > >
> > >
> > > Hello Libaiqing,
> > >
> > > Sorry for the delay. I will try to reproduce it myself.
> >
> > I tried 1.5.1 and qemu.git/master and your particular commit
> > 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
> >
> > All work well for me. I used 3.10.0-rc6 as both and guest kernel.
> >
> > >
> > > >
> > > > > > The qemu cmd:
> > > > > > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
> > -enable-kvm
> > > > > -name fedora -M pc -m 1024 -smp 2 -drive
> > > > > file=/home/fedora18.iso,if=ide,media=cdrom -device
> > > > > vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga
> > qxl
> > > > > -vnc :1
> > > > > >
> > > > > > The vnc output:
> > > > > > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> > > > > INCONSISTENCY;RUN FSCK MANUALLY.
> > > > > > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > > > > > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> > > > > system check.
> > > > > >
> > > > > > The guest kernel log:
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > > > > > Kernel: scsi2 : Virtio SCSI HBA
> > > > > > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > > > > > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > > > > > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > > > > > Kernel: sd 2:0:1:0: [sda]write protect is off
> > > > > > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > > > > > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > > > > > Kernel: sda sda1 sda2
> > > > > > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > > > > > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > > > > > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > > > > > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> > > > > >
> > > > > > The info of host:
> > > > > > [root@fedora121 x86_64-softmmu]# uname -a
> > > > > > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013
> > x86_64
> > > > > x86_64 x86_64 GNU/Linux
> > > > > > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > > > > > vhost_scsi 49456 5
> > > > > > target_core_mod 282163 14
> > > > >
> > target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> > > > > ost_scsi
> > > > > > [root@fedora121 x86_64-softmmu]# targetcli
> > > > > > targetcli shell version v2.1.fb26
> > > > > > Copyright 2011 by RisingTide Systems LLC and others.
> > > > > > For help on commands, type 'help'.
> > > > > >
> > > > > > /> ls
> > > > > > o-
> > > > >
> > / ..............................................................................................................
> > > > > ........... [...]
> > > > > > o-
> > > > >
> > backstores ...............................................................................................
> > > > > ............... [...]
> > > > > > | o-
> > > > >
> > block ..................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > fileio .................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > pscsi ..................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > ramdisk ................................................................................................
> > > > > [Storage Objects: 1]
> > > > > > | o-
> > > > > r0 ...................................................................................................
> > > > > [(6.0GiB) activated]
> > > > > > o-
> > > > >
> > iscsi .........................................................................................................
> > > > > ... [Targets: 0]
> > > > > > o-
> > > > >
> > loopback ..................................................................................................
> > > > > ....... [Targets: 0]
> > > > > > o-
> > > > >
> > vhost .......................................................................................................
> > > > > ..... [Targets: 1]
> > > > > > o-
> > > > >
> > naa.50014057133e25dc ............................................................................
> > > > > .................. [TPGs: 1]
> > > > > > o-
> > > > > tpg1 ...............................................................................................
> > > > > [naa.5001405a70ac3421]
> > > > > > o-
> > > > >
> > acls .........................................................................................................
> > .
> > > > > [ACLs: 0]
> > > > > > o-
> > > > >
> > luns .........................................................................................................
> > .
> > > > > [LUNs: 1]
> > > > > > o-
> > > > >
> > lun0 .....................................................................................................
> > > > > [ramdisk/r0]
> > > > > >
> > > > > > Regards,
> > > > > > baiqing
> > > > > > > -----Original Message-----
> > > > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > > > Sent: Thursday, June 20, 2013 9:34 AM
> > > > > > > To: Libaiqing
> > > > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > supporting
> > > > > the
> > > > > > > tcm_vhost Linux kernel module
> > > > > > >
> > > > > > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > > > > > Hi paolo,
> > > > > > > > The vhost-scsi device can be used as boot device?
> > > > > > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > > > > > Could you give me some advise to debug this problem ? I can
> > > > > provide
> > > > > > > more information if need.
> > > > > > >
> > > > > > > Boot from vhost-scsi is supposed to work. The seabios you used
> > should
> > > > > be
> > > > > > > fine which contains the fixes for vhost-scsi.
> > > > > > >
> > > > > > > Instead of playing with the /sys/kernel/config/target directly, I
> > really
> > > > > > > recommend using targetcli utils.
> > > > > > >
> > > > > > > Nab, I think we really should write some docs for people to use
> > > > > > > vhost-scsi.
> > > > > > >
> > > > > > > This is how I install and use targetcli in RHEL6. Note you need
> > upstream
> > > > > > > kernel and qemu bits for vhost-scsi.
> > > > > > >
> > > > > > > # yum groupinstall 'Development tools'
> > > > > > > # yum install python-devel epydoc python-simpleparse
> > > > > > >
> > > > > > > # git clone git://github.com/agrover/rtslib-fb.git
> > > > > > > # git clone git://github.com/agrover/targetcli-fb.git
> > > > > > > # git clone git://github.com/agrover/configshell-fb.git
> > > > > > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > > > > > make -C $i rpm
> > > > > > > yum localinstall $i/dist/*.noarch.rpm
> > > > > > > done
> > > > > > >
> > > > > > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > > > > > # targetcli
> > > > > > > /> /backstores/ramdisk create r0 1g
> > > > > > > /> /vhost create
> > > > > > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > > > > > /> create /backstores/ramdisk/r0
> > > > > > >
> > > > > > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > > > > > >
> > > > > > > Hope this helps.
> > > > > > >
> > > > > > > > Regards,
> > > > > > > > baiqing
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > > > > >
> > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> > > > > On
> > > > > > > > > Behalf Of Paolo Bonzini
> > > > > > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > > > > > To: Wenchao Xia
> > > > > > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> > > > > nab@linux-iscsi.org;
> > > > > > > > > Michael S. Tsirkin
> > > > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > > > supporting
> > > > > > > the
> > > > > > > > > tcm_vhost Linux kernel module
> > > > > > > > >
> > > > > > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > > > > > >> >
> > > > > > > > > >> > The WWPN specified in configfs is passed to "-device
> > > > > > > vhost-scsi-pci".
> > > > > > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now,
> > so it is
> > > > > not
> > > > > > > > > >> > available from the QEMU command-line. Instead, I
> > hardcode it
> > > > > to
> > > > > > > > > zero.
> > > > > > > > > >> >
> > > > > > > > > > Hi, Paolo
> > > > > > > > > > Any document about how to config it correctly in configfs,
> > > > > before
> > > > > > > > > > invoking qemu with the WWPN number?
> > > > > > > > >
> > > > > > > > > Unfortunately no, but vhost-scsi doesn't have many knobs
> > (unlike
> > > > > > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > > > > > >
> > > > > > > > > cd /sys/kernel/config/target
> > > > > > > > > mkdir -p core/fileio_0/fileio
> > > > > > > > > echo
> > > > > > >
> > 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > > > > > core/fileio_0/fileio/control
> > > > > > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > > > > > ln -sf ../../../../../core/fileio_0/fileio/
> > lun/lun_0/virtual_scsi_port
> > > > > > > > > echo naa.60014053226f0388 > nexus
> > > > > > > > >
> > > > > > > > > The "nexus" value is the initiator WWN.
> > naa.600140554cf3a18e is
> > > > > the
> > > > > > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > > > > > >
> > > > > > > > > Paolo
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Asias
> > > > >
> > > > > --
> > > > > Asias
> > >
> > > --
> > > Asias
> >
> > --
> > Asias
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-04 7:00 ` Libaiqing
2013-07-05 0:00 ` Asias He
@ 2013-07-05 6:52 ` Asias He
2013-07-05 11:17 ` Vadim Rozenfeld
1 sibling, 1 reply; 56+ messages in thread
From: Asias He @ 2013-07-05 6:52 UTC (permalink / raw)
To: Libaiqing
Cc: Michael S. Tsirkin, Yan Vugenfirer, qemu-devel@nongnu.org,
nab@linux-iscsi.org, Vadim Rozenfeld, Haofeng, Paolo Bonzini,
Wenchao Xia
[CCing Vadim and Yan]
On Thu, Jul 04, 2013 at 07:00:49AM +0000, Libaiqing wrote:
> Hi asias,
> 1 Window can not boot from vhost-scsi device;
> 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I used the driver virtio-win-0.1-59 version.)
>
> Do you have any plan about these?
I can reproduce this issue on win2003 (Linux guest works fine). The guest
hangs in the boot process. OS is on virito-blk disk, vhost-scsi is
attached as the second disk.
Guest probes from target 0 to 255. Only target 1 is available.
vhost-scsi sends VIRTIO_SCSI_S_BAD_TARGET back to target 0 and 255 except
tareget 1. Howerver, from the log we can see, guest is sending to target
0 again and hangs afterwards.
Vadim and Yan, any ideas?
[ 3109.954237] br0: port 2(tap0) entered disabled state
[ 3109.954387] device tap0 left promiscuous mode
[ 3109.954389] br0: port 2(tap0) entered disabled state
[ 3119.534136] device tap0 entered promiscuous mode
[ 3119.534169] br0: port 2(tap0) entered forwarding state
[ 3119.534180] br0: port 2(tap0) entered forwarding state
[ 3120.138334] vhost_scsi_ctl_handle_kick: The handling func for control queue.
[ 3120.138666] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.138669] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.138671] target=0, tpg= (null)
[ 3120.138672] send bad target head=0, out=1
[ 3120.138673] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139219] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139221] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.139223] target=1, tpg=ffff88021f8fc800
[ 3120.139225] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 36, data_direction: 2
[ 3120.139226] vhost_scsi got command opcode: 0x12, lun: 0
[ 3120.139228] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
[ 3120.139229] Mapping 1 iovecs for 1 pages
[ 3120.139233] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139261] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.139470] vhost_get_vq_desc: head: 0, out: 1 in: 1
[ 3120.139472] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006bd9, len: 51
[ 3120.139474] target=1, tpg=ffff88021f8fc800
[ 3120.139475] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 0, data_direction: 3
[ 3120.139476] vhost_scsi got command opcode: 0x0, lun: 0
[ 3120.139480] vhost_get_vq_desc: head: 128, out: 1 in: 1
[ 3120.139487] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.139554] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139557] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.139558] target=1, tpg=ffff88021f8fc800
[ 3120.139560] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 8, data_direction: 2
[ 3120.139561] vhost_scsi got command opcode: 0x25, lun: 0
[ 3120.139563] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
[ 3120.139564] Mapping 1 iovecs for 1 pages
[ 3120.139568] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139575] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.139783] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139785] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.139787] target=2, tpg= (null)
[ 3120.139788] send bad target head=0, out=1
[ 3120.139789] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139938] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139940] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
...
[ 3120.170209] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.170304] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.170305] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.170306] target=255, tpg= (null)
[ 3120.170306] send bad target head=0, out=1
[ 3120.170307] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.474648] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.474652] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
[ 3120.474654] target=1, tpg=ffff88021f8fc800
[ 3120.474656] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
[ 3120.474658] vhost_scsi got command opcode: 0x28, lun: 0
[ 3120.474660] vhost_scsi_map_iov_to_sgl sg ffff880208f70d40 sgl_count 2 is_err 0
[ 3120.474662] Mapping 1 iovecs for 2 pages
[ 3120.474666] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.474680] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.532843] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.532845] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
[ 3120.532847] target=1, tpg=ffff88021f8fc800
[ 3120.532848] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
[ 3120.532850] vhost_scsi got command opcode: 0x28, lun: 0
[ 3120.532852] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
[ 3120.532853] Mapping 1 iovecs for 1 pages
[ 3120.532857] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.532863] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.532889] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.532891] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
[ 3120.532892] target=1, tpg=ffff88021f8fc800
[ 3120.532894] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
[ 3120.532895] vhost_scsi got command opcode: 0x28, lun: 0
[ 3120.532897] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
[ 3120.532898] Mapping 1 iovecs for 1 pages
[ 3120.532901] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.532906] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3123.852940] vhost_scsi_ctl_handle_kick: The handling func for control queue.
[ 3123.853694] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3123.853696] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f2e6c53ac, len: 51
[ 3123.853697] target=0, tpg= (null)
[ 3123.853698] send bad target head=0, out=1
[ 3123.853700] vhost_get_vq_desc: head: 128, out: 1 in: 2
> Thanks,
> Baiqing.
> > -----Original Message-----
> > From: Asias He [mailto:asias@redhat.com]
> > Sent: Wednesday, July 03, 2013 4:09 PM
> > To: Libaiqing
> > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> > tcm_vhost Linux kernel module
> >
> > On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
> > > On Fri, Jun 21, 2013 at 10:16:48AM +0000, Libaiqing wrote:
> > > > Hi Asias,
> > > >
> > > > > -----Original Message-----
> > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > Sent: Thursday, June 20, 2013 5:39 PM
> > > > > To: Libaiqing
> > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > supporting the
> > > > > tcm_vhost Linux kernel module
> > > > >
> > > > > On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > > > > > Hi Asias,
> > > > > > Thanks for your config.
> > > > > > According to you config,I test booting from vhost device with
> > > > > upstream kernel and qemu,but failed.
> > > > > >
> > > > > > 1 installing guest from cdrom,ok.
> > > > > > 2 booting vhost-scsi,guest fs error occurs.
> > > > > > 3 using fileio backstores,the error is same..
> > > > > > 4 rebooting guest,a log printed:
> > > > > > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
> > Object
> > > > > 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
> > > > >
> > > > > Paolo, I remember you fixed a similar issue?
> > > > >
> > > > > > 5 using upstream seabios,core dumped.
> > > > > >
> > > > > > Could you give me some advise to debug this problem ? I can
> > provide
> > > > > more information if need.
> > > > >
> > > > > Can you show me qemu commit id you used? Can you verity that if
> > using the
> > > > > host kernel for guest helps? Does booting directly (without the install
> > > > > and reboot process) work?
> > > > Qemu commit id is "commit
> > 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> > > >
> > > > Guest kernel updateing is useless.
> > > >
> > > > Booting directly doesn't work too.
> > >
> > >
> > > Hello Libaiqing,
> > >
> > > Sorry for the delay. I will try to reproduce it myself.
> >
> > I tried 1.5.1 and qemu.git/master and your particular commit
> > 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
> >
> > All work well for me. I used 3.10.0-rc6 as both and guest kernel.
> >
> > >
> > > >
> > > > > > The qemu cmd:
> > > > > > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
> > -enable-kvm
> > > > > -name fedora -M pc -m 1024 -smp 2 -drive
> > > > > file=/home/fedora18.iso,if=ide,media=cdrom -device
> > > > > vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga
> > qxl
> > > > > -vnc :1
> > > > > >
> > > > > > The vnc output:
> > > > > > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> > > > > INCONSISTENCY;RUN FSCK MANUALLY.
> > > > > > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > > > > > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> > > > > system check.
> > > > > >
> > > > > > The guest kernel log:
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > > > > > Kernel: scsi2 : Virtio SCSI HBA
> > > > > > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > > > > > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > > > > > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > > > > > Kernel: sd 2:0:1:0: [sda]write protect is off
> > > > > > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > > > > > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > > > > > Kernel: sda sda1 sda2
> > > > > > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > > > > > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > > > > > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > > > > > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> > > > > >
> > > > > > The info of host:
> > > > > > [root@fedora121 x86_64-softmmu]# uname -a
> > > > > > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013
> > x86_64
> > > > > x86_64 x86_64 GNU/Linux
> > > > > > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > > > > > vhost_scsi 49456 5
> > > > > > target_core_mod 282163 14
> > > > >
> > target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> > > > > ost_scsi
> > > > > > [root@fedora121 x86_64-softmmu]# targetcli
> > > > > > targetcli shell version v2.1.fb26
> > > > > > Copyright 2011 by RisingTide Systems LLC and others.
> > > > > > For help on commands, type 'help'.
> > > > > >
> > > > > > /> ls
> > > > > > o-
> > > > >
> > / ..............................................................................................................
> > > > > ........... [...]
> > > > > > o-
> > > > >
> > backstores ...............................................................................................
> > > > > ............... [...]
> > > > > > | o-
> > > > >
> > block ..................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > fileio .................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > pscsi ..................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > ramdisk ................................................................................................
> > > > > [Storage Objects: 1]
> > > > > > | o-
> > > > > r0 ...................................................................................................
> > > > > [(6.0GiB) activated]
> > > > > > o-
> > > > >
> > iscsi .........................................................................................................
> > > > > ... [Targets: 0]
> > > > > > o-
> > > > >
> > loopback ..................................................................................................
> > > > > ....... [Targets: 0]
> > > > > > o-
> > > > >
> > vhost .......................................................................................................
> > > > > ..... [Targets: 1]
> > > > > > o-
> > > > >
> > naa.50014057133e25dc ............................................................................
> > > > > .................. [TPGs: 1]
> > > > > > o-
> > > > > tpg1 ...............................................................................................
> > > > > [naa.5001405a70ac3421]
> > > > > > o-
> > > > >
> > acls .........................................................................................................
> > .
> > > > > [ACLs: 0]
> > > > > > o-
> > > > >
> > luns .........................................................................................................
> > .
> > > > > [LUNs: 1]
> > > > > > o-
> > > > >
> > lun0 .....................................................................................................
> > > > > [ramdisk/r0]
> > > > > >
> > > > > > Regards,
> > > > > > baiqing
> > > > > > > -----Original Message-----
> > > > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > > > Sent: Thursday, June 20, 2013 9:34 AM
> > > > > > > To: Libaiqing
> > > > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > supporting
> > > > > the
> > > > > > > tcm_vhost Linux kernel module
> > > > > > >
> > > > > > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > > > > > Hi paolo,
> > > > > > > > The vhost-scsi device can be used as boot device?
> > > > > > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > > > > > Could you give me some advise to debug this problem ? I can
> > > > > provide
> > > > > > > more information if need.
> > > > > > >
> > > > > > > Boot from vhost-scsi is supposed to work. The seabios you used
> > should
> > > > > be
> > > > > > > fine which contains the fixes for vhost-scsi.
> > > > > > >
> > > > > > > Instead of playing with the /sys/kernel/config/target directly, I
> > really
> > > > > > > recommend using targetcli utils.
> > > > > > >
> > > > > > > Nab, I think we really should write some docs for people to use
> > > > > > > vhost-scsi.
> > > > > > >
> > > > > > > This is how I install and use targetcli in RHEL6. Note you need
> > upstream
> > > > > > > kernel and qemu bits for vhost-scsi.
> > > > > > >
> > > > > > > # yum groupinstall 'Development tools'
> > > > > > > # yum install python-devel epydoc python-simpleparse
> > > > > > >
> > > > > > > # git clone git://github.com/agrover/rtslib-fb.git
> > > > > > > # git clone git://github.com/agrover/targetcli-fb.git
> > > > > > > # git clone git://github.com/agrover/configshell-fb.git
> > > > > > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > > > > > make -C $i rpm
> > > > > > > yum localinstall $i/dist/*.noarch.rpm
> > > > > > > done
> > > > > > >
> > > > > > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > > > > > # targetcli
> > > > > > > /> /backstores/ramdisk create r0 1g
> > > > > > > /> /vhost create
> > > > > > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > > > > > /> create /backstores/ramdisk/r0
> > > > > > >
> > > > > > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > > > > > >
> > > > > > > Hope this helps.
> > > > > > >
> > > > > > > > Regards,
> > > > > > > > baiqing
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > > > > >
> > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> > > > > On
> > > > > > > > > Behalf Of Paolo Bonzini
> > > > > > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > > > > > To: Wenchao Xia
> > > > > > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> > > > > nab@linux-iscsi.org;
> > > > > > > > > Michael S. Tsirkin
> > > > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > > > supporting
> > > > > > > the
> > > > > > > > > tcm_vhost Linux kernel module
> > > > > > > > >
> > > > > > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > > > > > >> >
> > > > > > > > > >> > The WWPN specified in configfs is passed to "-device
> > > > > > > vhost-scsi-pci".
> > > > > > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now,
> > so it is
> > > > > not
> > > > > > > > > >> > available from the QEMU command-line. Instead, I
> > hardcode it
> > > > > to
> > > > > > > > > zero.
> > > > > > > > > >> >
> > > > > > > > > > Hi, Paolo
> > > > > > > > > > Any document about how to config it correctly in configfs,
> > > > > before
> > > > > > > > > > invoking qemu with the WWPN number?
> > > > > > > > >
> > > > > > > > > Unfortunately no, but vhost-scsi doesn't have many knobs
> > (unlike
> > > > > > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > > > > > >
> > > > > > > > > cd /sys/kernel/config/target
> > > > > > > > > mkdir -p core/fileio_0/fileio
> > > > > > > > > echo
> > > > > > >
> > 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > > > > > core/fileio_0/fileio/control
> > > > > > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > > > > > ln -sf ../../../../../core/fileio_0/fileio/
> > lun/lun_0/virtual_scsi_port
> > > > > > > > > echo naa.60014053226f0388 > nexus
> > > > > > > > >
> > > > > > > > > The "nexus" value is the initiator WWN.
> > naa.600140554cf3a18e is
> > > > > the
> > > > > > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > > > > > >
> > > > > > > > > Paolo
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Asias
> > > > >
> > > > > --
> > > > > Asias
> > >
> > > --
> > > Asias
> >
> > --
> > Asias
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-05 6:52 ` Asias He
@ 2013-07-05 11:17 ` Vadim Rozenfeld
2013-07-10 1:50 ` Asias He
0 siblings, 1 reply; 56+ messages in thread
From: Vadim Rozenfeld @ 2013-07-05 11:17 UTC (permalink / raw)
To: Asias He
Cc: Libaiqing, Michael S. Tsirkin, Yan Vugenfirer, qemu-devel, nab,
Haofeng, Paolo Bonzini, Wenchao Xia
Hi Asias,
Windows driver should be able to support as many logical units and targets
as reported by QEMU. In case of VIRTIO_SCSI_S_BAD_TARGET it will just propagate
the relevant SRB error code to the port driver.
In any case, I will try reproducing this problem on my system.
Best,
Vadim.
----- Original Message -----
From: "Asias He" <asias@redhat.com>
To: "Libaiqing" <libaiqing@huawei.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>, "Wenchao Xia" <xiawenc@linux.vnet.ibm.com>, qemu-devel@nongnu.org, nab@linux-iscsi.org, "Michael S. Tsirkin" <mst@redhat.com>, "Haofeng" <haofeng@huawei.com>, "Vadim Rozenfeld" <vrozenfe@redhat.com>, "Yan Vugenfirer" <yvugenfi@redhat.com>
Sent: Friday, July 5, 2013 4:52:05 PM
Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
[CCing Vadim and Yan]
On Thu, Jul 04, 2013 at 07:00:49AM +0000, Libaiqing wrote:
> Hi asias,
> 1 Window can not boot from vhost-scsi device;
> 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I used the driver virtio-win-0.1-59 version.)
>
> Do you have any plan about these?
I can reproduce this issue on win2003 (Linux guest works fine). The guest
hangs in the boot process. OS is on virito-blk disk, vhost-scsi is
attached as the second disk.
Guest probes from target 0 to 255. Only target 1 is available.
vhost-scsi sends VIRTIO_SCSI_S_BAD_TARGET back to target 0 and 255 except
tareget 1. Howerver, from the log we can see, guest is sending to target
0 again and hangs afterwards.
Vadim and Yan, any ideas?
[ 3109.954237] br0: port 2(tap0) entered disabled state
[ 3109.954387] device tap0 left promiscuous mode
[ 3109.954389] br0: port 2(tap0) entered disabled state
[ 3119.534136] device tap0 entered promiscuous mode
[ 3119.534169] br0: port 2(tap0) entered forwarding state
[ 3119.534180] br0: port 2(tap0) entered forwarding state
[ 3120.138334] vhost_scsi_ctl_handle_kick: The handling func for control queue.
[ 3120.138666] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.138669] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.138671] target=0, tpg= (null)
[ 3120.138672] send bad target head=0, out=1
[ 3120.138673] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139219] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139221] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.139223] target=1, tpg=ffff88021f8fc800
[ 3120.139225] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 36, data_direction: 2
[ 3120.139226] vhost_scsi got command opcode: 0x12, lun: 0
[ 3120.139228] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
[ 3120.139229] Mapping 1 iovecs for 1 pages
[ 3120.139233] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139261] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.139470] vhost_get_vq_desc: head: 0, out: 1 in: 1
[ 3120.139472] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006bd9, len: 51
[ 3120.139474] target=1, tpg=ffff88021f8fc800
[ 3120.139475] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 0, data_direction: 3
[ 3120.139476] vhost_scsi got command opcode: 0x0, lun: 0
[ 3120.139480] vhost_get_vq_desc: head: 128, out: 1 in: 1
[ 3120.139487] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.139554] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139557] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.139558] target=1, tpg=ffff88021f8fc800
[ 3120.139560] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 8, data_direction: 2
[ 3120.139561] vhost_scsi got command opcode: 0x25, lun: 0
[ 3120.139563] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
[ 3120.139564] Mapping 1 iovecs for 1 pages
[ 3120.139568] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139575] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.139783] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139785] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.139787] target=2, tpg= (null)
[ 3120.139788] send bad target head=0, out=1
[ 3120.139789] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139938] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139940] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
...
[ 3120.170209] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.170304] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.170305] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
[ 3120.170306] target=255, tpg= (null)
[ 3120.170306] send bad target head=0, out=1
[ 3120.170307] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.474648] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.474652] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
[ 3120.474654] target=1, tpg=ffff88021f8fc800
[ 3120.474656] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
[ 3120.474658] vhost_scsi got command opcode: 0x28, lun: 0
[ 3120.474660] vhost_scsi_map_iov_to_sgl sg ffff880208f70d40 sgl_count 2 is_err 0
[ 3120.474662] Mapping 1 iovecs for 2 pages
[ 3120.474666] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.474680] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.532843] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.532845] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
[ 3120.532847] target=1, tpg=ffff88021f8fc800
[ 3120.532848] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
[ 3120.532850] vhost_scsi got command opcode: 0x28, lun: 0
[ 3120.532852] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
[ 3120.532853] Mapping 1 iovecs for 1 pages
[ 3120.532857] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.532863] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3120.532889] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.532891] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
[ 3120.532892] target=1, tpg=ffff88021f8fc800
[ 3120.532894] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
[ 3120.532895] vhost_scsi got command opcode: 0x28, lun: 0
[ 3120.532897] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
[ 3120.532898] Mapping 1 iovecs for 1 pages
[ 3120.532901] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.532906] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
[ 3123.852940] vhost_scsi_ctl_handle_kick: The handling func for control queue.
[ 3123.853694] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3123.853696] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f2e6c53ac, len: 51
[ 3123.853697] target=0, tpg= (null)
[ 3123.853698] send bad target head=0, out=1
[ 3123.853700] vhost_get_vq_desc: head: 128, out: 1 in: 2
> Thanks,
> Baiqing.
> > -----Original Message-----
> > From: Asias He [mailto:asias@redhat.com]
> > Sent: Wednesday, July 03, 2013 4:09 PM
> > To: Libaiqing
> > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> > tcm_vhost Linux kernel module
> >
> > On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
> > > On Fri, Jun 21, 2013 at 10:16:48AM +0000, Libaiqing wrote:
> > > > Hi Asias,
> > > >
> > > > > -----Original Message-----
> > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > Sent: Thursday, June 20, 2013 5:39 PM
> > > > > To: Libaiqing
> > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > supporting the
> > > > > tcm_vhost Linux kernel module
> > > > >
> > > > > On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > > > > > Hi Asias,
> > > > > > Thanks for your config.
> > > > > > According to you config,I test booting from vhost device with
> > > > > upstream kernel and qemu,but failed.
> > > > > >
> > > > > > 1 installing guest from cdrom,ok.
> > > > > > 2 booting vhost-scsi,guest fs error occurs.
> > > > > > 3 using fileio backstores,the error is same..
> > > > > > 4 rebooting guest,a log printed:
> > > > > > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
> > Object
> > > > > 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
> > > > >
> > > > > Paolo, I remember you fixed a similar issue?
> > > > >
> > > > > > 5 using upstream seabios,core dumped.
> > > > > >
> > > > > > Could you give me some advise to debug this problem ? I can
> > provide
> > > > > more information if need.
> > > > >
> > > > > Can you show me qemu commit id you used? Can you verity that if
> > using the
> > > > > host kernel for guest helps? Does booting directly (without the install
> > > > > and reboot process) work?
> > > > Qemu commit id is "commit
> > 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> > > >
> > > > Guest kernel updateing is useless.
> > > >
> > > > Booting directly doesn't work too.
> > >
> > >
> > > Hello Libaiqing,
> > >
> > > Sorry for the delay. I will try to reproduce it myself.
> >
> > I tried 1.5.1 and qemu.git/master and your particular commit
> > 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
> >
> > All work well for me. I used 3.10.0-rc6 as both and guest kernel.
> >
> > >
> > > >
> > > > > > The qemu cmd:
> > > > > > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
> > -enable-kvm
> > > > > -name fedora -M pc -m 1024 -smp 2 -drive
> > > > > file=/home/fedora18.iso,if=ide,media=cdrom -device
> > > > > vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga
> > qxl
> > > > > -vnc :1
> > > > > >
> > > > > > The vnc output:
> > > > > > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> > > > > INCONSISTENCY;RUN FSCK MANUALLY.
> > > > > > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > > > > > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> > > > > system check.
> > > > > >
> > > > > > The guest kernel log:
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > > > > > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > > > > > Kernel: scsi2 : Virtio SCSI HBA
> > > > > > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > > > > > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > > > > > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > > > > > Kernel: sd 2:0:1:0: [sda]write protect is off
> > > > > > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > > > > > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > > > > > Kernel: sda sda1 sda2
> > > > > > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > > > > > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > > > > > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > > > > > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> > > > > >
> > > > > > The info of host:
> > > > > > [root@fedora121 x86_64-softmmu]# uname -a
> > > > > > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013
> > x86_64
> > > > > x86_64 x86_64 GNU/Linux
> > > > > > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > > > > > vhost_scsi 49456 5
> > > > > > target_core_mod 282163 14
> > > > >
> > target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> > > > > ost_scsi
> > > > > > [root@fedora121 x86_64-softmmu]# targetcli
> > > > > > targetcli shell version v2.1.fb26
> > > > > > Copyright 2011 by RisingTide Systems LLC and others.
> > > > > > For help on commands, type 'help'.
> > > > > >
> > > > > > /> ls
> > > > > > o-
> > > > >
> > / ..............................................................................................................
> > > > > ........... [...]
> > > > > > o-
> > > > >
> > backstores ...............................................................................................
> > > > > ............... [...]
> > > > > > | o-
> > > > >
> > block ..................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > fileio .................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > pscsi ..................................................................................................
> > > > > [Storage Objects: 0]
> > > > > > | o-
> > > > >
> > ramdisk ................................................................................................
> > > > > [Storage Objects: 1]
> > > > > > | o-
> > > > > r0 ...................................................................................................
> > > > > [(6.0GiB) activated]
> > > > > > o-
> > > > >
> > iscsi .........................................................................................................
> > > > > ... [Targets: 0]
> > > > > > o-
> > > > >
> > loopback ..................................................................................................
> > > > > ....... [Targets: 0]
> > > > > > o-
> > > > >
> > vhost .......................................................................................................
> > > > > ..... [Targets: 1]
> > > > > > o-
> > > > >
> > naa.50014057133e25dc ............................................................................
> > > > > .................. [TPGs: 1]
> > > > > > o-
> > > > > tpg1 ...............................................................................................
> > > > > [naa.5001405a70ac3421]
> > > > > > o-
> > > > >
> > acls .........................................................................................................
> > .
> > > > > [ACLs: 0]
> > > > > > o-
> > > > >
> > luns .........................................................................................................
> > .
> > > > > [LUNs: 1]
> > > > > > o-
> > > > >
> > lun0 .....................................................................................................
> > > > > [ramdisk/r0]
> > > > > >
> > > > > > Regards,
> > > > > > baiqing
> > > > > > > -----Original Message-----
> > > > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > > > Sent: Thursday, June 20, 2013 9:34 AM
> > > > > > > To: Libaiqing
> > > > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > supporting
> > > > > the
> > > > > > > tcm_vhost Linux kernel module
> > > > > > >
> > > > > > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > > > > > Hi paolo,
> > > > > > > > The vhost-scsi device can be used as boot device?
> > > > > > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > > > > > Could you give me some advise to debug this problem ? I can
> > > > > provide
> > > > > > > more information if need.
> > > > > > >
> > > > > > > Boot from vhost-scsi is supposed to work. The seabios you used
> > should
> > > > > be
> > > > > > > fine which contains the fixes for vhost-scsi.
> > > > > > >
> > > > > > > Instead of playing with the /sys/kernel/config/target directly, I
> > really
> > > > > > > recommend using targetcli utils.
> > > > > > >
> > > > > > > Nab, I think we really should write some docs for people to use
> > > > > > > vhost-scsi.
> > > > > > >
> > > > > > > This is how I install and use targetcli in RHEL6. Note you need
> > upstream
> > > > > > > kernel and qemu bits for vhost-scsi.
> > > > > > >
> > > > > > > # yum groupinstall 'Development tools'
> > > > > > > # yum install python-devel epydoc python-simpleparse
> > > > > > >
> > > > > > > # git clone git://github.com/agrover/rtslib-fb.git
> > > > > > > # git clone git://github.com/agrover/targetcli-fb.git
> > > > > > > # git clone git://github.com/agrover/configshell-fb.git
> > > > > > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > > > > > make -C $i rpm
> > > > > > > yum localinstall $i/dist/*.noarch.rpm
> > > > > > > done
> > > > > > >
> > > > > > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > > > > > # targetcli
> > > > > > > /> /backstores/ramdisk create r0 1g
> > > > > > > /> /vhost create
> > > > > > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > > > > > /> create /backstores/ramdisk/r0
> > > > > > >
> > > > > > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > > > > > >
> > > > > > > Hope this helps.
> > > > > > >
> > > > > > > > Regards,
> > > > > > > > baiqing
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > > > > >
> > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> > > > > On
> > > > > > > > > Behalf Of Paolo Bonzini
> > > > > > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > > > > > To: Wenchao Xia
> > > > > > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> > > > > nab@linux-iscsi.org;
> > > > > > > > > Michael S. Tsirkin
> > > > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > > > supporting
> > > > > > > the
> > > > > > > > > tcm_vhost Linux kernel module
> > > > > > > > >
> > > > > > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > > > > > >> >
> > > > > > > > > >> > The WWPN specified in configfs is passed to "-device
> > > > > > > vhost-scsi-pci".
> > > > > > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now,
> > so it is
> > > > > not
> > > > > > > > > >> > available from the QEMU command-line. Instead, I
> > hardcode it
> > > > > to
> > > > > > > > > zero.
> > > > > > > > > >> >
> > > > > > > > > > Hi, Paolo
> > > > > > > > > > Any document about how to config it correctly in configfs,
> > > > > before
> > > > > > > > > > invoking qemu with the WWPN number?
> > > > > > > > >
> > > > > > > > > Unfortunately no, but vhost-scsi doesn't have many knobs
> > (unlike
> > > > > > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > > > > > >
> > > > > > > > > cd /sys/kernel/config/target
> > > > > > > > > mkdir -p core/fileio_0/fileio
> > > > > > > > > echo
> > > > > > >
> > 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > > > > > core/fileio_0/fileio/control
> > > > > > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > > > > > ln -sf ../../../../../core/fileio_0/fileio/
> > lun/lun_0/virtual_scsi_port
> > > > > > > > > echo naa.60014053226f0388 > nexus
> > > > > > > > >
> > > > > > > > > The "nexus" value is the initiator WWN.
> > naa.600140554cf3a18e is
> > > > > the
> > > > > > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > > > > > >
> > > > > > > > > Paolo
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Asias
> > > > >
> > > > > --
> > > > > Asias
> > >
> > > --
> > > Asias
> >
> > --
> > Asias
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
2013-07-05 11:17 ` Vadim Rozenfeld
@ 2013-07-10 1:50 ` Asias He
0 siblings, 0 replies; 56+ messages in thread
From: Asias He @ 2013-07-10 1:50 UTC (permalink / raw)
To: Vadim Rozenfeld
Cc: Libaiqing, Michael S. Tsirkin, Yan Vugenfirer, qemu-devel, nab,
Haofeng, Paolo Bonzini, Wenchao Xia
On Fri, Jul 05, 2013 at 07:17:59AM -0400, Vadim Rozenfeld wrote:
> Hi Asias,
>
> Windows driver should be able to support as many logical units and targets
> as reported by QEMU. In case of VIRTIO_SCSI_S_BAD_TARGET it will just propagate
> the relevant SRB error code to the port driver.
> In any case, I will try reproducing this problem on my system.
Thanks, let me know if you have issue to setup the vhost-scsi
environment. In the other mail of this thread, I wrote a howto to setup
up vhost-scsi in RHEL6.
> Best,
> Vadim.
>
> ----- Original Message -----
> From: "Asias He" <asias@redhat.com>
> To: "Libaiqing" <libaiqing@huawei.com>
> Cc: "Paolo Bonzini" <pbonzini@redhat.com>, "Wenchao Xia" <xiawenc@linux.vnet.ibm.com>, qemu-devel@nongnu.org, nab@linux-iscsi.org, "Michael S. Tsirkin" <mst@redhat.com>, "Haofeng" <haofeng@huawei.com>, "Vadim Rozenfeld" <vrozenfe@redhat.com>, "Yan Vugenfirer" <yvugenfi@redhat.com>
> Sent: Friday, July 5, 2013 4:52:05 PM
> Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module
>
> [CCing Vadim and Yan]
>
> On Thu, Jul 04, 2013 at 07:00:49AM +0000, Libaiqing wrote:
> > Hi asias,
> > 1 Window can not boot from vhost-scsi device;
> > 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I used the driver virtio-win-0.1-59 version.)
> >
> > Do you have any plan about these?
>
> I can reproduce this issue on win2003 (Linux guest works fine). The guest
> hangs in the boot process. OS is on virito-blk disk, vhost-scsi is
> attached as the second disk.
>
> Guest probes from target 0 to 255. Only target 1 is available.
> vhost-scsi sends VIRTIO_SCSI_S_BAD_TARGET back to target 0 and 255 except
> tareget 1. Howerver, from the log we can see, guest is sending to target
> 0 again and hangs afterwards.
>
> Vadim and Yan, any ideas?
>
> [ 3109.954237] br0: port 2(tap0) entered disabled state
> [ 3109.954387] device tap0 left promiscuous mode
> [ 3109.954389] br0: port 2(tap0) entered disabled state
> [ 3119.534136] device tap0 entered promiscuous mode
> [ 3119.534169] br0: port 2(tap0) entered forwarding state
> [ 3119.534180] br0: port 2(tap0) entered forwarding state
> [ 3120.138334] vhost_scsi_ctl_handle_kick: The handling func for control queue.
> [ 3120.138666] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.138669] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
> [ 3120.138671] target=0, tpg= (null)
> [ 3120.138672] send bad target head=0, out=1
> [ 3120.138673] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.139219] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.139221] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
> [ 3120.139223] target=1, tpg=ffff88021f8fc800
> [ 3120.139225] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 36, data_direction: 2
> [ 3120.139226] vhost_scsi got command opcode: 0x12, lun: 0
> [ 3120.139228] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
> [ 3120.139229] Mapping 1 iovecs for 1 pages
> [ 3120.139233] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.139261] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
> [ 3120.139470] vhost_get_vq_desc: head: 0, out: 1 in: 1
> [ 3120.139472] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006bd9, len: 51
> [ 3120.139474] target=1, tpg=ffff88021f8fc800
> [ 3120.139475] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 0, data_direction: 3
> [ 3120.139476] vhost_scsi got command opcode: 0x0, lun: 0
> [ 3120.139480] vhost_get_vq_desc: head: 128, out: 1 in: 1
> [ 3120.139487] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
> [ 3120.139554] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.139557] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
> [ 3120.139558] target=1, tpg=ffff88021f8fc800
> [ 3120.139560] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 8, data_direction: 2
> [ 3120.139561] vhost_scsi got command opcode: 0x25, lun: 0
> [ 3120.139563] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
> [ 3120.139564] Mapping 1 iovecs for 1 pages
> [ 3120.139568] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.139575] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
> [ 3120.139783] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.139785] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
> [ 3120.139787] target=2, tpg= (null)
> [ 3120.139788] send bad target head=0, out=1
> [ 3120.139789] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.139938] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.139940] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
>
> ...
>
> [ 3120.170209] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.170304] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.170305] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f28006c15, len: 51
> [ 3120.170306] target=255, tpg= (null)
> [ 3120.170306] send bad target head=0, out=1
> [ 3120.170307] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.474648] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.474652] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
> [ 3120.474654] target=1, tpg=ffff88021f8fc800
> [ 3120.474656] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
> [ 3120.474658] vhost_scsi got command opcode: 0x28, lun: 0
> [ 3120.474660] vhost_scsi_map_iov_to_sgl sg ffff880208f70d40 sgl_count 2 is_err 0
> [ 3120.474662] Mapping 1 iovecs for 2 pages
> [ 3120.474666] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.474680] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
> [ 3120.532843] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.532845] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
> [ 3120.532847] target=1, tpg=ffff88021f8fc800
> [ 3120.532848] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
> [ 3120.532850] vhost_scsi got command opcode: 0x28, lun: 0
> [ 3120.532852] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
> [ 3120.532853] Mapping 1 iovecs for 1 pages
> [ 3120.532857] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.532863] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
> [ 3120.532889] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3120.532891] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f280efe85, len: 51
> [ 3120.532892] target=1, tpg=ffff88021f8fc800
> [ 3120.532894] Allocated tv_cmd: ffff880223cbf800 exp_data_len: 512, data_direction: 2
> [ 3120.532895] vhost_scsi got command opcode: 0x28, lun: 0
> [ 3120.532897] vhost_scsi_map_iov_to_sgl sg ffff8802242bde60 sgl_count 1 is_err 0
> [ 3120.532898] Mapping 1 iovecs for 1 pages
> [ 3120.532901] vhost_get_vq_desc: head: 128, out: 1 in: 2
> [ 3120.532906] vhost_scsi_complete_cmd_work tv_cmd ffff880223cbf800 resid 0 status 0x0
> [ 3123.852940] vhost_scsi_ctl_handle_kick: The handling func for control queue.
> [ 3123.853694] vhost_get_vq_desc: head: 0, out: 1 in: 2
> [ 3123.853696] Calling __copy_from_user: vq->iov[0].iov_base: 00007f8f2e6c53ac, len: 51
> [ 3123.853697] target=0, tpg= (null)
> [ 3123.853698] send bad target head=0, out=1
> [ 3123.853700] vhost_get_vq_desc: head: 128, out: 1 in: 2
>
> > Thanks,
> > Baiqing.
> > > -----Original Message-----
> > > From: Asias He [mailto:asias@redhat.com]
> > > Sent: Wednesday, July 03, 2013 4:09 PM
> > > To: Libaiqing
> > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
> > > tcm_vhost Linux kernel module
> > >
> > > On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
> > > > On Fri, Jun 21, 2013 at 10:16:48AM +0000, Libaiqing wrote:
> > > > > Hi Asias,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > > Sent: Thursday, June 20, 2013 5:39 PM
> > > > > > To: Libaiqing
> > > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > supporting the
> > > > > > tcm_vhost Linux kernel module
> > > > > >
> > > > > > On Thu, Jun 20, 2013 at 08:49:50AM +0000, Libaiqing wrote:
> > > > > > > Hi Asias,
> > > > > > > Thanks for your config.
> > > > > > > According to you config,I test booting from vhost device with
> > > > > > upstream kernel and qemu,but failed.
> > > > > > >
> > > > > > > 1 installing guest from cdrom,ok.
> > > > > > > 2 booting vhost-scsi,guest fs error occurs.
> > > > > > > 3 using fileio backstores,the error is same..
> > > > > > > 4 rebooting guest,a log printed:
> > > > > > > (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
> > > Object
> > > > > > 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
> > > > > >
> > > > > > Paolo, I remember you fixed a similar issue?
> > > > > >
> > > > > > > 5 using upstream seabios,core dumped.
> > > > > > >
> > > > > > > Could you give me some advise to debug this problem ? I can
> > > provide
> > > > > > more information if need.
> > > > > >
> > > > > > Can you show me qemu commit id you used? Can you verity that if
> > > using the
> > > > > > host kernel for guest helps? Does booting directly (without the install
> > > > > > and reboot process) work?
> > > > > Qemu commit id is "commit
> > > 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427".
> > > > >
> > > > > Guest kernel updateing is useless.
> > > > >
> > > > > Booting directly doesn't work too.
> > > >
> > > >
> > > > Hello Libaiqing,
> > > >
> > > > Sorry for the delay. I will try to reproduce it myself.
> > >
> > > I tried 1.5.1 and qemu.git/master and your particular commit
> > > 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
> > >
> > > All work well for me. I used 3.10.0-rc6 as both and guest kernel.
> > >
> > > >
> > > > >
> > > > > > > The qemu cmd:
> > > > > > > [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
> > > -enable-kvm
> > > > > > -name fedora -M pc -m 1024 -smp 2 -drive
> > > > > > file=/home/fedora18.iso,if=ide,media=cdrom -device
> > > > > > vhost-scsi-pci,wwpn=naa.50014057133e25dc -monitor stdio -vga
> > > qxl
> > > > > > -vnc :1
> > > > > > >
> > > > > > > The vnc output:
> > > > > > > Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
> > > > > > INCONSISTENCY;RUN FSCK MANUALLY.
> > > > > > > Dracut-initqueue[189]: Warning: e2fsck returned with 4
> > > > > > > Dracut-initqueue[189]: Warning: ***An error occurred during the file
> > > > > > system check.
> > > > > > >
> > > > > > > The guest kernel log:
> > > > > > > Kernel: virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X
> > > > > > > Kernel: virtio-pci 0000:00:04.0: irq 41 for MSI/MSI-X
> > > > > > > Kernel: virtio-pci 0000:00:04.0: irq 42 for MSI/MSI-X
> > > > > > > Kernel: virtio-pci 0000:00:04.0: irq 43 for MSI/MSI-X
> > > > > > > Kernel: scsi2 : Virtio SCSI HBA
> > > > > > > Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
> > > > > > > Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
> > > > > > > Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .....
> > > > > > > Kernel: sd 2:0:1:0: [sda]write protect is off
> > > > > > > Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
> > > > > > > Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .....
> > > > > > > Kernel: sda sda1 sda2
> > > > > > > Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
> > > > > > > Dracut-initqueue[189]: Scanning devices sda2 for LVM
> > > > > > > Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
> > > > > > > Dracut-initqueue[189]: inactive '/dev/fedora/root'...
> > > > > > >
> > > > > > > The info of host:
> > > > > > > [root@fedora121 x86_64-softmmu]# uname -a
> > > > > > > Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013
> > > x86_64
> > > > > > x86_64 x86_64 GNU/Linux
> > > > > > > [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
> > > > > > > vhost_scsi 49456 5
> > > > > > > target_core_mod 282163 14
> > > > > >
> > > target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
> > > > > > ost_scsi
> > > > > > > [root@fedora121 x86_64-softmmu]# targetcli
> > > > > > > targetcli shell version v2.1.fb26
> > > > > > > Copyright 2011 by RisingTide Systems LLC and others.
> > > > > > > For help on commands, type 'help'.
> > > > > > >
> > > > > > > /> ls
> > > > > > > o-
> > > > > >
> > > / ..............................................................................................................
> > > > > > ........... [...]
> > > > > > > o-
> > > > > >
> > > backstores ...............................................................................................
> > > > > > ............... [...]
> > > > > > > | o-
> > > > > >
> > > block ..................................................................................................
> > > > > > [Storage Objects: 0]
> > > > > > > | o-
> > > > > >
> > > fileio .................................................................................................
> > > > > > [Storage Objects: 0]
> > > > > > > | o-
> > > > > >
> > > pscsi ..................................................................................................
> > > > > > [Storage Objects: 0]
> > > > > > > | o-
> > > > > >
> > > ramdisk ................................................................................................
> > > > > > [Storage Objects: 1]
> > > > > > > | o-
> > > > > > r0 ...................................................................................................
> > > > > > [(6.0GiB) activated]
> > > > > > > o-
> > > > > >
> > > iscsi .........................................................................................................
> > > > > > ... [Targets: 0]
> > > > > > > o-
> > > > > >
> > > loopback ..................................................................................................
> > > > > > ....... [Targets: 0]
> > > > > > > o-
> > > > > >
> > > vhost .......................................................................................................
> > > > > > ..... [Targets: 1]
> > > > > > > o-
> > > > > >
> > > naa.50014057133e25dc ............................................................................
> > > > > > .................. [TPGs: 1]
> > > > > > > o-
> > > > > > tpg1 ...............................................................................................
> > > > > > [naa.5001405a70ac3421]
> > > > > > > o-
> > > > > >
> > > acls .........................................................................................................
> > > .
> > > > > > [ACLs: 0]
> > > > > > > o-
> > > > > >
> > > luns .........................................................................................................
> > > .
> > > > > > [LUNs: 1]
> > > > > > > o-
> > > > > >
> > > lun0 .....................................................................................................
> > > > > > [ramdisk/r0]
> > > > > > >
> > > > > > > Regards,
> > > > > > > baiqing
> > > > > > > > -----Original Message-----
> > > > > > > > From: Asias He [mailto:asias@redhat.com]
> > > > > > > > Sent: Thursday, June 20, 2013 9:34 AM
> > > > > > > > To: Libaiqing
> > > > > > > > Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
> > > > > > > > nab@linux-iscsi.org; Michael S. Tsirkin; Haofeng
> > > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > supporting
> > > > > > the
> > > > > > > > tcm_vhost Linux kernel module
> > > > > > > >
> > > > > > > > On Wed, Jun 19, 2013 at 12:55:10PM +0000, Libaiqing wrote:
> > > > > > > > > Hi paolo,
> > > > > > > > > The vhost-scsi device can be used as boot device?
> > > > > > > > > I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
> > > > > > > > > Could you give me some advise to debug this problem ? I can
> > > > > > provide
> > > > > > > > more information if need.
> > > > > > > >
> > > > > > > > Boot from vhost-scsi is supposed to work. The seabios you used
> > > should
> > > > > > be
> > > > > > > > fine which contains the fixes for vhost-scsi.
> > > > > > > >
> > > > > > > > Instead of playing with the /sys/kernel/config/target directly, I
> > > really
> > > > > > > > recommend using targetcli utils.
> > > > > > > >
> > > > > > > > Nab, I think we really should write some docs for people to use
> > > > > > > > vhost-scsi.
> > > > > > > >
> > > > > > > > This is how I install and use targetcli in RHEL6. Note you need
> > > upstream
> > > > > > > > kernel and qemu bits for vhost-scsi.
> > > > > > > >
> > > > > > > > # yum groupinstall 'Development tools'
> > > > > > > > # yum install python-devel epydoc python-simpleparse
> > > > > > > >
> > > > > > > > # git clone git://github.com/agrover/rtslib-fb.git
> > > > > > > > # git clone git://github.com/agrover/targetcli-fb.git
> > > > > > > > # git clone git://github.com/agrover/configshell-fb.git
> > > > > > > > # for i in rtslib-fb configshell-fb targetcli-fb; do
> > > > > > > > make -C $i rpm
> > > > > > > > yum localinstall $i/dist/*.noarch.rpm
> > > > > > > > done
> > > > > > > >
> > > > > > > > In targetcli, create a backstore and vhost wwpn, e.g.
> > > > > > > > # targetcli
> > > > > > > > /> /backstores/ramdisk create r0 1g
> > > > > > > > /> /vhost create
> > > > > > > > /> cd /vhost/naa.500140527cb6616b/tpg1/luns
> > > > > > > > /> create /backstores/ramdisk/r0
> > > > > > > >
> > > > > > > > # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
> > > > > > > >
> > > > > > > > Hope this helps.
> > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > baiqing
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: qemu-devel-bounces+libaiqing=huawei.com@nongnu.org
> > > > > > > > > >
> > > [mailto:qemu-devel-bounces+libaiqing=huawei.com@nongnu.org]
> > > > > > On
> > > > > > > > > > Behalf Of Paolo Bonzini
> > > > > > > > > > Sent: Tuesday, May 28, 2013 4:01 PM
> > > > > > > > > > To: Wenchao Xia
> > > > > > > > > > Cc: asias@redhat.com; qemu-devel@nongnu.org;
> > > > > > nab@linux-iscsi.org;
> > > > > > > > > > Michael S. Tsirkin
> > > > > > > > > > Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
> > > > > > supporting
> > > > > > > > the
> > > > > > > > > > tcm_vhost Linux kernel module
> > > > > > > > > >
> > > > > > > > > > Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> > > > > > > > > > >> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> > > > > > > > > > >> >
> > > > > > > > > > >> > The WWPN specified in configfs is passed to "-device
> > > > > > > > vhost-scsi-pci".
> > > > > > > > > > >> > The tgpt field of the SET_ENDPOINT ioctl is obsolete now,
> > > so it is
> > > > > > not
> > > > > > > > > > >> > available from the QEMU command-line. Instead, I
> > > hardcode it
> > > > > > to
> > > > > > > > > > zero.
> > > > > > > > > > >> >
> > > > > > > > > > > Hi, Paolo
> > > > > > > > > > > Any document about how to config it correctly in configfs,
> > > > > > before
> > > > > > > > > > > invoking qemu with the WWPN number?
> > > > > > > > > >
> > > > > > > > > > Unfortunately no, but vhost-scsi doesn't have many knobs
> > > (unlike
> > > > > > > > > > iSCSI for example) so it's quite simple. Here is an example:
> > > > > > > > > >
> > > > > > > > > > cd /sys/kernel/config/target
> > > > > > > > > > mkdir -p core/fileio_0/fileio
> > > > > > > > > > echo
> > > > > > > >
> > > 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > > > > > > > > > core/fileio_0/fileio/control
> > > > > > > > > > echo 1 > core/fileio_0/fileio/enable
> > > > > > > > > > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > > > > > > > > > cd vhost/naa.600140554cf3a18e/tpgt_0
> > > > > > > > > > ln -sf ../../../../../core/fileio_0/fileio/
> > > lun/lun_0/virtual_scsi_port
> > > > > > > > > > echo naa.60014053226f0388 > nexus
> > > > > > > > > >
> > > > > > > > > > The "nexus" value is the initiator WWN.
> > > naa.600140554cf3a18e is
> > > > > > the
> > > > > > > > > > target WWN that you have to pass to "-device vhost-scsi-pci".
> > > > > > > > > >
> > > > > > > > > > Paolo
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Asias
> > > > > >
> > > > > > --
> > > > > > Asias
> > > >
> > > > --
> > > > Asias
> > >
> > > --
> > > Asias
>
> --
> Asias
--
Asias
^ permalink raw reply [flat|nested] 56+ messages in thread
* [Qemu-devel] [PATCH 7/9] vhost-scsi-pci: new device supporting the tcm_vhost Linux kernel module
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (5 preceding siblings ...)
2013-04-19 14:24 ` [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 8/9] vhost-scsi-ccw: " Paolo Bonzini
` (4 subsequent siblings)
11 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: asias, nab, Michael S. Tsirkin
From: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/virtio/virtio-pci.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++
hw/virtio/virtio-pci.h | 18 +++++++++++++++
2 files changed, 78 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index b362cc8..c1e9a60 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1285,6 +1285,63 @@ static const TypeInfo virtio_scsi_pci_info = {
.class_init = virtio_scsi_pci_class_init,
};
+/* vhost-scsi-pci */
+
+#ifdef CONFIG_VHOST_SCSI
+static Property vhost_scsi_pci_properties[] = {
+ DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors,
+ DEV_NVECTORS_UNSPECIFIED),
+ DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
+ DEFINE_VHOST_SCSI_PROPERTIES(VHostSCSIPCI, vdev.parent_obj.conf),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
+static int vhost_scsi_pci_init_pci(VirtIOPCIProxy *vpci_dev)
+{
+ VHostSCSIPCI *dev = VHOST_SCSI_PCI(vpci_dev);
+ DeviceState *vdev = DEVICE(&dev->vdev);
+ VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+
+ if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {
+ vpci_dev->nvectors = vs->conf.num_queues + 3;
+ }
+
+ qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
+ if (qdev_init(vdev) < 0) {
+ return -1;
+ }
+ return 0;
+}
+
+static void vhost_scsi_pci_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
+ PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
+ k->init = vhost_scsi_pci_init_pci;
+ dc->props = vhost_scsi_pci_properties;
+ pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+ pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_SCSI;
+ pcidev_k->revision = 0x00;
+ pcidev_k->class_id = PCI_CLASS_STORAGE_SCSI;
+}
+
+static void vhost_scsi_pci_instance_init(Object *obj)
+{
+ VHostSCSIPCI *dev = VHOST_SCSI_PCI(obj);
+ object_initialize(OBJECT(&dev->vdev), TYPE_VHOST_SCSI);
+ object_property_add_child(obj, "virtio-backend", OBJECT(&dev->vdev), NULL);
+}
+
+static const TypeInfo vhost_scsi_pci_info = {
+ .name = TYPE_VHOST_SCSI_PCI,
+ .parent = TYPE_VIRTIO_PCI,
+ .instance_size = sizeof(VHostSCSIPCI),
+ .instance_init = vhost_scsi_pci_instance_init,
+ .class_init = vhost_scsi_pci_class_init,
+};
+#endif
+
/* virtio-balloon-pci */
static void balloon_pci_stats_get_all(Object *obj, struct Visitor *v,
@@ -1541,6 +1598,9 @@ static void virtio_pci_register_types(void)
type_register_static(&virtio_balloon_pci_info);
type_register_static(&virtio_serial_pci_info);
type_register_static(&virtio_net_pci_info);
+#ifdef CONFIG_VHOST_SCSI
+ type_register_static(&vhost_scsi_pci_info);
+#endif
}
type_init(virtio_pci_register_types)
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index aa67561..1b66e46 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -24,6 +24,9 @@
#include "hw/virtio/virtio-balloon.h"
#include "hw/virtio/virtio-bus.h"
#include "hw/virtio/virtio-9p.h"
+#ifdef CONFIG_VHOST_SCSI
+#include "hw/virtio/vhost-scsi.h"
+#endif
typedef struct VirtIOPCIProxy VirtIOPCIProxy;
typedef struct VirtIOBlkPCI VirtIOBlkPCI;
@@ -31,6 +34,7 @@ typedef struct VirtIOSCSIPCI VirtIOSCSIPCI;
typedef struct VirtIOBalloonPCI VirtIOBalloonPCI;
typedef struct VirtIOSerialPCI VirtIOSerialPCI;
typedef struct VirtIONetPCI VirtIONetPCI;
+typedef struct VHostSCSIPCI VHostSCSIPCI;
/* virtio-pci-bus */
@@ -104,6 +108,20 @@ struct VirtIOSCSIPCI {
VirtIOSCSI vdev;
};
+#ifdef CONFIG_VHOST_SCSI
+/*
+ * vhost-scsi-pci: This extends VirtioPCIProxy.
+ */
+#define TYPE_VHOST_SCSI_PCI "vhost-scsi-pci"
+#define VHOST_SCSI_PCI(obj) \
+ OBJECT_CHECK(VHostSCSIPCI, (obj), TYPE_VHOST_SCSI_PCI)
+
+struct VHostSCSIPCI {
+ VirtIOPCIProxy parent_obj;
+ VHostSCSI vdev;
+};
+#endif
+
/*
* virtio-blk-pci: This extends VirtioPCIProxy.
*/
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Qemu-devel] [PATCH 8/9] vhost-scsi-ccw: new device supporting the tcm_vhost Linux kernel module
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (6 preceding siblings ...)
2013-04-19 14:24 ` [Qemu-devel] [PATCH 7/9] vhost-scsi-pci: " Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-04-19 14:24 ` [Qemu-devel] [PATCH 9/9] vhost-scsi-s390: " Paolo Bonzini
` (3 subsequent siblings)
11 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: asias, nab
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/s390x/virtio-ccw.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
hw/s390x/virtio-ccw.h | 14 ++++++++++++++
2 files changed, 65 insertions(+)
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 5232526..56539d3 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -687,6 +687,28 @@ static void virtio_ccw_scsi_instance_init(Object *obj)
object_property_add_child(obj, "virtio-backend", OBJECT(&dev->vdev), NULL);
}
+#ifdef CONFIG_VHOST_SCSI
+static int vhost_ccw_scsi_init(VirtioCcwDevice *ccw_dev)
+{
+ VHostSCSICcw *dev = VHOST_SCSI_CCW(ccw_dev);
+ DeviceState *vdev = DEVICE(&dev->vdev);
+
+ qdev_set_parent_bus(vdev, BUS(&ccw_dev->bus));
+ if (qdev_init(vdev) < 0) {
+ return -1;
+ }
+
+ return virtio_ccw_device_init(ccw_dev, VIRTIO_DEVICE(vdev));
+}
+
+static void vhost_ccw_scsi_instance_init(Object *obj)
+{
+ VHostSCSICcw *dev = VHOST_SCSI_CCW(obj);
+ object_initialize(OBJECT(&dev->vdev), TYPE_VHOST_SCSI);
+ object_property_add_child(obj, "virtio-backend", OBJECT(&dev->vdev), NULL);
+}
+#endif
+
static int virtio_ccw_rng_init(VirtioCcwDevice *dev)
{
VirtIODevice *vdev;
@@ -897,6 +919,34 @@ static const TypeInfo virtio_ccw_scsi = {
.class_init = virtio_ccw_scsi_class_init,
};
+#ifdef CONFIG_VHOST_SCSI
+static Property vhost_ccw_scsi_properties[] = {
+ DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
+ DEFINE_VHOST_SCSI_PROPERTIES(VirtIOSCSICcw, vdev.parent_obj.conf),
+ DEFINE_VIRTIO_COMMON_FEATURES(VirtioCcwDevice, host_features[0]),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
+static void vhost_ccw_scsi_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);
+
+ k->init = vhost_ccw_scsi_init;
+ k->exit = virtio_ccw_exit;
+ dc->reset = virtio_ccw_reset;
+ dc->props = vhost_ccw_scsi_properties;
+}
+
+static const TypeInfo vhost_ccw_scsi = {
+ .name = TYPE_VHOST_SCSI_CCW,
+ .parent = TYPE_VIRTIO_CCW_DEVICE,
+ .instance_size = sizeof(VirtIOSCSICcw),
+ .instance_init = vhost_ccw_scsi_instance_init,
+ .class_init = vhost_ccw_scsi_class_init,
+};
+#endif
+
static void virtio_ccw_rng_initfn(Object *obj)
{
VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(obj);
@@ -1054,6 +1104,7 @@ static void virtio_ccw_register(void)
type_register_static(&virtio_ccw_net);
type_register_static(&virtio_ccw_balloon);
type_register_static(&virtio_ccw_scsi);
+ type_register_static(&vhost_ccw_scsi);
type_register_static(&virtio_ccw_rng);
type_register_static(&virtual_css_bridge_info);
}
diff --git a/hw/s390x/virtio-ccw.h b/hw/s390x/virtio-ccw.h
index 35ab1a5..84055e7 100644
--- a/hw/s390x/virtio-ccw.h
+++ b/hw/s390x/virtio-ccw.h
@@ -16,6 +16,9 @@
#include <hw/virtio/virtio-net.h>
#include <hw/virtio/virtio-serial.h>
#include <hw/virtio/virtio-scsi.h>
+#ifdef CONFIG_VHOST_SCSI
+#include <hw/virtio/vhost-scsi.h>
+#endif
#include <hw/virtio/virtio-balloon.h>
#include <hw/virtio/virtio-rng.h>
#include <hw/virtio/virtio-bus.h>
@@ -101,6 +104,17 @@ typedef struct VirtIOSCSICcw {
VirtIOSCSI vdev;
} VirtIOSCSICcw;
+/* vhost-scsi-ccw */
+
+#define TYPE_VHOST_SCSI_CCW "vhost-scsi-ccw"
+#define VHOST_SCSI_CCW(obj) \
+ OBJECT_CHECK(VHostSCSICcw, (obj), TYPE_VHOST_SCSI_CCW)
+
+typedef struct VHostSCSICcw {
+ VirtioCcwDevice parent_obj;
+ VHostSCSI vdev;
+} VHostSCSICcw;
+
/* virtio-blk-ccw */
#define TYPE_VIRTIO_BLK_CCW "virtio-blk-ccw"
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* [Qemu-devel] [PATCH 9/9] vhost-scsi-s390: new device supporting the tcm_vhost Linux kernel module
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (7 preceding siblings ...)
2013-04-19 14:24 ` [Qemu-devel] [PATCH 8/9] vhost-scsi-ccw: " Paolo Bonzini
@ 2013-04-19 14:24 ` Paolo Bonzini
2013-04-23 23:17 ` [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Nicholas A. Bellinger
` (2 subsequent siblings)
11 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-19 14:24 UTC (permalink / raw)
To: qemu-devel; +Cc: asias, nab, Michael S. Tsirkin
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Asias He <asias@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/s390x/s390-virtio-bus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++
hw/s390x/s390-virtio-bus.h | 16 +++++++++++++++
2 files changed, 65 insertions(+)
diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index 8f29b5e..dabbc2e 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -28,6 +28,7 @@
#include "hw/virtio/virtio-rng.h"
#include "hw/virtio/virtio-serial.h"
#include "hw/virtio/virtio-net.h"
+#include "hw/virtio/vhost-scsi.h"
#include "hw/sysbus.h"
#include "sysemu/kvm.h"
@@ -239,6 +240,28 @@ static void s390_virtio_scsi_instance_init(Object *obj)
object_property_add_child(obj, "virtio-backend", OBJECT(&dev->vdev), NULL);
}
+#ifdef CONFIG_VHOST_SCSI
+static int s390_vhost_scsi_init(VirtIOS390Device *s390_dev)
+{
+ VHostSCSIS390 *dev = VHOST_SCSI_S390(s390_dev);
+ DeviceState *vdev = DEVICE(&dev->vdev);
+
+ qdev_set_parent_bus(vdev, BUS(&s390_dev->bus));
+ if (qdev_init(vdev) < 0) {
+ return -1;
+ }
+
+ return s390_virtio_device_init(s390_dev, VIRTIO_DEVICE(vdev));
+}
+
+static void s390_vhost_scsi_instance_init(Object *obj)
+{
+ VHostSCSIS390 *dev = VHOST_SCSI_S390(obj);
+ object_initialize(OBJECT(&dev->vdev), TYPE_VHOST_SCSI);
+ object_property_add_child(obj, "virtio-backend", OBJECT(&dev->vdev), NULL);
+}
+#endif
+
static int s390_virtio_rng_init(VirtIOS390Device *dev)
{
VirtIODevice *vdev;
@@ -582,6 +605,31 @@ static const TypeInfo s390_virtio_scsi = {
.class_init = s390_virtio_scsi_class_init,
};
+#ifdef CONFIG_VHOST_SCSI
+static Property s390_vhost_scsi_properties[] = {
+ DEFINE_VIRTIO_COMMON_FEATURES(VirtIOS390Device, host_features),
+ DEFINE_VHOST_SCSI_PROPERTIES(VHostSCSIS390, vdev.parent_obj.conf),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
+static void s390_vhost_scsi_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ VirtIOS390DeviceClass *k = VIRTIO_S390_DEVICE_CLASS(klass);
+
+ k->init = s390_vhost_scsi_init;
+ dc->props = s390_vhost_scsi_properties;
+}
+
+static const TypeInfo s390_vhost_scsi = {
+ .name = TYPE_VHOST_SCSI_S390,
+ .parent = TYPE_VIRTIO_S390_DEVICE,
+ .instance_size = sizeof(VHostSCSIS390),
+ .instance_init = s390_vhost_scsi_instance_init,
+ .class_init = s390_vhost_scsi_class_init,
+};
+#endif
+
/***************** S390 Virtio Bus Bridge Device *******************/
/* Only required to have the virtio bus as child in the system bus */
@@ -643,6 +691,7 @@ static void s390_virtio_register_types(void)
type_register_static(&s390_virtio_blk);
type_register_static(&s390_virtio_net);
type_register_static(&s390_virtio_scsi);
+ type_register_static(&s390_vhost_scsi);
type_register_static(&s390_virtio_rng);
type_register_static(&s390_virtio_bridge_info);
}
diff --git a/hw/s390x/s390-virtio-bus.h b/hw/s390x/s390-virtio-bus.h
index 925ed2b..d7c47db 100644
--- a/hw/s390x/s390-virtio-bus.h
+++ b/hw/s390x/s390-virtio-bus.h
@@ -25,6 +25,9 @@
#include "hw/virtio/virtio-serial.h"
#include "hw/virtio/virtio-scsi.h"
#include "hw/virtio/virtio-bus.h"
+#ifdef CONFIG_VHOST_SCSI
+#include "hw/virtio/vhost-scsi.h"
+#endif
#define VIRTIO_DEV_OFFS_TYPE 0 /* 8 bits */
#define VIRTIO_DEV_OFFS_NUM_VQ 1 /* 8 bits */
@@ -160,4 +163,17 @@ typedef struct VirtIONetS390 {
VirtIONet vdev;
} VirtIONetS390;
+/* vhost-scsi-s390 */
+
+#ifdef CONFIG_VHOST_SCSI
+#define TYPE_VHOST_SCSI_S390 "vhost-scsi-s390"
+#define VHOST_SCSI_S390(obj) \
+ OBJECT_CHECK(VHostSCSIS390, (obj), TYPE_VHOST_SCSI_S390)
+
+typedef struct VHostSCSIS390 {
+ VirtIOS390Device parent_obj;
+ VHostSCSI vdev;
+} VHostSCSIS390;
+#endif
+
#endif
--
1.8.1.4
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (8 preceding siblings ...)
2013-04-19 14:24 ` [Qemu-devel] [PATCH 9/9] vhost-scsi-s390: " Paolo Bonzini
@ 2013-04-23 23:17 ` Nicholas A. Bellinger
2013-04-24 5:59 ` [Qemu-devel] seabios for qemu 1.5 Gerd Hoffmann
2013-04-24 4:56 ` [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Stefan Weil
2013-06-17 21:18 ` Anthony Liguori
11 siblings, 1 reply; 56+ messages in thread
From: Nicholas A. Bellinger @ 2013-04-23 23:17 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Michael S. Tsirkin, qemu-devel, target-devel, Gerd Hoffmann,
Anthony Liguori, asias
On Fri, 2013-04-19 at 16:24 +0200, Paolo Bonzini wrote:
> The following changes since commit 09dada400328d75daf79e3eca1e48e024fec148d:
>
> configure: remove duplicate test (2013-04-18 14:12:31 +0200)
>
> are available in the git repository at:
>
> git://github.com/bonzini/qemu.git scsi-next
>
> for you to fetch changes up to d6e51919a7e3250bbfb4bb0ad0f208ab6fd688a4:
>
> vhost-scsi-s390: new device supporting the tcm_vhost Linux kernel module (2013-04-19 16:19:13 +0200)
>
> The VMware PVSCSI implementation and vhost-scsi are finally getting in.
>
Hi Paolo & Co,
Thanks for all of the efforts to finally get the vhost-scsi series
merged into upstream QEMU v1.5 code!
Also, just a reminder that pc-bios/bios.bin needs to be updated to
include Asias's seabios.git commits below for this code to boot.
b44a7be17bdd270ea029a8e2ec0c2e80c6cd0444 virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
5a7730db57ab0715223421e65b54fb50d6fefe5c virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
I just tested with this afternoon's qemu.git and seabios.git HEADs, and
both are functioning as expected.
Anthony + Gerd, can we expect an rev to pc-bios/bios.bin soon to pick up
these seabios changes for vhost-scsi..?
Thanks,
--nab
> Paolo
> ----------------------------------------------------------------
> Dmitry Fleytman (1):
> scsi: VMWare PVSCSI paravirtual device implementation
>
> Nicholas Bellinger (3):
> vhost: Add vhost_commit callback for SeaBIOS ROM region re-mapping
> vhost-scsi: new device supporting the tcm_vhost Linux kernel module
> vhost-scsi-pci: new device supporting the tcm_vhost Linux kernel module
>
> Paolo Bonzini (5):
> scsi: avoid assertion failure on VERIFY command
> virtio-scsi: create VirtIOSCSICommon
> virtio: simplify Makefile conditionals
> vhost-scsi-ccw: new device supporting the tcm_vhost Linux kernel module
> vhost-scsi-s390: new device supporting the tcm_vhost Linux kernel module
>
> configure | 10 +
> default-configs/pci.mak | 1 +
> docs/specs/vmw_pvscsi-spec.txt | 92 +++
> hw/Makefile.objs | 2 +-
> hw/s390x/s390-virtio-bus.c | 51 +-
> hw/s390x/s390-virtio-bus.h | 16 +
> hw/s390x/virtio-ccw.c | 53 +-
> hw/s390x/virtio-ccw.h | 14 +
> hw/scsi/Makefile.objs | 7 +-
> hw/scsi/scsi-disk.c | 19 +-
> hw/scsi/vhost-scsi.c | 288 ++++++++++
> hw/scsi/virtio-scsi.c | 212 +++----
> hw/scsi/vmw_pvscsi.c | 1216 +++++++++++++++++++++++++++++++++++++++
> hw/scsi/vmw_pvscsi.h | 434 ++++++++++++++
> hw/virtio/Makefile.objs | 8 +-
> hw/virtio/vhost.c | 53 +-
> hw/virtio/virtio-pci.c | 65 ++-
> hw/virtio/virtio-pci.h | 18 +
> include/hw/pci/pci.h | 1 +
> include/hw/virtio/vhost-scsi.h | 73 +++
> include/hw/virtio/vhost.h | 3 +
> include/hw/virtio/virtio-scsi.h | 135 ++++-
> include/qemu/osdep.h | 4 +
> trace-events | 35 ++
> 24 files changed, 2636 insertions(+), 174 deletions(-)
> create mode 100644 docs/specs/vmw_pvscsi-spec.txt
> create mode 100644 hw/scsi/vhost-scsi.c
> create mode 100644 hw/scsi/vmw_pvscsi.c
> create mode 100644 hw/scsi/vmw_pvscsi.h
> create mode 100644 include/hw/virtio/vhost-scsi.h
^ permalink raw reply [flat|nested] 56+ messages in thread* [Qemu-devel] seabios for qemu 1.5
2013-04-23 23:17 ` [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Nicholas A. Bellinger
@ 2013-04-24 5:59 ` Gerd Hoffmann
2013-04-24 6:11 ` Amos Kong
2013-04-30 16:01 ` Paolo Bonzini
0 siblings, 2 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2013-04-24 5:59 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Kevin O'Connor, Michael S. Tsirkin, seabios@seabios.org,
qemu-devel, target-devel, Anthony Liguori, Paolo Bonzini, asias
Hi,
> b44a7be17bdd270ea029a8e2ec0c2e80c6cd0444 virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
> 5a7730db57ab0715223421e65b54fb50d6fefe5c virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
> Anthony + Gerd, can we expect an rev to pc-bios/bios.bin soon to pick up
> these seabios changes for vhost-scsi..?
I don't feel like placing a seabios git snapshot into qemu.
I think we should just cherry-pick everything we need for qemu 1.5 into
the 1.7.2-stable branch, roll out a 1.7.2.2 release and put that into
qemu 1.5.
So, what will be needed?
(1) The two commits listed above.
(2) The patch for the pvpanic device (assuming it gets
merged for 1.5).
Anything else?
Hard freeze for qemu 1.5 is next Wednesday.
cheers,
Gerd
PS: For qemu 1.6 (which will hopefully include the acpi table
reorganization) we will need a new release from the master
branch and thus a bit more careful release planning.
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] seabios for qemu 1.5
2013-04-24 5:59 ` [Qemu-devel] seabios for qemu 1.5 Gerd Hoffmann
@ 2013-04-24 6:11 ` Amos Kong
2013-05-16 4:46 ` Amos Kong
2013-04-30 16:01 ` Paolo Bonzini
1 sibling, 1 reply; 56+ messages in thread
From: Amos Kong @ 2013-04-24 6:11 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Kevin O'Connor, Michael S. Tsirkin, seabios@seabios.org,
qemu-devel, Nicholas A. Bellinger, target-devel, Anthony Liguori,
Paolo Bonzini, asias
On Wed, Apr 24, 2013 at 07:59:36AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > b44a7be17bdd270ea029a8e2ec0c2e80c6cd0444 virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
> > 5a7730db57ab0715223421e65b54fb50d6fefe5c virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
>
> > Anthony + Gerd, can we expect an rev to pc-bios/bios.bin soon to pick up
> > these seabios changes for vhost-scsi..?
>
> I don't feel like placing a seabios git snapshot into qemu.
>
> I think we should just cherry-pick everything we need for qemu 1.5 into
> the 1.7.2-stable branch, roll out a 1.7.2.2 release and put that into
> qemu 1.5.
>
> So, what will be needed?
>
> (1) The two commits listed above.
> (2) The patch for the pvpanic device (assuming it gets
> merged for 1.5).
>
> Anything else?
Hi Gerd,
This bug fix is needed:
| commit 11a7234491cb2a027b0fa5e82af38a3e78b44c80
| Author: Kevin O'Connor <kevin@koconnor.net>
| Date: Tue Mar 5 17:52:21 2013 +0800
|
| Cache boot-fail-wait to avoid romfile access after POST.
|
| Memory allocated with malloc_tmp() can't be used after the POST phase.
| So, access boot-fail-wait in post phase and store it for the boot
| phase to use. This fixes the regression introduced by commit
| 59d6ca52.
> Hard freeze for qemu 1.5 is next Wednesday.
>
> cheers,
> Gerd
>
> PS: For qemu 1.6 (which will hopefully include the acpi table
> reorganization) we will need a new release from the master
> branch and thus a bit more careful release planning.
>
--
Amos.
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] seabios for qemu 1.5
2013-04-24 6:11 ` Amos Kong
@ 2013-05-16 4:46 ` Amos Kong
2013-05-27 6:17 ` Gerd Hoffmann
0 siblings, 1 reply; 56+ messages in thread
From: Amos Kong @ 2013-05-16 4:46 UTC (permalink / raw)
To: Gerd Hoffmann, kevin, anthony
Cc: Michael S. Tsirkin, seabios@seabios.org, qemu-devel,
Nicholas A. Bellinger, target-devel, Paolo Bonzini, asias
On Wed, Apr 24, 2013 at 02:11:26PM +0800, Amos Kong wrote:
> On Wed, Apr 24, 2013 at 07:59:36AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > b44a7be17bdd270ea029a8e2ec0c2e80c6cd0444 virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
> > > 5a7730db57ab0715223421e65b54fb50d6fefe5c virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
> >
> > > Anthony + Gerd, can we expect an rev to pc-bios/bios.bin soon to pick up
> > > these seabios changes for vhost-scsi..?
> >
> > I don't feel like placing a seabios git snapshot into qemu.
> >
> > I think we should just cherry-pick everything we need for qemu 1.5 into
> > the 1.7.2-stable branch, roll out a 1.7.2.2 release and put that into
> > qemu 1.5.
> >
> > So, what will be needed?
> >
> > (1) The two commits listed above.
> > (2) The patch for the pvpanic device (assuming it gets
> > merged for 1.5).
> >
> > Anything else?
>
> Hi Gerd,
>
> This bug fix is needed:
>
> | commit 11a7234491cb2a027b0fa5e82af38a3e78b44c80
> | Author: Kevin O'Connor <kevin@koconnor.net>
> | Date: Tue Mar 5 17:52:21 2013 +0800
> |
> | Cache boot-fail-wait to avoid romfile access after POST.
> |
> | Memory allocated with malloc_tmp() can't be used after the POST phase.
> | So, access boot-fail-wait in post phase and store it for the boot
> | phase to use. This fixes the regression introduced by commit
> | 59d6ca52.
This patch doesn't contain in seabios-1.7.2.1, it wasn't contained in
latest bios.bin of qemu, it caused 'strict boot' doesn't work.
# qemu -boot strict=on
What can we do for this? push Kevin add this patch in stable branch
and re-built bios.bin?
> > Hard freeze for qemu 1.5 is next Wednesday.
> >
> > cheers,
> > Gerd
> >
> > PS: For qemu 1.6 (which will hopefully include the acpi table
> > reorganization) we will need a new release from the master
> > branch and thus a bit more careful release planning.
--
Amos.
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] seabios for qemu 1.5
2013-05-16 4:46 ` Amos Kong
@ 2013-05-27 6:17 ` Gerd Hoffmann
0 siblings, 0 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2013-05-27 6:17 UTC (permalink / raw)
To: Amos Kong
Cc: target-devel, Michael S. Tsirkin, seabios@seabios.org, qemu-devel,
Nicholas A. Bellinger, kevin, anthony, Paolo Bonzini, asias
Hi,
>> | commit 11a7234491cb2a027b0fa5e82af38a3e78b44c80
>> | Author: Kevin O'Connor <kevin@koconnor.net>
>> | Date: Tue Mar 5 17:52:21 2013 +0800
>> |
>> | Cache boot-fail-wait to avoid romfile access after POST.
>> |
>> | Memory allocated with malloc_tmp() can't be used after the POST phase.
>> | So, access boot-fail-wait in post phase and store it for the boot
>> | phase to use. This fixes the regression introduced by commit
>> | 59d6ca52.
>
>
> This patch doesn't contain in seabios-1.7.2.1, it wasn't contained in
> latest bios.bin of qemu, it caused 'strict boot' doesn't work.
>
> # qemu -boot strict=on
>
> What can we do for this? push Kevin add this patch in stable branch
> and re-built bios.bin?
It's in the 1.7.2-stable branch meanwhile. 1.7.2.2 isn't tagged yet
though. It's going slower than usual, seems Kevin is a bit busy with
non-seabios things these days.
Once we have a release released I'll put updates into master and the
stable-1.5 branch.
cheers,
Gerd
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] seabios for qemu 1.5
2013-04-24 5:59 ` [Qemu-devel] seabios for qemu 1.5 Gerd Hoffmann
2013-04-24 6:11 ` Amos Kong
@ 2013-04-30 16:01 ` Paolo Bonzini
1 sibling, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-30 16:01 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Kevin O'Connor, Michael S. Tsirkin, seabios@seabios.org,
qemu-devel, Nicholas A. Bellinger, target-devel, Anthony Liguori,
asias
Il 24/04/2013 07:59, Gerd Hoffmann ha scritto:
> Hi,
>
>> b44a7be17bdd270ea029a8e2ec0c2e80c6cd0444 virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
>> 5a7730db57ab0715223421e65b54fb50d6fefe5c virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
>
>> Anthony + Gerd, can we expect an rev to pc-bios/bios.bin soon to pick up
>> these seabios changes for vhost-scsi..?
>
> I don't feel like placing a seabios git snapshot into qemu.
>
> I think we should just cherry-pick everything we need for qemu 1.5 into
> the 1.7.2-stable branch, roll out a 1.7.2.2 release and put that into
> qemu 1.5.
>
> So, what will be needed?
>
> (1) The two commits listed above.
> (2) The patch for the pvpanic device (assuming it gets
> merged for 1.5).
>
> Anything else?
>
> Hard freeze for qemu 1.5 is next Wednesday.
It's just a few patches, so we can do it in -rc1 too.
Paolo
> cheers,
> Gerd
>
> PS: For qemu 1.6 (which will hopefully include the acpi table
> reorganization) we will need a new release from the master
> branch and thus a bit more careful release planning.
>
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (9 preceding siblings ...)
2013-04-23 23:17 ` [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Nicholas A. Bellinger
@ 2013-04-24 4:56 ` Stefan Weil
2013-04-24 8:19 ` Paolo Bonzini
2013-06-17 21:18 ` Anthony Liguori
11 siblings, 1 reply; 56+ messages in thread
From: Stefan Weil @ 2013-04-24 4:56 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: asias, qemu-devel, nab
Am 19.04.2013 16:24, schrieb Paolo Bonzini:
> The following changes since commit 09dada400328d75daf79e3eca1e48e024fec148d:
>
> configure: remove duplicate test (2013-04-18 14:12:31 +0200)
>
> are available in the git repository at:
>
> git://github.com/bonzini/qemu.git scsi-next
>
> for you to fetch changes up to d6e51919a7e3250bbfb4bb0ad0f208ab6fd688a4:
>
> vhost-scsi-s390: new device supporting the tcm_vhost Linux kernel module (2013-04-19 16:19:13 +0200)
>
> The VMware PVSCSI implementation and vhost-scsi are finally getting in.
>
> Paolo
> ----------------------------------------------------------------
> Dmitry Fleytman (1):
> scsi: VMWare PVSCSI paravirtual device implementation
>
> Nicholas Bellinger (3):
> vhost: Add vhost_commit callback for SeaBIOS ROM region re-mapping
> vhost-scsi: new device supporting the tcm_vhost Linux kernel module
> vhost-scsi-pci: new device supporting the tcm_vhost Linux kernel module
>
> Paolo Bonzini (5):
> scsi: avoid assertion failure on VERIFY command
> virtio-scsi: create VirtIOSCSICommon
> virtio: simplify Makefile conditionals
> vhost-scsi-ccw: new device supporting the tcm_vhost Linux kernel module
> vhost-scsi-s390: new device supporting the tcm_vhost Linux kernel module
>
Hi Paolo,
the latest QEMU build is broken when CONFIG_VHOST_SCSI is undefined.
Regards,
Stefan
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13
2013-04-24 4:56 ` [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Stefan Weil
@ 2013-04-24 8:19 ` Paolo Bonzini
2013-04-24 16:56 ` Stefan Weil
0 siblings, 1 reply; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-24 8:19 UTC (permalink / raw)
To: Stefan Weil; +Cc: asias, qemu-devel, nab
Il 24/04/2013 06:56, Stefan Weil ha scritto:
> Hi Paolo,
>
> the latest QEMU build is broken when CONFIG_VHOST_SCSI is undefined.
--verbose, please. :)
$ ../configure --disable-vhost-scsi
$ grep VHOST_SC */config-* config-*
$
works here.
Paolo
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13
2013-04-24 8:19 ` Paolo Bonzini
@ 2013-04-24 16:56 ` Stefan Weil
2013-04-26 8:40 ` Paolo Bonzini
0 siblings, 1 reply; 56+ messages in thread
From: Stefan Weil @ 2013-04-24 16:56 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: asias, qemu-devel, nab
Am 24.04.2013 10:19, schrieb Paolo Bonzini:
> Il 24/04/2013 06:56, Stefan Weil ha scritto:
>> Hi Paolo, the latest QEMU build is broken when CONFIG_VHOST_SCSI is
>> undefined.
> --verbose, please. :)
Sorry, I thought it was obvious. The error occurs in a cross build for
w64 when building s390x-softmmu.
Regards,
Stefan
$ make -C bin/debug/amd64-mingw32msvc -k
make: Entering directory `/qemu/bin/debug/amd64-mingw32msvc'
CC s390x-softmmu/hw/s390x/s390-virtio-bus.o
/qemu/hw/s390x/s390-virtio-bus.c: In function 's390_virtio_register_types':
/qemu/hw/s390x/s390-virtio-bus.c:694: error: 's390_vhost_scsi'
undeclared (first use in this function)
/qemu/hw/s390x/s390-virtio-bus.c:694: error: (Each undeclared identifier
is reported only once
/qemu/hw/s390x/s390-virtio-bus.c:694: error: for each function it
appears in.)
make[1]: *** [hw/s390x/s390-virtio-bus.o] Fehler 1
CC s390x-softmmu/hw/s390x/s390-virtio-ccw.o
In file included from /qemu/hw/s390x/s390-virtio-ccw.c:18:
/qemu/hw/s390x/virtio-ccw.h:115: error: expected
specifier-qualifier-list before 'VHostSCSI'
make[1]: *** [hw/s390x/s390-virtio-ccw.o] Fehler 1
CC s390x-softmmu/hw/s390x/virtio-ccw.o
In file included from /qemu/hw/s390x/virtio-ccw.c:27:
/qemu/hw/s390x/virtio-ccw.h:115: error: expected
specifier-qualifier-list before 'VHostSCSI'
/qemu/hw/s390x/virtio-ccw.c: In function 'virtio_ccw_register':
/qemu/hw/s390x/virtio-ccw.c:1107: error: 'vhost_ccw_scsi' undeclared
(first use in this function)
/qemu/hw/s390x/virtio-ccw.c:1107: error: (Each undeclared identifier is
reported only once
/qemu/hw/s390x/virtio-ccw.c:1107: error: for each function it appears in.)
make[1]: *** [hw/s390x/virtio-ccw.o] Fehler 1
CC s390x-softmmu/target-s390x/translate.o
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13
2013-04-24 16:56 ` Stefan Weil
@ 2013-04-26 8:40 ` Paolo Bonzini
0 siblings, 0 replies; 56+ messages in thread
From: Paolo Bonzini @ 2013-04-26 8:40 UTC (permalink / raw)
To: Stefan Weil; +Cc: asias, qemu-devel, nab
Il 24/04/2013 18:56, Stefan Weil ha scritto:
> Am 24.04.2013 10:19, schrieb Paolo Bonzini:
>> Il 24/04/2013 06:56, Stefan Weil ha scritto:
>>> Hi Paolo, the latest QEMU build is broken when CONFIG_VHOST_SCSI is
>>> undefined.
>> --verbose, please. :)
>
> Sorry, I thought it was obvious. The error occurs in a cross build for
> w64 when building s390x-softmmu.
Will fix it next week, -rc0 should be fine.
Paolo
> Regards,
> Stefan
>
> $ make -C bin/debug/amd64-mingw32msvc -k
> make: Entering directory `/qemu/bin/debug/amd64-mingw32msvc'
> CC s390x-softmmu/hw/s390x/s390-virtio-bus.o
> /qemu/hw/s390x/s390-virtio-bus.c: In function 's390_virtio_register_types':
> /qemu/hw/s390x/s390-virtio-bus.c:694: error: 's390_vhost_scsi'
> undeclared (first use in this function)
> /qemu/hw/s390x/s390-virtio-bus.c:694: error: (Each undeclared identifier
> is reported only once
> /qemu/hw/s390x/s390-virtio-bus.c:694: error: for each function it
> appears in.)
> make[1]: *** [hw/s390x/s390-virtio-bus.o] Fehler 1
> CC s390x-softmmu/hw/s390x/s390-virtio-ccw.o
> In file included from /qemu/hw/s390x/s390-virtio-ccw.c:18:
> /qemu/hw/s390x/virtio-ccw.h:115: error: expected
> specifier-qualifier-list before 'VHostSCSI'
> make[1]: *** [hw/s390x/s390-virtio-ccw.o] Fehler 1
> CC s390x-softmmu/hw/s390x/virtio-ccw.o
> In file included from /qemu/hw/s390x/virtio-ccw.c:27:
> /qemu/hw/s390x/virtio-ccw.h:115: error: expected
> specifier-qualifier-list before 'VHostSCSI'
> /qemu/hw/s390x/virtio-ccw.c: In function 'virtio_ccw_register':
> /qemu/hw/s390x/virtio-ccw.c:1107: error: 'vhost_ccw_scsi' undeclared
> (first use in this function)
> /qemu/hw/s390x/virtio-ccw.c:1107: error: (Each undeclared identifier is
> reported only once
> /qemu/hw/s390x/virtio-ccw.c:1107: error: for each function it appears in.)
> make[1]: *** [hw/s390x/virtio-ccw.o] Fehler 1
> CC s390x-softmmu/target-s390x/translate.o
>
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13
2013-04-19 14:24 [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Paolo Bonzini
` (10 preceding siblings ...)
2013-04-24 4:56 ` [Qemu-devel] [PULL 0/9] SCSI updates for 2013-04-13 Stefan Weil
@ 2013-06-17 21:18 ` Anthony Liguori
11 siblings, 0 replies; 56+ messages in thread
From: Anthony Liguori @ 2013-06-17 21:18 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Michael S. Tsirkin, seabios@seabios.org, target-devel, asias
Pulled. Thanks.
Regards,
Anthony Liguori
^ permalink raw reply [flat|nested] 56+ messages in thread