vdev->guest_features is not masking features that are not supported by
the guest.  Fix this by introducing a common wrapper to be used by all
virtio bus implementations.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

SCSI buses will need to read the children list first-to-last.  This
requires using a QTAILQ, because hell breaks loose if you just try
inserting at the tail (thus reversing the order of all existing
visits from last-to-first to first-to-tail).
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

It needs to be a qdev property, because it belongs to the drive's
guest part.  Precedence: commit a0fef654 and 6ced55a5.

Bonus: info qtree now shows the serial number.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

The s390x virtio bus keeps management information on virtio after the top
of the guest's RAM. We need to be able to tell the guest the size of its
RAM (without virtio stuff), but also be able to trap when the guest accesses
RAM outside of its scope (including virtio stuff).

So we need a variable telling us the size of the virtio stuff, so we can
calculate the highest available RAM address from that.

While at it, also increase the maximum number of virtio pages, so we play
along well with more recent kernels that spawn a ridiculous number of virtio
console adapters.
Signed-off-by: NAlexander Graf <agraf@suse.de>

The KVM interrupt injection path is non-generic for now. So we need to push
knowledge of how to inject a device interrupt using KVM into the actual device
code.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Using cpu_physical_memory_read, cpu_physical_memory_write and ldub_phys
improves readability and allows removing some type casts.

lduw_phys and ldl_phys were not used because both require aligned
addresses. Therefore it is not possible to simply replace existing
calls by one of these functions.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

The feature bitmap in the s390 virtio machine is little endian. To
address for that, we need to bswap the values after reading them out.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Commit 6b331efb broke the s390 proxy version
of virtio-serial by only taking its PCI brother into account.

So let's adjust s390-virtio-serial the same way as its PCI counterpart, making
it compile and work again.
Signed-off-by: NAlexander Graf <agraf@suse.de>
CC: Amit Shah <amit.shah@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

We have two different virtio buses: pci and s390. The abstraction path
taken in qemu is to have generic aliases for each device type in the
architecture specific qdev devices.

So let's make use of these aliases whenever we can and define them
whenever we can.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

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: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

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: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

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: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

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: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

vhost net backend needs to be notified when
frontend status changes. Add a callback,
similar to set_features.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Commit 428c149b modified the argument
that virtio_blk_init takes. Update the s390 bus code that calls this
function.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
CC: Christoph Hellwig <hch@lst.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

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: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

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: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

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: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Rename features->guest_features. This is
what they are, avoid confusion with
host features which we also need to keep around.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

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: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

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: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>