summaryrefslogtreecommitdiffstats
path: root/hw/s390-virtio-bus.c
Commit message (Collapse)AuthorAgeFilesLines
* virtio-net: Introduce a new bottom half packet TXAlex Williamson2010-09-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Based on a patch from Mark McLoughlin, this patch introduces a new bottom half packet transmitter that avoids the latency imposed by the tx_timer approach. Rather than scheduling a timer when a TX packet comes in, schedule a bottom half to be run from the iothread. The bottom half handler first attempts to flush the queue with notification disabled (this is where we could race with a guest without txburst). If we flush a full burst, reschedule immediately. If we send short of a full burst, try to re-enable notification. To avoid a race with TXs that may have occurred, we must then flush again. If we find some packets to send, the guest it probably active, so we can reschedule again. tx_timer and tx_bh are mutually exclusive, so we can re-use the tx_waiting flag to indicate one or the other needs to be setup. This allows us to seamlessly migrate between timer and bh TX handling. The bottom half handler becomes the new default and we add a new tx= option to virtio-net-pci. Usage: -device virtio-net-pci,tx=timer # select timer mitigation vs "bh" Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-net: Limit number of packets sent per TX flushAlex Williamson2010-09-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | If virtio_net_flush_tx() is called with notification disabled, we can race with the guest, processing packets at the same rate as they get produced. The trouble is that this means we have no guaranteed exit condition from the function and can spend minutes in there. Currently flush_tx is only called with notification on, which seems to limit us to one pass through the queue per call. An upcoming patch changes this. Also add an option to set this value on the command line as different workloads may wish to use different values. We can't necessarily support any random value, so this is a developer option: x-txburst= Usage: -device virtio-net-pci,x-txburst=64 # 64 packets per tx flush One pass through the queue (256) seems to be a good default value for this, balancing latency with throughput. We use a signed int for x-txburst because 2^31 packets in a burst would take many, many minutes to process and it allows us to easily return a negative value value from virtio_net_flush_tx() to indicate a back-off or error condition. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-net: Make tx_timer timeout configurableAlex Williamson2010-09-071-1/+4
| | | | | | | | | | | | | | Add an option to make the TX mitigation timer adjustable as a device option. The 150us hard coded default used currently is reasonable, but may not be suitable for all workloads, this gives us a way to adjust it using a single binary. We can't support any random option though, so use the "x-" prefix to indicate this is a developer option. Usage: -device virtio-net-pci,x-txtimer=500000,... # .5ms timeout Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* Implement virtio resetAlexander Graf2010-04-091-2/+1
| | | | | | | | | The guest may issue a RESET command for virtio. So far we didn't bother to implement it, but with my new bootloader we actually need it for Linux to get back to a safe state. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
* virtio: add set_status callbackMichael S. Tsirkin2010-04-011-1/+1
| | | | | | | | | vhost net backend needs to be notified when frontend status changes. Add a callback, similar to set_features. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* s390-virtio: Fix compile error for virtio-block initAmit Shah2010-03-061-1/+1
| | | | | | | | | | Commit 428c149b0be790b440e1cbee185b152cdb22feec modified the argument that virtio_blk_init takes. Update the s390 bus code that calls this function. Signed-off-by: Amit Shah <amit.shah@redhat.com> CC: Christoph Hellwig <hch@lst.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
* block: add topology qdev propertiesChristoph Hellwig2010-02-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add three new qdev properties to export block topology information to the guest. This is needed to get optimal I/O alignment for RAID arrays or SSDs. The options are: - physical_block_size to specify the physical block size of the device, this is going to increase from 512 bytes to 4096 kilobytes for many modern storage devices - min_io_size to specify the minimal I/O size without performance impact, this is typically set to the RAID chunk size for arrays. - opt_io_size to specify the optimal sustained I/O size, this is typically the RAID stripe width for arrays. I decided to not auto-probe these values from blkid which might easily be possible as I don't know how to deal with these issues on migration. Note that we specificly only set the physical_block_size, and not the logial one which is the unit all I/O is described in. The reason for that is that IDE does not support increasing the logical block size and at last for now I want to stick to one meachnisms in queue and allow for easy switching of transports for a given backing image which would not be possible if scsi and virtio use real 4k sectors, while ide only uses the physical block exponent. To make this more common for the different block drivers introduce a new BlockConf structure holding all common block properties and a DEFINE_BLOCK_PROPERTIES macro to add them all together, mirroring what is done for network drivers. Also switch over all block drivers to use it, except for the floppy driver which has weird driveA/driveB properties and probably won't require any advanced block options ever. Example usage for a virtio device with 4k physical block size and 8k optimal I/O size: -drive file=scratch.img,media=disk,cache=none,id=scratch \ -device virtio-blk-pci,drive=scratch,physical_block_size=4096,opt_io_size=8192 aliguori: updated patch to take into account BLOCK events Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* virtio-console: qdev conversion, new virtio-serial-busAmit Shah2010-01-201-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit converts the virtio-console device to create a new virtio-serial bus that can host console and generic serial ports. The file hosting this code is now called virtio-serial-bus.c. The virtio console is now a very simple qdev device that sits on the virtio-serial-bus and communicates between the bus and qemu's chardevs. This commit also includes a few changes to the virtio backing code for pci and s390 to spawn the virtio-serial bus. As a result of the qdev conversion, we get rid of a lot of legacy code. The old-style way of instantiating a virtio console using -virtioconsole ... is maintained, but the new, preferred way is to use -device virtio-serial -device virtconsole,chardev=... With this commit, multiple devices as well as multiple ports with a single device can be supported. For multiple ports support, each port gets an IO vq pair. Since the guest needs to know in advance how many vqs a particular device will need, we have to set this number as a property of the virtio-serial device and also as a config option. In addition, we also spawn a pair of control IO vqs. This is an internal channel meant for guest-host communication for things like port open/close, sending port properties over to the guest, etc. This commit is a part of a series of other commits to get the full implementation of multiport support. Future commits will add other support as well as ride on the savevm version that we bump up here. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* virtio: add features as qdev propertiesMichael S. Tsirkin2010-01-111-3/+9
| | | | | | | | | | | | | Add feature bits as properties to virtio. This makes it possible to e.g. define machine without indirect buffer support, which is required for 0.10 compatibility, or without hardware checksum support, which is required for 0.11 compatibility. Since default values for optional features are now set by qdev, get_features callback has been modified: it sets non-optional bits, and clears bits not supported by host. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* virtio: rename features -> guest_featuresMichael S. Tsirkin2010-01-111-1/+1
| | | | | | | | | Rename features->guest_features. This is what they are, avoid confusion with host features which we also need to keep around. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* S390: Don't tell guest we're updating config spaceAlexander Graf2009-12-181-1/+1
| | | | | | | | | | | | | Currently we always set the "config space changed" bit to 1 when triggering any virtio interrupt. While that worked in 2.6.27, newer kernels interpret that value as "only the config space changed and nothing else happened". Since we usually trigger interrupts to tell the guest that something did happen, we just not tell it the config space changed for now until we implement the correct callback for that. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
* Add S390x virtio machine busAlexander Graf2009-12-051-0/+395
On S390x we don't want to go through the hassle of emulating real existing hardware, because we don't need to for running Linux. So let's instead implement a machine that is 100% based on VirtIO which we fortunately implement already. This patch implements the bus that is the groundwork for such an S390x virtio machine. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
OpenPOWER on IntegriCloud