Largely based on <scsi/scsi.h> from linux. Added into the tree so we
can use the defines everywhere, not just in scsi-generic.c (which is
linux-specific).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Create generic functions to allocate, find and release SCSIRequest
structs. Make scsi-disk and scsi-generic use them.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Changes:
* Move from open-coded lists to QTAILQ macros.
* Move the struct elements to the common data structures
(SCSIDevice + SCSIRequest).
* Drop free request pools.
* Fix request cleanup in the destroy callback.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Rename the SCSIRequest structs in scsi-disk.c and scsi-generic.c to
SCSIDiskReq and SCSIGenericReq. Create a SCSIRequest struct and move
the common elements over.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The SCSI-2 documentation suggests, that although the block
descriptor is optional for an arbitrary SCSI-2 device (chapter 8.2.10,
http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2/SCSI2-08.html )
it is mandatory for a disk: chapters 9.1.2, 9.3.3
( http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-09.html ) don't say
"optional" any more, just "The block descriptor in the MODE SENSE
data describes the block lengths that are used on the medium."
v2: limit the number of sectors reported in the block descriptor to 24 bits.
Signed-off-by: Artyom Tarasenko <atar4qemu@gmail.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Changes:
* drive_uninit() wants a DriveInfo now.
* drive_uninit() also calls bdrv_delete(),
so callers don't need to do that.
* drive_uninit() calls are moved over to the ->exit()
callbacks, destroy_bdrvs() is zapped.
* setting bdrv->private is not needed any more as the
only user (destroy_bdrvs) is gone.
* usb-storage needs no drive_uninit, scsi-disk will
handle that.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add a enable_write_cache flag in the block driver state, and use it to
decide if we claim to have a volatile write cache that needs controlled
flushing from the guest. The flag is off if cache=writethrough is
defined because O_DSYNC guarantees that every write goes to stable
storage, and it is on for cache=none and cache=writeback.
Both scsi-disk and ide now use the new flage, changing from their
defaults of always off (ide) or always on (scsi-disk).
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When a VM state change handler changes VM state, other VM state change
handlers can see the state transitions out of order.
bmdma_map(), scsi_disk_init() and virtio_blk_init() install VM state
change handlers to restart DMA. These handlers can vm_stop() by
running into a write error on a drive with werror=stop. This throws
the VM state change handler callback into disarray. Here's an example
case I observed:
0. The virtual IDE drive goes south. All future writes return errors.
1. Something encounters a write error, and duly stops the VM with
vm_stop().
2. vm_stop() calls vm_state_notify(0).
3. vm_state_notify() runs the callbacks in list vm_change_state_head.
It contains ide_dma_restart_cb() installed by bmdma_map(). It also
contains audio_vm_change_state_handler() installed by audio_init().
4. audio_vm_change_state_handler() stops audio stuff.
5. User continues VM with monitor command "c". This runs vm_start().
6. vm_start() calls vm_state_notify(1).
7. vm_state_notify() runs the callbacks in vm_change_state_head.
8. ide_dma_restart_cb() happens to come first. It does its work, runs
into a write error, and duly stops the VM with vm_stop().
9. vm_stop() runs vm_state_notify(0).
10. vm_state_notify() runs the callbacks in vm_change_state_head.
11. audio_vm_change_state_handler() stops audio stuff. Which isn't
running.
12. vm_stop() finishes, ide_dma_restart_cb() finishes, step 7's
vm_state_notify() resumes running handlers.
13. audio_vm_change_state_handler() starts audio stuff. Oopsie.
Fix this by moving the actual write from each VM state change handler
into a new bottom half (suggested by Gleb Natapov).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
I used the following command to enable debugging:
perl -p -i -e 's/^\/\/#define DEBUG/#define DEBUG/g' * */* */*/*
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Always use the vectored APIs to reduce code churn once we switch the BlockDriver
API to be vectored.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7019 c046a42c-6fe2-441c-8c8c-71466251a162
Implement Test Unit Ready command (return NOT READY as above
if !bdrv_is_inserted(...))
Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6954 c046a42c-6fe2-441c-8c8c-71466251a162
Add asc 0x3a, ascq 0: Medium not present to NOT READY sense
(needed to keep some guests from retrying causing long sleeps in the
kernel)
Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6953 c046a42c-6fe2-441c-8c8c-71466251a162
The bdrv layer uses a signed offset. Furthermore, block-raw-posix
only seeks when that offset is positive. Passing a negative offset
to block-raw-posix can result in data being written at the current
seek cursor's position.
It may be possible to exploit this to seek to the end of the disk
and extend the virtual disk by writing data to a negative sector
offset. After a reboot, this could lead to the guest having a
larger disk than it had before.
Close the hole by sanity checking the lba against the size of the
disk.
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6475 c046a42c-6fe2-441c-8c8c-71466251a162
Paul Brook pointed out that the number of sectors reported
by the SCSI read capacity commands needs to be divided by
s->cluster_size, because bdrv_get_geometry reports the number
of 512 byte sectors, while emulated CDROMs report 2048 byte
sectors back to the guest.
This has no consequences for emulated hard disks, which use
a cluster size of 1.
aliguori: fixed typo
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6469 c046a42c-6fe2-441c-8c8c-71466251a162
Implement SCSI READ(16), WRITE(16) and SAI READ CAPACITY(16) commands,
so SCSI disks larger than 2TB can work with guests that support these
newer SCSI commands.
The cast to (uint64_t) is needed because otherwise gcc will use a
signed int, which gets sign extended into uint64_t lba, resulting
in bad block numbers for READ 10 and READ 16 with block numbers
larger than 2^31.
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6468 c046a42c-6fe2-441c-8c8c-71466251a162
Sector numbers can overflow on a virtual scsi disk of over 1TB
in size. Qemu's bdrv_read expects an int64_t, so fix the overflow
by going to that data type.
On large disks, we clip the capacity to 2TB instead of returning
"capacity modulo 2TB".
Turn sector_count into an unsigned to prevent a signed/unsigned
overflow with SCSI transfers larger than 2TB. We're unlikely to
ever hit this bug, but fixing it is just one line.
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6467 c046a42c-6fe2-441c-8c8c-71466251a162
Windows calculates HW "uniqueness" based on a hard drive serial number
among other things. The patch allows to specify drive serial number
from a command line.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6214 c046a42c-6fe2-441c-8c8c-71466251a162
Openserver 5.0.5 sends an Inquiry command to the emulated SCSI disk
expecting a response length of 40 bytes. Currently the response to an
Inquiry command is hardcoded to 36 bytes. When receiving a response of
length 36 instead of 40 Openserver panics.
Modifications to original patch based on feedback from Ryan Harper and Paul
Brook. Thanks guys.
Signed-off-by: Justin Chevrier <address@hidden>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5903 c046a42c-6fe2-441c-8c8c-71466251a162
taken from Xen 17267:f4a92f0db20f, original patch by Samuel Thibault.
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5385 c046a42c-6fe2-441c-8c8c-71466251a162
