commit bf011293fa made virtio-blk-pci not
PCI-compliant, since it makes region 0 (which is an i/o region)
size > 256, and, since PCI 2.1, i/o regions are limited to 256 bytes size.
When the ATA serial number feature is off, which is the default,
make the device spec compliant again, by making region 0 smaller.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reported-by: Vadim Rozenfeld <vrozenfe@redhat.com>
Tested-by: Vadim Rozenfeld <vrozenfe@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
It is quite common for virtio-blk to submit more than one write request in a
row to the qemu block layer. Use bdrv_aio_multiwrite to allow block drivers to
optimize its handling of the requests.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The bdrv_aio_{read,write} routines can return a NULL pointer when the
I/O submission fails. Currently we ignore this and will wait forever
for an I/O completion and leading to a hang of the guest.
I can easily reproduce this using the native Linux AIO patch, but it's
also possible using normal pthreads-based AIO.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
First user of the new drive property. With this patch applied host
and guest config can be specified separately, like this:
-drive if=none,id=disk1,file=/path/to/disk.img
-device virtio-blk-pci,drive=disk1
You can set any property for virtio-blk-pci now. You can set the pci
address via addr=. You can switch the device into 0.10 compat mode
using class=0x0180. As this is per device you can have one 0.10 and one
0.11 virtio block device in a single virtual machine.
Old syntax continues to work. Internally it does the same as the two
lines above though. One side effect this has is a different
initialization order, which might result in a different pci address
being assigned by default.
Long term plan here is to have this working for all block devices, i.e.
once all scsi is properly qdev-ified you will be able to do something
like this:
-drive if=none,id=sda,file=/path/to/disk.img
-device lsi,id=lsi,addr=<pciaddr>
-device scsi-disk,drive=sda,bus=lsi.0,lun=<n>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-Id:
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>
[brought forward to current qemu-kvm.git]
This patch implements the missing qemu logic to
interpret a '-drive .. serial=XYZ ..' flag for
a virtio_blk device.
The serial number string is contained in a
skeletal IDENTIFY DEVICE data structure and
this structure is made available to the guest
virtio_blk driver via pci i/o region 0.
Signed-off-by: john cooper <john.cooper@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
[had the qemu list address wrong the first time, reply to this message,
not the previous if you were on Cc]
Add support for SG_IO passthru (packet commands) to the virtio-blk
backend. Conceptually based on an older patch from Hannes Reinecke
but largely rewritten to match the code structure and layering in
virtio-blk.
Note that currently we issue the hose SG_IO synchronously. We could
easily switch to async I/O, but that would required either bloating
the VirtIOBlockReq by the size of struct sg_io_hdr or an additional
memory allocation for each SG_IO request.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Use the generic bdrv_aio_readv/bdrv_aio_writev APIs instead of linearizing
buffers directly. This enables using the future native preadv/pwritev
support.
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@6903 c046a42c-6fe2-441c-8c8c-71466251a162
Record PCIDev on the BlockDriverState structure to locate for release
on hot-removal.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6597 c046a42c-6fe2-441c-8c8c-71466251a162
This patch adds and uses #defines for PCI device classes and subclases,
using a new pci_config_set_class() function, similar to the recently
added pci_config_set_vendor_id() and pci_config_set_device_id().
Change since v1: fixed compilation of hw/sun4u.c
Signed-off-by: Stuart Brady <stuart.brady@gmail.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6491 c046a42c-6fe2-441c-8c8c-71466251a162
A subsystem vendor ID of zero isn't allowed, so we use our
default ID.
Gerd points out that although the PCI subsystem vendor ID is
treated by the guest as the virtio vendor ID:
/* we use the subsystem vendor/device id as the virtio vendor/device
* id. this allows us to use the same PCI vendor/device id for all
* virtio devices and to identify the particular virtio driver by
* the subsytem ids */
vp_dev->vdev.id.vendor = pci_dev->subsystem_vendor;
vp_dev->vdev.id.device = pci_dev->subsystem_device;
it looks like only the device ID is used right now:
# grep virtio modules.alias
alias virtio:d00000001v* virtio_net
alias virtio:d00000002v* virtio_blk
alias virtio:d00000003v* virtio_console
alias virtio:d00000004v* virtio-rng
alias virtio:d00000005v* virtio_balloon
alias pci:v00001AF4d*sv*sd*bc*sc*i* virtio_pci
alias virtio:d00000009v* 9pnet_virtio
so setting the subsystem vendor id to something != zero shouldn't cause
trouble.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6440 c046a42c-6fe2-441c-8c8c-71466251a162
Use the defines added by the previous patch in the virtio drivers.
Also remove the pointless vendor and device args from the
virtio_blk_init() function.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5987 c046a42c-6fe2-441c-8c8c-71466251a162
Virtio-blk is a paravirtual block device based on VirtIO. It can be used by
specifying the if=virtio parameter to the -drive parameter.
When using -enable-kvm, it can achieve very good performance compared to IDE or
SCSI.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5870 c046a42c-6fe2-441c-8c8c-71466251a162
