2007-12-24 19:11:51 +03:00
|
|
|
/*
|
|
|
|
* Generic SCSI Device support
|
|
|
|
*
|
|
|
|
* Copyright (c) 2007 Bull S.A.S.
|
|
|
|
* Based on code by Paul Brook
|
|
|
|
* Based on code by Fabrice Bellard
|
|
|
|
*
|
|
|
|
* Written by Laurent Vivier <Laurent.Vivier@bull.net>
|
|
|
|
*
|
2011-06-26 06:21:35 +04:00
|
|
|
* This code is licensed under the LGPL.
|
2007-12-24 19:11:51 +03:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2016-01-26 21:17:16 +03:00
|
|
|
#include "qemu/osdep.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 11:01:28 +03:00
|
|
|
#include "qapi/error.h"
|
2019-05-23 17:35:06 +03:00
|
|
|
#include "qemu/ctype.h"
|
2012-12-17 21:20:00 +04:00
|
|
|
#include "qemu/error-report.h"
|
2019-05-23 17:35:07 +03:00
|
|
|
#include "qemu/module.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/scsi/scsi.h"
|
2019-08-12 08:23:39 +03:00
|
|
|
#include "migration/qemu-file-types.h"
|
2019-08-12 08:23:51 +03:00
|
|
|
#include "hw/qdev-properties.h"
|
2020-12-12 01:05:12 +03:00
|
|
|
#include "hw/qdev-properties-system.h"
|
2018-10-23 01:43:51 +03:00
|
|
|
#include "hw/scsi/emulation.h"
|
2014-10-07 15:59:18 +04:00
|
|
|
#include "sysemu/block-backend.h"
|
2018-12-11 19:31:05 +03:00
|
|
|
#include "trace.h"
|
2007-12-24 19:11:51 +03:00
|
|
|
|
2009-08-31 16:24:04 +04:00
|
|
|
#ifdef __linux__
|
2007-12-24 19:11:51 +03:00
|
|
|
|
|
|
|
#include <scsi/sg.h>
|
2017-08-22 10:23:55 +03:00
|
|
|
#include "scsi/constants.h"
|
2007-12-24 19:11:51 +03:00
|
|
|
|
|
|
|
#ifndef MAX_UINT
|
|
|
|
#define MAX_UINT ((unsigned int)-1)
|
|
|
|
#endif
|
|
|
|
|
2009-11-26 17:33:48 +03:00
|
|
|
typedef struct SCSIGenericReq {
|
|
|
|
SCSIRequest req;
|
2007-12-24 19:11:51 +03:00
|
|
|
uint8_t *buf;
|
|
|
|
int buflen;
|
|
|
|
int len;
|
|
|
|
sg_io_hdr_t io_header;
|
2009-11-26 17:33:48 +03:00
|
|
|
} SCSIGenericReq;
|
2007-12-24 19:11:51 +03:00
|
|
|
|
2011-12-15 16:24:30 +04:00
|
|
|
static void scsi_generic_save_request(QEMUFile *f, SCSIRequest *req)
|
|
|
|
{
|
|
|
|
SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req);
|
|
|
|
|
|
|
|
qemu_put_sbe32s(f, &r->buflen);
|
|
|
|
if (r->buflen && r->req.cmd.mode == SCSI_XFER_TO_DEV) {
|
|
|
|
assert(!r->req.sg);
|
|
|
|
qemu_put_buffer(f, r->buf, r->req.cmd.xfer);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void scsi_generic_load_request(QEMUFile *f, SCSIRequest *req)
|
|
|
|
{
|
|
|
|
SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req);
|
|
|
|
|
|
|
|
qemu_get_sbe32s(f, &r->buflen);
|
|
|
|
if (r->buflen && r->req.cmd.mode == SCSI_XFER_TO_DEV) {
|
|
|
|
assert(!r->req.sg);
|
|
|
|
qemu_get_buffer(f, r->buf, r->req.cmd.xfer);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-18 18:01:56 +04:00
|
|
|
static void scsi_free_request(SCSIRequest *req)
|
2007-12-24 19:11:51 +03:00
|
|
|
{
|
2011-04-18 18:01:56 +04:00
|
|
|
SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req);
|
|
|
|
|
2011-08-21 07:09:37 +04:00
|
|
|
g_free(r->buf);
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Helper function for command completion. */
|
2015-07-19 20:15:26 +03:00
|
|
|
static void scsi_command_complete_noio(SCSIGenericReq *r, int ret)
|
2007-12-24 19:11:51 +03:00
|
|
|
{
|
2011-08-03 12:49:06 +04:00
|
|
|
int status;
|
2017-08-22 10:43:14 +03:00
|
|
|
SCSISense sense;
|
2020-11-16 21:40:40 +03:00
|
|
|
sg_io_hdr_t *io_hdr = &r->io_header;
|
2007-12-24 19:11:51 +03:00
|
|
|
|
2015-07-19 20:15:26 +03:00
|
|
|
assert(r->req.aiocb == NULL);
|
|
|
|
|
2014-09-24 12:27:53 +04:00
|
|
|
if (r->req.io_canceled) {
|
2014-09-25 06:20:47 +04:00
|
|
|
scsi_req_cancel_complete(&r->req);
|
2014-09-24 12:27:53 +04:00
|
|
|
goto done;
|
|
|
|
}
|
2020-11-16 21:40:40 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
status = scsi_sense_from_errno(-ret, &sense);
|
|
|
|
if (status == CHECK_CONDITION) {
|
2017-08-22 10:43:14 +03:00
|
|
|
scsi_req_build_sense(&r->req, sense);
|
2011-08-03 12:49:06 +04:00
|
|
|
}
|
2020-11-16 21:40:40 +03:00
|
|
|
} else if (io_hdr->host_status != SCSI_HOST_OK) {
|
2021-02-24 21:14:50 +03:00
|
|
|
scsi_req_complete_failed(&r->req, io_hdr->host_status);
|
|
|
|
goto done;
|
2020-11-16 21:40:40 +03:00
|
|
|
} else if (io_hdr->driver_status & SG_ERR_DRIVER_TIMEOUT) {
|
|
|
|
status = BUSY;
|
|
|
|
} else {
|
|
|
|
status = io_hdr->status;
|
|
|
|
if (io_hdr->driver_status & SG_ERR_DRIVER_SENSE) {
|
|
|
|
r->req.sense_len = io_hdr->sb_len_wr;
|
|
|
|
}
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
2018-12-11 19:31:05 +03:00
|
|
|
trace_scsi_generic_command_complete_noio(r, r->req.tag, status);
|
2009-11-26 17:34:00 +03:00
|
|
|
|
2011-08-03 12:49:06 +04:00
|
|
|
scsi_req_complete(&r->req, status);
|
2014-09-24 12:27:53 +04:00
|
|
|
done:
|
2014-09-24 12:27:54 +04:00
|
|
|
scsi_req_unref(&r->req);
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
|
2015-07-19 20:15:26 +03:00
|
|
|
static void scsi_command_complete(void *opaque, int ret)
|
|
|
|
{
|
|
|
|
SCSIGenericReq *r = (SCSIGenericReq *)opaque;
|
2017-02-13 16:52:32 +03:00
|
|
|
SCSIDevice *s = r->req.dev;
|
2015-07-19 20:15:26 +03:00
|
|
|
|
|
|
|
assert(r->req.aiocb != NULL);
|
|
|
|
r->req.aiocb = NULL;
|
2017-02-13 16:52:32 +03:00
|
|
|
|
|
|
|
aio_context_acquire(blk_get_aio_context(s->conf.blk));
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, ret);
|
2017-02-13 16:52:32 +03:00
|
|
|
aio_context_release(blk_get_aio_context(s->conf.blk));
|
2015-07-19 20:15:26 +03:00
|
|
|
}
|
|
|
|
|
2014-10-07 15:59:18 +04:00
|
|
|
static int execute_command(BlockBackend *blk,
|
2009-11-26 17:33:48 +03:00
|
|
|
SCSIGenericReq *r, int direction,
|
2014-10-07 15:59:15 +04:00
|
|
|
BlockCompletionFunc *complete)
|
2007-12-24 19:11:51 +03:00
|
|
|
{
|
2020-11-16 21:31:13 +03:00
|
|
|
SCSIDevice *s = r->req.dev;
|
|
|
|
|
2007-12-24 19:11:51 +03:00
|
|
|
r->io_header.interface_id = 'S';
|
|
|
|
r->io_header.dxfer_direction = direction;
|
|
|
|
r->io_header.dxferp = r->buf;
|
|
|
|
r->io_header.dxfer_len = r->buflen;
|
2009-11-26 17:33:51 +03:00
|
|
|
r->io_header.cmdp = r->req.cmd.buf;
|
|
|
|
r->io_header.cmd_len = r->req.cmd.len;
|
2011-08-03 12:49:07 +04:00
|
|
|
r->io_header.mx_sb_len = sizeof(r->req.sense);
|
|
|
|
r->io_header.sbp = r->req.sense;
|
2020-11-16 21:31:13 +03:00
|
|
|
r->io_header.timeout = s->io_timeout * 1000;
|
2007-12-24 19:11:51 +03:00
|
|
|
r->io_header.usr_ptr = r;
|
|
|
|
r->io_header.flags |= SG_FLAG_DIRECT_IO;
|
|
|
|
|
2020-11-16 21:31:14 +03:00
|
|
|
trace_scsi_generic_aio_sgio_command(r->req.tag, r->req.cmd.buf[0],
|
|
|
|
r->io_header.timeout);
|
2014-10-07 15:59:18 +04:00
|
|
|
r->req.aiocb = blk_aio_ioctl(blk, SG_IO, &r->io_header, complete, r);
|
2013-05-29 16:12:10 +04:00
|
|
|
if (r->req.aiocb == NULL) {
|
|
|
|
return -EIO;
|
|
|
|
}
|
2007-12-24 19:11:51 +03:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-12-17 19:56:12 +03:00
|
|
|
static int scsi_handle_inquiry_reply(SCSIGenericReq *r, SCSIDevice *s, int len)
|
2018-06-27 20:24:30 +03:00
|
|
|
{
|
2018-10-23 01:46:21 +03:00
|
|
|
uint8_t page, page_idx;
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
|
2018-06-27 20:24:30 +03:00
|
|
|
/*
|
|
|
|
* EVPD set to zero returns the standard INQUIRY data.
|
|
|
|
*
|
|
|
|
* Check if scsi_version is unset (-1) to avoid re-defining it
|
|
|
|
* each time an INQUIRY with standard data is received.
|
|
|
|
* scsi_version is initialized with -1 in scsi_generic_reset
|
|
|
|
* and scsi_disk_reset, making sure that we'll set the
|
|
|
|
* scsi_version after a reset. If the version field of the
|
|
|
|
* INQUIRY response somehow changes after a guest reboot,
|
|
|
|
* we'll be able to keep track of it.
|
|
|
|
*
|
|
|
|
* On SCSI-2 and older, first 3 bits of byte 2 is the
|
|
|
|
* ANSI-approved version, while on later versions the
|
|
|
|
* whole byte 2 contains the version. Check if we're dealing
|
|
|
|
* with a newer version and, in that case, assign the
|
|
|
|
* whole byte.
|
|
|
|
*/
|
|
|
|
if (s->scsi_version == -1 && !(r->req.cmd.buf[1] & 0x01)) {
|
|
|
|
s->scsi_version = r->buf[2] & 0x07;
|
|
|
|
if (s->scsi_version > 2) {
|
|
|
|
s->scsi_version = r->buf[2];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-12 01:51:22 +03:00
|
|
|
if ((s->type == TYPE_DISK || s->type == TYPE_ZBC) &&
|
|
|
|
(r->req.cmd.buf[1] & 0x01)) {
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
page = r->req.cmd.buf[2];
|
|
|
|
if (page == 0xb0) {
|
2021-06-03 11:34:23 +03:00
|
|
|
uint64_t max_transfer = blk_get_max_hw_transfer(s->conf.blk);
|
2021-09-23 16:04:36 +03:00
|
|
|
uint32_t max_iov = blk_get_max_hw_iov(s->conf.blk);
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
|
|
|
|
assert(max_transfer);
|
2021-04-14 20:51:48 +03:00
|
|
|
max_transfer = MIN_NON_ZERO(max_transfer, max_iov * qemu_real_host_page_size)
|
|
|
|
/ s->blocksize;
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
stl_be_p(&r->buf[8], max_transfer);
|
|
|
|
/* Also take care of the opt xfer len. */
|
|
|
|
stl_be_p(&r->buf[12],
|
|
|
|
MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12])));
|
2019-01-11 19:27:31 +03:00
|
|
|
} else if (s->needs_vpd_bl_emulation && page == 0x00 && r->buflen >= 4) {
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
/*
|
|
|
|
* Now we're capable of supplying the VPD Block Limits
|
|
|
|
* response if the hardware can't. Add it in the INQUIRY
|
|
|
|
* Supported VPD pages response in case we are using the
|
|
|
|
* emulation for this device.
|
|
|
|
*
|
|
|
|
* This way, the guest kernel will be aware of the support
|
|
|
|
* and will use it to proper setup the SCSI device.
|
2018-10-23 01:46:21 +03:00
|
|
|
*
|
|
|
|
* VPD page numbers must be sorted, so insert 0xb0 at the
|
2019-01-11 19:27:31 +03:00
|
|
|
* right place with an in-place insert. When the while loop
|
|
|
|
* begins the device response is at r[0] to r[page_idx - 1].
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
*/
|
2019-01-11 19:27:31 +03:00
|
|
|
page_idx = lduw_be_p(r->buf + 2) + 4;
|
|
|
|
page_idx = MIN(page_idx, r->buflen);
|
|
|
|
while (page_idx > 4 && r->buf[page_idx - 1] >= 0xb0) {
|
2018-10-23 01:46:21 +03:00
|
|
|
if (page_idx < r->buflen) {
|
|
|
|
r->buf[page_idx] = r->buf[page_idx - 1];
|
|
|
|
}
|
2019-01-11 19:27:31 +03:00
|
|
|
page_idx--;
|
|
|
|
}
|
|
|
|
if (page_idx < r->buflen) {
|
|
|
|
r->buf[page_idx] = 0xb0;
|
2018-10-23 01:46:21 +03:00
|
|
|
}
|
|
|
|
stw_be_p(r->buf + 2, lduw_be_p(r->buf + 2) + 1);
|
2020-12-17 19:56:12 +03:00
|
|
|
|
|
|
|
if (len < r->buflen) {
|
|
|
|
len++;
|
|
|
|
}
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
}
|
2018-06-27 20:24:30 +03:00
|
|
|
}
|
2020-12-17 19:56:12 +03:00
|
|
|
return len;
|
2018-06-27 20:24:30 +03:00
|
|
|
}
|
|
|
|
|
2018-10-23 01:43:51 +03:00
|
|
|
static int scsi_generic_emulate_block_limits(SCSIGenericReq *r, SCSIDevice *s)
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
{
|
2018-10-23 01:43:51 +03:00
|
|
|
int len;
|
|
|
|
uint8_t buf[64];
|
|
|
|
|
|
|
|
SCSIBlockLimits bl = {
|
|
|
|
.max_io_sectors = blk_get_max_transfer(s->conf.blk) / s->blocksize
|
|
|
|
};
|
|
|
|
|
|
|
|
memset(r->buf, 0, r->buflen);
|
|
|
|
stb_p(buf, s->type);
|
|
|
|
stb_p(buf + 1, 0xb0);
|
|
|
|
len = scsi_emulate_block_limits(buf + 4, &bl);
|
|
|
|
assert(len <= sizeof(buf) - 4);
|
|
|
|
stw_be_p(buf + 2, len);
|
|
|
|
|
|
|
|
memcpy(r->buf, buf, MIN(r->buflen, len + 4));
|
|
|
|
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
r->io_header.sb_len_wr = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We have valid contents in the reply buffer but the
|
|
|
|
* io_header can report a sense error coming from
|
|
|
|
* the hardware in scsi_command_complete_noio. Clean
|
|
|
|
* up the io_header to avoid reporting it.
|
|
|
|
*/
|
|
|
|
r->io_header.driver_status = 0;
|
|
|
|
r->io_header.status = 0;
|
|
|
|
|
|
|
|
return r->buflen;
|
|
|
|
}
|
|
|
|
|
2007-12-24 19:11:51 +03:00
|
|
|
static void scsi_read_complete(void * opaque, int ret)
|
|
|
|
{
|
2009-11-26 17:33:48 +03:00
|
|
|
SCSIGenericReq *r = (SCSIGenericReq *)opaque;
|
2011-10-13 12:36:27 +04:00
|
|
|
SCSIDevice *s = r->req.dev;
|
2007-12-24 19:11:51 +03:00
|
|
|
int len;
|
|
|
|
|
2015-07-19 20:15:26 +03:00
|
|
|
assert(r->req.aiocb != NULL);
|
2011-05-25 18:53:46 +04:00
|
|
|
r->req.aiocb = NULL;
|
2015-07-19 20:15:26 +03:00
|
|
|
|
2017-02-13 16:52:32 +03:00
|
|
|
aio_context_acquire(blk_get_aio_context(s->conf.blk));
|
|
|
|
|
2014-09-24 12:27:53 +04:00
|
|
|
if (ret || r->req.io_canceled) {
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, ret);
|
2017-02-13 16:52:32 +03:00
|
|
|
goto done;
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
2015-07-19 20:15:26 +03:00
|
|
|
|
2007-12-24 19:11:51 +03:00
|
|
|
len = r->io_header.dxfer_len - r->io_header.resid;
|
2018-12-11 19:31:05 +03:00
|
|
|
trace_scsi_generic_read_complete(r->req.tag, len);
|
2007-12-24 19:11:51 +03:00
|
|
|
|
|
|
|
r->len = -1;
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
|
2019-07-18 12:42:36 +03:00
|
|
|
if (r->io_header.driver_status & SG_ERR_DRIVER_SENSE) {
|
2018-10-23 01:58:21 +03:00
|
|
|
SCSISense sense =
|
|
|
|
scsi_parse_sense_buf(r->req.sense, r->io_header.sb_len_wr);
|
2019-07-18 12:42:36 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if this is a VPD Block Limits request that
|
|
|
|
* resulted in sense error but would need emulation.
|
|
|
|
* In this case, emulate a valid VPD response.
|
|
|
|
*/
|
|
|
|
if (sense.key == ILLEGAL_REQUEST &&
|
|
|
|
s->needs_vpd_bl_emulation &&
|
|
|
|
r->req.cmd.buf[0] == INQUIRY &&
|
|
|
|
(r->req.cmd.buf[1] & 0x01) &&
|
|
|
|
r->req.cmd.buf[2] == 0xb0) {
|
2018-10-23 01:43:51 +03:00
|
|
|
len = scsi_generic_emulate_block_limits(r, s);
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
/*
|
2019-07-18 12:42:36 +03:00
|
|
|
* It's okay to jup to req_complete: no need to
|
|
|
|
* let scsi_handle_inquiry_reply handle an
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
* INQUIRY VPD BL request we created manually.
|
|
|
|
*/
|
2019-07-18 12:42:36 +03:00
|
|
|
}
|
|
|
|
if (sense.key) {
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
goto req_complete;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-06 13:24:12 +03:00
|
|
|
if (r->io_header.host_status != SCSI_HOST_OK ||
|
|
|
|
(r->io_header.driver_status & SG_ERR_DRIVER_TIMEOUT) ||
|
|
|
|
r->io_header.status != GOOD ||
|
|
|
|
len == 0) {
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, 0);
|
2017-02-13 16:52:32 +03:00
|
|
|
goto done;
|
2015-07-19 20:15:26 +03:00
|
|
|
}
|
2011-10-13 12:36:27 +04:00
|
|
|
|
2015-07-19 20:15:26 +03:00
|
|
|
/* Snoop READ CAPACITY output to set the blocksize. */
|
|
|
|
if (r->req.cmd.buf[0] == READ_CAPACITY_10 &&
|
|
|
|
(ldl_be_p(&r->buf[0]) != 0xffffffffU || s->max_lba == 0)) {
|
|
|
|
s->blocksize = ldl_be_p(&r->buf[4]);
|
|
|
|
s->max_lba = ldl_be_p(&r->buf[0]) & 0xffffffffULL;
|
|
|
|
} else if (r->req.cmd.buf[0] == SERVICE_ACTION_IN_16 &&
|
|
|
|
(r->req.cmd.buf[1] & 31) == SAI_READ_CAPACITY_16) {
|
|
|
|
s->blocksize = ldl_be_p(&r->buf[8]);
|
|
|
|
s->max_lba = ldq_be_p(&r->buf[0]);
|
2011-05-03 16:15:59 +04:00
|
|
|
}
|
2015-07-19 20:15:26 +03:00
|
|
|
blk_set_guest_block_size(s->conf.blk, s->blocksize);
|
|
|
|
|
2020-08-12 01:51:22 +03:00
|
|
|
/*
|
|
|
|
* Patch MODE SENSE device specific parameters if the BDS is opened
|
2015-09-16 18:26:16 +03:00
|
|
|
* readonly.
|
|
|
|
*/
|
2020-08-12 01:51:22 +03:00
|
|
|
if ((s->type == TYPE_DISK || s->type == TYPE_TAPE || s->type == TYPE_ZBC) &&
|
2021-01-18 15:34:47 +03:00
|
|
|
!blk_is_writable(s->conf.blk) &&
|
2015-09-16 18:26:16 +03:00
|
|
|
(r->req.cmd.buf[0] == MODE_SENSE ||
|
|
|
|
r->req.cmd.buf[0] == MODE_SENSE_10) &&
|
|
|
|
(r->req.cmd.buf[1] & 0x8) == 0) {
|
|
|
|
if (r->req.cmd.buf[0] == MODE_SENSE) {
|
|
|
|
r->buf[2] |= 0x80;
|
|
|
|
} else {
|
|
|
|
r->buf[3] |= 0x80;
|
|
|
|
}
|
|
|
|
}
|
2018-03-28 00:14:51 +03:00
|
|
|
if (r->req.cmd.buf[0] == INQUIRY) {
|
2020-12-17 19:56:12 +03:00
|
|
|
len = scsi_handle_inquiry_reply(r, s, len);
|
2016-05-26 09:15:05 +03:00
|
|
|
}
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
|
|
|
|
req_complete:
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_req_data(&r->req, len);
|
|
|
|
scsi_req_unref(&r->req);
|
2017-02-13 16:52:32 +03:00
|
|
|
|
|
|
|
done:
|
|
|
|
aio_context_release(blk_get_aio_context(s->conf.blk));
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Read more data from scsi device into buffer. */
|
2011-04-18 14:35:39 +04:00
|
|
|
static void scsi_read_data(SCSIRequest *req)
|
2007-12-24 19:11:51 +03:00
|
|
|
{
|
2011-04-18 14:35:39 +04:00
|
|
|
SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req);
|
2011-10-12 14:49:35 +04:00
|
|
|
SCSIDevice *s = r->req.dev;
|
2007-12-24 19:11:51 +03:00
|
|
|
int ret;
|
|
|
|
|
2018-12-11 19:31:05 +03:00
|
|
|
trace_scsi_generic_read_data(req->tag);
|
2011-10-25 14:53:35 +04:00
|
|
|
|
|
|
|
/* The request is used as the AIO opaque value, so add a ref. */
|
|
|
|
scsi_req_ref(&r->req);
|
2007-12-24 19:11:51 +03:00
|
|
|
if (r->len == -1) {
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, 0);
|
2007-12-24 19:11:51 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-10-07 15:59:18 +04:00
|
|
|
ret = execute_command(s->conf.blk, r, SG_DXFER_FROM_DEV,
|
|
|
|
scsi_read_complete);
|
2011-04-18 14:53:14 +04:00
|
|
|
if (ret < 0) {
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, ret);
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void scsi_write_complete(void * opaque, int ret)
|
|
|
|
{
|
2009-11-26 17:33:48 +03:00
|
|
|
SCSIGenericReq *r = (SCSIGenericReq *)opaque;
|
2011-10-12 14:49:35 +04:00
|
|
|
SCSIDevice *s = r->req.dev;
|
2007-12-24 19:11:51 +03:00
|
|
|
|
2018-12-11 19:31:05 +03:00
|
|
|
trace_scsi_generic_write_complete(ret);
|
2015-07-19 20:15:26 +03:00
|
|
|
|
|
|
|
assert(r->req.aiocb != NULL);
|
2011-05-25 18:53:46 +04:00
|
|
|
r->req.aiocb = NULL;
|
2015-07-19 20:15:26 +03:00
|
|
|
|
2017-02-13 16:52:32 +03:00
|
|
|
aio_context_acquire(blk_get_aio_context(s->conf.blk));
|
|
|
|
|
2014-09-24 12:27:53 +04:00
|
|
|
if (ret || r->req.io_canceled) {
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, ret);
|
2017-02-13 16:52:32 +03:00
|
|
|
goto done;
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
|
2009-11-26 17:33:51 +03:00
|
|
|
if (r->req.cmd.buf[0] == MODE_SELECT && r->req.cmd.buf[4] == 12 &&
|
2011-10-12 14:49:35 +04:00
|
|
|
s->type == TYPE_TAPE) {
|
|
|
|
s->blocksize = (r->buf[9] << 16) | (r->buf[10] << 8) | r->buf[11];
|
2018-12-11 19:31:05 +03:00
|
|
|
trace_scsi_generic_write_complete_blocksize(s->blocksize);
|
2008-10-17 12:08:56 +04:00
|
|
|
}
|
|
|
|
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, ret);
|
2017-02-13 16:52:32 +03:00
|
|
|
|
|
|
|
done:
|
|
|
|
aio_context_release(blk_get_aio_context(s->conf.blk));
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Write data to a scsi device. Returns nonzero on failure.
|
|
|
|
The transfer may complete asynchronously. */
|
2011-04-22 11:39:16 +04:00
|
|
|
static void scsi_write_data(SCSIRequest *req)
|
2007-12-24 19:11:51 +03:00
|
|
|
{
|
2011-04-18 14:35:39 +04:00
|
|
|
SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req);
|
2011-10-12 14:49:35 +04:00
|
|
|
SCSIDevice *s = r->req.dev;
|
2007-12-24 19:11:51 +03:00
|
|
|
int ret;
|
|
|
|
|
2018-12-11 19:31:05 +03:00
|
|
|
trace_scsi_generic_write_data(req->tag);
|
2007-12-24 19:11:51 +03:00
|
|
|
if (r->len == 0) {
|
|
|
|
r->len = r->buflen;
|
2011-04-18 16:59:13 +04:00
|
|
|
scsi_req_data(&r->req, r->len);
|
2011-04-22 11:39:16 +04:00
|
|
|
return;
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
|
2011-10-25 14:53:35 +04:00
|
|
|
/* The request is used as the AIO opaque value, so add a ref. */
|
|
|
|
scsi_req_ref(&r->req);
|
2014-10-07 15:59:18 +04:00
|
|
|
ret = execute_command(s->conf.blk, r, SG_DXFER_TO_DEV, scsi_write_complete);
|
2011-04-18 14:53:14 +04:00
|
|
|
if (ret < 0) {
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, ret);
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return a pointer to the data buffer. */
|
2011-04-18 14:35:39 +04:00
|
|
|
static uint8_t *scsi_get_buf(SCSIRequest *req)
|
2007-12-24 19:11:51 +03:00
|
|
|
{
|
2011-04-18 14:35:39 +04:00
|
|
|
SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req);
|
|
|
|
|
2007-12-24 19:11:51 +03:00
|
|
|
return r->buf;
|
|
|
|
}
|
|
|
|
|
2018-12-11 19:31:05 +03:00
|
|
|
static void scsi_generic_command_dump(uint8_t *cmd, int len)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
char *line_buffer, *p;
|
|
|
|
|
|
|
|
line_buffer = g_malloc(len * 5 + 1);
|
|
|
|
|
|
|
|
for (i = 0, p = line_buffer; i < len; i++) {
|
|
|
|
p += sprintf(p, " 0x%02x", cmd[i]);
|
|
|
|
}
|
|
|
|
trace_scsi_generic_send_command(line_buffer);
|
|
|
|
|
|
|
|
g_free(line_buffer);
|
|
|
|
}
|
|
|
|
|
2007-12-24 19:11:51 +03:00
|
|
|
/* Execute a scsi command. Returns the length of the data expected by the
|
|
|
|
command. This will be Positive for data transfers from the device
|
|
|
|
(eg. disk reads), negative for transfers to the device (eg. disk writes),
|
|
|
|
and zero if the command does not transfer any data. */
|
|
|
|
|
2011-04-18 14:35:39 +04:00
|
|
|
static int32_t scsi_send_command(SCSIRequest *req, uint8_t *cmd)
|
2007-12-24 19:11:51 +03:00
|
|
|
{
|
2011-04-18 14:35:39 +04:00
|
|
|
SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req);
|
2011-10-12 14:49:35 +04:00
|
|
|
SCSIDevice *s = r->req.dev;
|
2007-12-24 19:11:51 +03:00
|
|
|
int ret;
|
|
|
|
|
2018-12-11 19:31:05 +03:00
|
|
|
if (trace_event_get_state_backends(TRACE_SCSI_GENERIC_SEND_COMMAND)) {
|
|
|
|
scsi_generic_command_dump(cmd, r->req.cmd.len);
|
2010-09-01 18:33:21 +04:00
|
|
|
}
|
2007-12-24 19:11:51 +03:00
|
|
|
|
2009-11-26 17:33:55 +03:00
|
|
|
if (r->req.cmd.xfer == 0) {
|
2014-12-04 16:12:43 +03:00
|
|
|
g_free(r->buf);
|
2007-12-24 19:11:51 +03:00
|
|
|
r->buflen = 0;
|
|
|
|
r->buf = NULL;
|
2011-10-25 14:53:35 +04:00
|
|
|
/* The request is used as the AIO opaque value, so add a ref. */
|
|
|
|
scsi_req_ref(&r->req);
|
2014-10-07 15:59:18 +04:00
|
|
|
ret = execute_command(s->conf.blk, r, SG_DXFER_NONE,
|
|
|
|
scsi_command_complete);
|
2011-04-18 14:53:14 +04:00
|
|
|
if (ret < 0) {
|
2015-07-19 20:15:26 +03:00
|
|
|
scsi_command_complete_noio(r, ret);
|
2011-04-18 14:53:14 +04:00
|
|
|
return 0;
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-11-26 17:33:55 +03:00
|
|
|
if (r->buflen != r->req.cmd.xfer) {
|
2014-12-04 16:12:43 +03:00
|
|
|
g_free(r->buf);
|
2011-08-21 07:09:37 +04:00
|
|
|
r->buf = g_malloc(r->req.cmd.xfer);
|
2009-11-26 17:33:55 +03:00
|
|
|
r->buflen = r->req.cmd.xfer;
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
memset(r->buf, 0, r->buflen);
|
2009-11-26 17:33:55 +03:00
|
|
|
r->len = r->req.cmd.xfer;
|
2009-11-26 17:33:57 +03:00
|
|
|
if (r->req.cmd.mode == SCSI_XFER_TO_DEV) {
|
2007-12-24 19:11:51 +03:00
|
|
|
r->len = 0;
|
2011-04-18 14:35:39 +04:00
|
|
|
return -r->req.cmd.xfer;
|
2011-04-18 18:01:56 +04:00
|
|
|
} else {
|
2011-04-18 14:35:39 +04:00
|
|
|
return r->req.cmd.xfer;
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-12 14:29:57 +03:00
|
|
|
static int read_naa_id(const uint8_t *p, uint64_t *p_wwn)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if ((p[1] & 0xF) == 3) {
|
|
|
|
/* NAA designator type */
|
|
|
|
if (p[3] != 8) {
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
*p_wwn = ldq_be_p(p + 4);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((p[1] & 0xF) == 8) {
|
|
|
|
/* SCSI name string designator type */
|
|
|
|
if (p[3] < 20 || memcmp(&p[4], "naa.", 4)) {
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (p[3] > 20 && p[24] != ',') {
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
*p_wwn = 0;
|
|
|
|
for (i = 8; i < 24; i++) {
|
2017-07-20 19:31:30 +03:00
|
|
|
char c = qemu_toupper(p[i]);
|
2016-01-12 14:29:57 +03:00
|
|
|
c -= (c >= '0' && c <= '9' ? '0' : 'A' - 10);
|
|
|
|
*p_wwn = (*p_wwn << 4) | c;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2018-06-27 20:24:31 +03:00
|
|
|
int scsi_SG_IO_FROM_DEV(BlockBackend *blk, uint8_t *cmd, uint8_t cmd_size,
|
2020-11-16 21:31:13 +03:00
|
|
|
uint8_t *buf, uint8_t buf_size, uint32_t timeout)
|
2016-01-12 14:29:57 +03:00
|
|
|
{
|
|
|
|
sg_io_hdr_t io_header;
|
2018-06-27 20:24:31 +03:00
|
|
|
uint8_t sensebuf[8];
|
2016-01-12 14:29:57 +03:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
memset(&io_header, 0, sizeof(io_header));
|
|
|
|
io_header.interface_id = 'S';
|
|
|
|
io_header.dxfer_direction = SG_DXFER_FROM_DEV;
|
2018-06-27 20:24:31 +03:00
|
|
|
io_header.dxfer_len = buf_size;
|
2016-01-12 14:29:57 +03:00
|
|
|
io_header.dxferp = buf;
|
|
|
|
io_header.cmdp = cmd;
|
2018-06-27 20:24:31 +03:00
|
|
|
io_header.cmd_len = cmd_size;
|
2016-01-12 14:29:57 +03:00
|
|
|
io_header.mx_sb_len = sizeof(sensebuf);
|
|
|
|
io_header.sbp = sensebuf;
|
2020-11-16 21:31:13 +03:00
|
|
|
io_header.timeout = timeout * 1000;
|
2016-01-12 14:29:57 +03:00
|
|
|
|
2020-11-16 21:31:14 +03:00
|
|
|
trace_scsi_generic_ioctl_sgio_command(cmd[0], io_header.timeout);
|
2018-06-27 20:24:31 +03:00
|
|
|
ret = blk_ioctl(blk, SG_IO, &io_header);
|
2020-11-16 21:31:14 +03:00
|
|
|
if (ret < 0 || io_header.status ||
|
|
|
|
io_header.driver_status || io_header.host_status) {
|
|
|
|
trace_scsi_generic_ioctl_sgio_done(cmd[0], ret, io_header.status,
|
|
|
|
io_header.host_status);
|
2018-06-27 20:24:31 +03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
/*
|
|
|
|
* Executes an INQUIRY request with EVPD set to retrieve the
|
|
|
|
* available VPD pages of the device. If the device does
|
|
|
|
* not support the Block Limits page (page 0xb0), set
|
|
|
|
* the needs_vpd_bl_emulation flag for future use.
|
|
|
|
*/
|
|
|
|
static void scsi_generic_set_vpd_bl_emulation(SCSIDevice *s)
|
|
|
|
{
|
|
|
|
uint8_t cmd[6];
|
|
|
|
uint8_t buf[250];
|
|
|
|
uint8_t page_len;
|
|
|
|
int ret, i;
|
|
|
|
|
|
|
|
memset(cmd, 0, sizeof(cmd));
|
|
|
|
memset(buf, 0, sizeof(buf));
|
|
|
|
cmd[0] = INQUIRY;
|
|
|
|
cmd[1] = 1;
|
|
|
|
cmd[2] = 0x00;
|
|
|
|
cmd[4] = sizeof(buf);
|
|
|
|
|
|
|
|
ret = scsi_SG_IO_FROM_DEV(s->conf.blk, cmd, sizeof(cmd),
|
2020-11-16 21:31:13 +03:00
|
|
|
buf, sizeof(buf), s->io_timeout);
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
/*
|
|
|
|
* Do not assume anything if we can't retrieve the
|
|
|
|
* INQUIRY response to assert the VPD Block Limits
|
|
|
|
* support.
|
|
|
|
*/
|
|
|
|
s->needs_vpd_bl_emulation = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
page_len = buf[3];
|
2018-10-23 01:58:43 +03:00
|
|
|
for (i = 4; i < MIN(sizeof(buf), page_len + 4); i++) {
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
if (buf[i] == 0xb0) {
|
|
|
|
s->needs_vpd_bl_emulation = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
s->needs_vpd_bl_emulation = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void scsi_generic_read_device_identification(SCSIDevice *s)
|
2018-06-27 20:24:31 +03:00
|
|
|
{
|
|
|
|
uint8_t cmd[6];
|
|
|
|
uint8_t buf[250];
|
|
|
|
int ret;
|
|
|
|
int i, len;
|
|
|
|
|
|
|
|
memset(cmd, 0, sizeof(cmd));
|
|
|
|
memset(buf, 0, sizeof(buf));
|
|
|
|
cmd[0] = INQUIRY;
|
|
|
|
cmd[1] = 1;
|
|
|
|
cmd[2] = 0x83;
|
|
|
|
cmd[4] = sizeof(buf);
|
|
|
|
|
|
|
|
ret = scsi_SG_IO_FROM_DEV(s->conf.blk, cmd, sizeof(cmd),
|
2020-11-16 21:31:13 +03:00
|
|
|
buf, sizeof(buf), s->io_timeout);
|
2018-06-27 20:24:31 +03:00
|
|
|
if (ret < 0) {
|
2016-01-12 14:29:57 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
len = MIN((buf[2] << 8) | buf[3], sizeof(buf) - 4);
|
|
|
|
for (i = 0; i + 3 <= len; ) {
|
|
|
|
const uint8_t *p = &buf[i + 4];
|
|
|
|
uint64_t wwn;
|
|
|
|
|
|
|
|
if (i + (p[3] + 4) > len) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((p[1] & 0x10) == 0) {
|
|
|
|
/* Associated with the logical unit */
|
|
|
|
if (read_naa_id(p, &wwn) == 0) {
|
|
|
|
s->wwn = wwn;
|
|
|
|
}
|
|
|
|
} else if ((p[1] & 0x10) == 0x10) {
|
|
|
|
/* Associated with the target port */
|
|
|
|
if (read_naa_id(p, &wwn) == 0) {
|
|
|
|
s->port_wwn = wwn;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
i += p[3] + 4;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
void scsi_generic_read_device_inquiry(SCSIDevice *s)
|
|
|
|
{
|
|
|
|
scsi_generic_read_device_identification(s);
|
2020-08-12 01:51:22 +03:00
|
|
|
if (s->type == TYPE_DISK || s->type == TYPE_ZBC) {
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
scsi_generic_set_vpd_bl_emulation(s);
|
|
|
|
} else {
|
|
|
|
s->needs_vpd_bl_emulation = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-07 15:59:18 +04:00
|
|
|
static int get_stream_blocksize(BlockBackend *blk)
|
2008-10-17 12:08:56 +04:00
|
|
|
{
|
|
|
|
uint8_t cmd[6];
|
|
|
|
uint8_t buf[12];
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
memset(cmd, 0, sizeof(cmd));
|
|
|
|
memset(buf, 0, sizeof(buf));
|
|
|
|
cmd[0] = MODE_SENSE;
|
|
|
|
cmd[4] = sizeof(buf);
|
|
|
|
|
2020-11-16 21:31:13 +03:00
|
|
|
ret = scsi_SG_IO_FROM_DEV(blk, cmd, sizeof(cmd), buf, sizeof(buf), 6);
|
2018-06-27 20:24:31 +03:00
|
|
|
if (ret < 0) {
|
2008-10-17 12:08:56 +04:00
|
|
|
return -1;
|
2011-10-12 16:49:48 +04:00
|
|
|
}
|
2018-06-27 20:24:31 +03:00
|
|
|
|
2008-10-17 12:08:56 +04:00
|
|
|
return (buf[9] << 16) | (buf[10] << 8) | buf[11];
|
|
|
|
}
|
|
|
|
|
2010-09-06 18:07:33 +04:00
|
|
|
static void scsi_generic_reset(DeviceState *dev)
|
|
|
|
{
|
2011-12-16 00:50:08 +04:00
|
|
|
SCSIDevice *s = SCSI_DEVICE(dev);
|
2010-09-06 18:07:33 +04:00
|
|
|
|
2018-04-05 19:09:51 +03:00
|
|
|
s->scsi_version = s->default_scsi_version;
|
2011-10-12 14:49:35 +04:00
|
|
|
scsi_device_purge_requests(s, SENSE_CODE(RESET));
|
2010-09-06 18:07:33 +04:00
|
|
|
}
|
|
|
|
|
2014-08-12 06:12:55 +04:00
|
|
|
static void scsi_generic_realize(SCSIDevice *s, Error **errp)
|
2007-12-24 19:11:51 +03:00
|
|
|
{
|
2014-04-28 14:14:57 +04:00
|
|
|
int rc;
|
2007-12-24 19:11:51 +03:00
|
|
|
int sg_version;
|
|
|
|
struct sg_scsi_id scsiid;
|
|
|
|
|
2014-10-07 15:59:18 +04:00
|
|
|
if (!s->conf.blk) {
|
2014-08-12 06:12:55 +04:00
|
|
|
error_setg(errp, "drive property not set");
|
|
|
|
return;
|
2009-08-31 16:24:04 +04:00
|
|
|
}
|
2007-12-24 19:11:51 +03:00
|
|
|
|
2020-11-03 09:12:40 +03:00
|
|
|
if (blk_get_on_error(s->conf.blk, 0) != BLOCKDEV_ON_ERROR_ENOSPC &&
|
|
|
|
blk_get_on_error(s->conf.blk, 0) != BLOCKDEV_ON_ERROR_REPORT) {
|
2014-08-12 06:12:55 +04:00
|
|
|
error_setg(errp, "Device doesn't support drive option werror");
|
|
|
|
return;
|
2010-05-27 22:02:28 +04:00
|
|
|
}
|
2014-10-07 15:59:18 +04:00
|
|
|
if (blk_get_on_error(s->conf.blk, 1) != BLOCKDEV_ON_ERROR_REPORT) {
|
2014-08-12 06:12:55 +04:00
|
|
|
error_setg(errp, "Device doesn't support drive option rerror");
|
|
|
|
return;
|
2010-05-27 22:02:28 +04:00
|
|
|
}
|
|
|
|
|
2007-12-24 19:11:51 +03:00
|
|
|
/* check we are using a driver managing SG_IO (version 3 and after */
|
2014-10-07 15:59:18 +04:00
|
|
|
rc = blk_ioctl(s->conf.blk, SG_GET_VERSION_NUM, &sg_version);
|
2014-04-28 14:14:57 +04:00
|
|
|
if (rc < 0) {
|
2018-03-21 13:57:26 +03:00
|
|
|
error_setg_errno(errp, -rc, "cannot get SG_IO version number");
|
|
|
|
if (rc != -EPERM) {
|
|
|
|
error_append_hint(errp, "Is this a SCSI device?\n");
|
|
|
|
}
|
2014-08-12 06:12:55 +04:00
|
|
|
return;
|
ISCSI: Add SCSI passthrough via scsi-generic to libiscsi
Update iscsi to allow passthrough of SG_IO scsi commands when the iscsi
device is forced to be scsi-generic.
Implement both bdrv_ioctl() and bdrv_aio_ioctl() in the iscsi backend,
emulate the SG_IO ioctl and pass the SCSI commands across to the
iscsi target.
This allows end-to-end passthrough of SCSI all the way from the guest,
to qemu, via scsi-generic, then libiscsi all the way to the iscsi target.
To activate this you need to specify that the iscsi lun should be treated
as a scsi-generic device.
Example:
-device lsi -device scsi-generic,drive=MyISCSI \
-drive file=iscsi://10.1.1.125/iqn.ronnie.test/1,if=none,id=MyISCSI
Note, you can currently not boot a qemu guest from a scsi device.
Note,
This only works when the host is linux, since the emulation relies on
definitions of SG_IO from the scsi-generic implementation in the
linux kernel.
It should be fairly easy to re-implement some structures similar enough
for non-linux hosts to do the same style of passthrough via a fake
scsi generic layer and libiscsi if need be.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-05-25 15:59:01 +04:00
|
|
|
}
|
|
|
|
if (sg_version < 30000) {
|
2014-08-12 06:12:55 +04:00
|
|
|
error_setg(errp, "scsi generic interface too old");
|
|
|
|
return;
|
2009-08-31 16:24:04 +04:00
|
|
|
}
|
2007-12-24 19:11:51 +03:00
|
|
|
|
|
|
|
/* get LUN of the /dev/sg? */
|
2014-10-07 15:59:18 +04:00
|
|
|
if (blk_ioctl(s->conf.blk, SG_GET_SCSI_ID, &scsiid)) {
|
2014-08-12 06:12:55 +04:00
|
|
|
error_setg(errp, "SG_GET_SCSI_ID ioctl failed");
|
|
|
|
return;
|
2009-08-31 16:24:04 +04:00
|
|
|
}
|
2018-01-18 05:52:45 +03:00
|
|
|
if (!blkconf_apply_backend_options(&s->conf,
|
2021-01-18 15:34:47 +03:00
|
|
|
!blk_supports_write_perm(s->conf.blk),
|
2018-01-18 05:52:45 +03:00
|
|
|
true, errp)) {
|
2017-12-05 18:15:53 +03:00
|
|
|
return;
|
|
|
|
}
|
2007-12-24 19:11:51 +03:00
|
|
|
|
|
|
|
/* define device state */
|
2011-10-12 14:49:35 +04:00
|
|
|
s->type = scsiid.scsi_type;
|
2018-12-11 19:31:05 +03:00
|
|
|
trace_scsi_generic_realize_type(s->type);
|
2011-11-18 19:32:02 +04:00
|
|
|
|
2011-10-13 12:36:27 +04:00
|
|
|
switch (s->type) {
|
|
|
|
case TYPE_TAPE:
|
2014-10-07 15:59:18 +04:00
|
|
|
s->blocksize = get_stream_blocksize(s->conf.blk);
|
2011-10-12 14:49:35 +04:00
|
|
|
if (s->blocksize == -1) {
|
|
|
|
s->blocksize = 0;
|
|
|
|
}
|
2011-10-13 12:36:27 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
/* Make a guess for block devices, we'll fix it when the guest sends.
|
|
|
|
* READ CAPACITY. If they don't, they likely would assume these sizes
|
|
|
|
* anyway. (TODO: they could also send MODE SENSE).
|
|
|
|
*/
|
|
|
|
case TYPE_ROM:
|
|
|
|
case TYPE_WORM:
|
|
|
|
s->blocksize = 2048;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
s->blocksize = 512;
|
|
|
|
break;
|
2008-10-17 12:08:56 +04:00
|
|
|
}
|
2011-10-12 14:49:35 +04:00
|
|
|
|
2018-12-11 19:31:05 +03:00
|
|
|
trace_scsi_generic_realize_blocksize(s->blocksize);
|
2016-01-12 14:29:57 +03:00
|
|
|
|
2018-03-28 00:14:51 +03:00
|
|
|
/* Only used by scsi-block, but initialize it nevertheless to be clean. */
|
|
|
|
s->default_scsi_version = -1;
|
2020-11-16 21:31:13 +03:00
|
|
|
s->io_timeout = DEFAULT_IO_TIMEOUT;
|
hw/scsi: add VPD Block Limits emulation
The VPD Block Limits Inquiry page is optional, allowing SCSI devices
to not implement it. This is the case for devices like the MegaRAID
SAS 9361-8i and Microsemi PM8069.
In case of SCSI passthrough, the response of this request is used by
the QEMU SCSI layer to set the max_io_sectors that the guest
device will support, based on the value of the max_sectors_kb that
the device has set in the host at that time. Without this response,
the guest kernel is free to assume any value of max_io_sectors
for the SCSI device. If this value is greater than the value from
the host, SCSI Sense errors will occur because the guest will send
read/write requests that are larger than the underlying host device
is configured to support. An example of this behavior can be seen
in [1].
A workaround is to set the max_sectors_kb host value back in the guest
kernel (a process that can be automated using rc.local startup scripts
and the like), but this has several drawbacks:
- it can be troublesome if the guest has many passthrough devices that
needs this tuning;
- if a change in max_sectors_kb is made in the host side, manual change
in the guests will also be required;
- during an OS install it is difficult, and sometimes not possible, to
go to a terminal and change the max_sectors_kb prior to the installation.
This means that the disk can't be used during the install process. The
easiest alternative here is to roll back to scsi-hd, install the guest
and then go back to SCSI passthrough when the installation is done and
max_sectors_kb can be set.
An easier way would be to QEMU handle the absence of the Block Limits
VPD device response, setting max_io_sectors accordingly and allowing
the guest to use the device without the hassle.
This patch adds emulation of the Block Limits VPD response for
SCSI passthrough devices of type TYPE_DISK that doesn't support
it. The following changes were made:
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply. In case the device does not
- a new function called scsi_generic_set_vpd_bl_emulation,
that is called during device realize, was created to set a
new flag 'needs_vpd_bl_emulation' of the device. This function
retrieves the Inquiry EVPD response of the device to check for
VPD BL support.
- scsi_handle_inquiry_reply will now check the available VPD
pages from the Inquiry EVPD reply in case the device needs
VPD BL emulation, adding the Block Limits page (0xb0) to
the list. This will make the guest kernel aware of the
support that we're now providing by emulation.
- a new function scsi_emulate_block_limits creates the
emulated Block Limits response. This function is called
inside scsi_read_complete in case the device requires
Block Limits VPD emulation and we detected a SCSI Sense
error in the VPD Block Limits reply that was issued
from the guest kernel to the device. This error is
expected: we're reporting support from our side, but
the device isn't aware of it.
With this patch, the guest now queries the Block Limits
page during the device configuration because it is being
advertised in the Supported Pages response. It will either
receive the Block Limits page from the hardware, if it supports
it, or will receive an emulated response from QEMU. At any rate,
the guest now has the information to set the max_sectors_kb
parameter accordingly, sparing the user of SCSI sense errors
that would happen without the emulated response and in the
absence of Block Limits support from the hardware.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1566195
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20180627172432.11120-4-danielhb413@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-27 20:24:32 +03:00
|
|
|
scsi_generic_read_device_inquiry(s);
|
2009-08-31 16:24:04 +04:00
|
|
|
}
|
2007-12-24 19:11:51 +03:00
|
|
|
|
2011-10-12 14:54:31 +04:00
|
|
|
const SCSIReqOps scsi_generic_req_ops = {
|
2011-08-03 12:49:08 +04:00
|
|
|
.size = sizeof(SCSIGenericReq),
|
2011-08-03 12:49:09 +04:00
|
|
|
.free_req = scsi_free_request,
|
|
|
|
.send_command = scsi_send_command,
|
|
|
|
.read_data = scsi_read_data,
|
|
|
|
.write_data = scsi_write_data,
|
|
|
|
.get_buf = scsi_get_buf,
|
2011-12-15 16:24:30 +04:00
|
|
|
.load_request = scsi_generic_load_request,
|
|
|
|
.save_request = scsi_generic_save_request,
|
2011-08-03 12:49:08 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static SCSIRequest *scsi_new_request(SCSIDevice *d, uint32_t tag, uint32_t lun,
|
2011-10-12 14:58:31 +04:00
|
|
|
uint8_t *buf, void *hba_private)
|
2011-08-03 12:49:08 +04:00
|
|
|
{
|
2016-06-14 00:57:58 +03:00
|
|
|
return scsi_req_alloc(&scsi_generic_req_ops, d, tag, lun, hba_private);
|
2011-08-03 12:49:08 +04:00
|
|
|
}
|
|
|
|
|
2011-12-08 07:34:16 +04:00
|
|
|
static Property scsi_generic_properties[] = {
|
2014-10-07 15:59:18 +04:00
|
|
|
DEFINE_PROP_DRIVE("drive", SCSIDevice, conf.blk),
|
2017-12-05 18:15:53 +03:00
|
|
|
DEFINE_PROP_BOOL("share-rw", SCSIDevice, conf.share_rw, false),
|
2020-11-16 21:31:13 +03:00
|
|
|
DEFINE_PROP_UINT32("io_timeout", SCSIDevice, io_timeout,
|
|
|
|
DEFAULT_IO_TIMEOUT),
|
2011-12-08 07:34:16 +04:00
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
2014-07-16 14:22:26 +04:00
|
|
|
static int scsi_generic_parse_cdb(SCSIDevice *dev, SCSICommand *cmd,
|
|
|
|
uint8_t *buf, void *hba_private)
|
|
|
|
{
|
|
|
|
return scsi_bus_parse_cdb(dev, cmd, buf, hba_private);
|
|
|
|
}
|
|
|
|
|
2011-12-16 00:50:08 +04:00
|
|
|
static void scsi_generic_class_initfn(ObjectClass *klass, void *data)
|
|
|
|
{
|
2011-12-08 07:34:16 +04:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
2011-12-16 00:50:08 +04:00
|
|
|
SCSIDeviceClass *sc = SCSI_DEVICE_CLASS(klass);
|
|
|
|
|
2014-08-12 06:12:55 +04:00
|
|
|
sc->realize = scsi_generic_realize;
|
2011-12-16 00:50:08 +04:00
|
|
|
sc->alloc_req = scsi_new_request;
|
2014-07-16 14:22:26 +04:00
|
|
|
sc->parse_cdb = scsi_generic_parse_cdb;
|
2011-12-08 07:34:16 +04:00
|
|
|
dc->fw_name = "disk";
|
|
|
|
dc->desc = "pass through generic scsi device (/dev/sg*)";
|
|
|
|
dc->reset = scsi_generic_reset;
|
2020-01-10 18:30:32 +03:00
|
|
|
device_class_set_props(dc, scsi_generic_properties);
|
2011-12-15 16:24:30 +04:00
|
|
|
dc->vmsd = &vmstate_scsi_device;
|
2011-12-16 00:50:08 +04:00
|
|
|
}
|
|
|
|
|
2013-01-10 19:19:07 +04:00
|
|
|
static const TypeInfo scsi_generic_info = {
|
2011-12-08 07:34:16 +04:00
|
|
|
.name = "scsi-generic",
|
|
|
|
.parent = TYPE_SCSI_DEVICE,
|
|
|
|
.instance_size = sizeof(SCSIDevice),
|
|
|
|
.class_init = scsi_generic_class_initfn,
|
2009-08-31 16:24:04 +04:00
|
|
|
};
|
2007-12-24 19:11:51 +03:00
|
|
|
|
2012-02-09 18:20:55 +04:00
|
|
|
static void scsi_generic_register_types(void)
|
2009-08-31 16:24:04 +04:00
|
|
|
{
|
2011-12-08 07:34:16 +04:00
|
|
|
type_register_static(&scsi_generic_info);
|
2007-12-24 19:11:51 +03:00
|
|
|
}
|
2012-02-09 18:20:55 +04:00
|
|
|
|
|
|
|
type_init(scsi_generic_register_types)
|
2009-08-31 16:24:04 +04:00
|
|
|
|
2007-12-24 19:11:51 +03:00
|
|
|
#endif /* __linux__ */
|