virtio_serial_init() allocates the VirtIOSerialBus dynamically, but
virtio_serial_exit() doesn't free it.

Fix by getting rid of the allocation.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Instead of calling flush_queued_data when unthrottling, schedule
a bh. That way we can return immediately to the caller, and the
flush uses the same call path as a have_data for callbackee.

No migration change is required because bh are called from vm_stop.
Signed-off-by: NAlon Levy <alevy@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

The virtio serial specification requres that the values in the config
space are encoded in native endian of the guest.

The qemu virtio-serial code did not do conversion to the guest endian
format what caused problems when host and guest use different format.

This patch corrects the qemu side, correctly doing host-native <->
guest-native conversions when accessing the config space. This won't
break any setups that aren't already broken, and fixes the case
of different host and guest endianness.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Fix crash on invalid input in virtio-serial.
Discovered by code review, untested.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

There's no code change, just re-arrangement to simplify the function
after recent modifications.
Reported-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Instead of using a single variable to pass to the virtio_serial_init
function, use a struct so that expanding the number of variables to be
passed on later is easier.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

VirtIOSerialDevice is like VirtIOSerialPort with just the first two
fields, which makes it pretty pointless.  Using VirtIOSerialPort
directly works equally well and is less confusing.

[Amit: - rebase
       - rename 'dev' to 'port' in function params in virtio-serial.h ]
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This can happen if a port gets unplugged before guest has chance to
initialise vqs.
Reported-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The new fields that got added as part of not copying over the guest
buffer to the host need to be saved/restored across migration.  Do that
and bump up the version number.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

This commit lets apps signal an incomplete write.  When that happens,
stop sending out any more data to the app and wait for it to unthrottle
the port.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

When the guest writes something to a host, we copied over the entire
buffer first into the host and then processed it.  Do away with that, it
could result in a malicious guest causing a DoS on the host.
Reported-by: NPaul Brook <paul@codesourcery.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Instead of combining flush logic into the discard case and not discard
case, have one function doing discard case.  This will help later when
adding flow control logic to the do_flush_queued_data() function.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

The current default of 16 buffers for the control vq is too small.  We
can get more entries in there, for example when asking the guest to add
max. allowed ports.

Note: a more robust solution would involve some kind of event queueing
in host to guarantee no event loss. Added a TODO to look into
this later.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Free malloc'ed memory, unregister from savevm and clean up virtio-common
bits on device hot-unplug.

This was found performing a migration after device hot-unplug.

Reported-by: <lihuang@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Currently virtio-serial supports a maximum of 31 ports. Specifying the
'max_ports' parameter to be > 31 on the cmd line causes badness.

Ensure we initialise virtio-serial only if max_ports is within the
supported range.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

In addition to the previous fix for calling do_flush_queued_data() only
when the virtqueue is ready, ensure do_flush_queued_data() gets a vq
that's suitably initialised.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If a virtio-serial port is removed before the guest comes up and
initialises the virtqueues, qemu exits with the message

Guest moved used index from 0 to 61440

This happens because we try to clear any pending buffers from the
virtqueue.

Ensure the virtqueue is initialised before calling any virtqueue
operations.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When available, we'd like to be able to access the DeviceState
when registering a savevm.  For buses with a get_dev_path()
function, this will allow us to create more unique savevm
id strings.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

For all i, ports_map[i] is used in and only in the i-th iteration.
Replace the dynamic array by a scalar variable.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Fix for too small allocation to ports_map
Signed-off-by: NAlon Levy <alevy@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

In the flush_queued_data() function, we expect port to be valid. Assert
only for port and not port || discard.
Reported-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Individual ports can now signal to the virtio-serial core to stop
sending data if the ports cannot immediately handle new data.  When a
port later unthrottles, any data queued up in the virtqueue are sent to
the port.

Disable throttling once a port is closed (and we discard all the
unconsumed buffers in the vq).

The guest kernel can reclaim the buffers when it receives the port close
event or when a port is being removed. Ensure we free up the buffers
before we send out any events to the guest.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Before the earlier patch, we relied on incorrect virtio api usage to
signal to the guest that a particular buffer wasn't consumed by the
host.

After fixing that, we now just discard the data the guest sends us while
a host port is disconnected or doesn't have a handler registered for
consuming data.

This commit really doesn't change anything from the current behaviour,
just makes the code slightly better by spinning off data handling to
ports in another function.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We cannot indicate to the guest how much data was consumed by an app for
out_bufs.  So we just have to assume the apps will consume all the data
that are handed over to them.

Fix the virtio api abuse in control_out() and handle_output().
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Current guests don't send more than one iov but it can change later.
Ensure we handle that case.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
CC: Avi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Current control messages are small enough to not be split into multiple
buffers but we could run into such a situation in the future or a
malicious guest could cause such a situation.

So handle the entire iov request for control messages.

Also ensure the size of the control request is >= what we expect
otherwise we risk accessing memory that we don't own.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
CC: Avi Kivity <avi@redhat.com>
Reported-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The virtio-net code uses iov_fill() which fills an iov from a linear
buffer. The virtio-serial-bus code does something similar in an
open-coded function.

Create a new iov.c file that has iov_from_buf().

Convert virtio-net and virtio-serial-bus over to use this functionality.
virtio-net used ints to hold sizes, the new function is going to use
size_t types.

Later commits will add the opposite functionality -- going from an iov
to a linear buffer.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Data should be written only when ports are open.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If adding of ports or devices in the guest fails we can send out a QMP
event so that management software can deal with it.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

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

The check for a 0-sized write request to a guest port is not necessary;
the while loop below won't be executed in this case and all will be
fine.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The virtio-serial code doesn't mix declarations and definitions, so
separate them out on different lines.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Allow the port 'id's to be set by a user on the command line. This is
needed by management apps that will want a stable port numbering scheme
for hot-plug/unplug and migration.

Since the port numbers are shared with the guest (to identify ports in
control messages), we just send a control message to the guest
indicating addition of new ports (hot-plug) or notifying the guest of
the available ports when the guest sends us a DEVICE_READY control
message.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If the host connection to a port is closed on the destination machine
after migration, whereas the connection was open on the source, the
guest has to be informed of that.

Similar for a host connection open on the destination.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If some ports that were hot-plugged on the source are not available on
the destination, fail migration instead of trying to deref a NULL
pointer.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reported-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The number of ports on the source as well as the destination machines
should match. If they don't, it means some ports that got hotplugged on
the source aren't instantiated on the destination. Or that ports that
were hot-unplugged on the source are created on the destination.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reported-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The target could be started with max_nr_ports for a virtio-serial device
lesser than what was available on the source machine. Fail the migration
in such a case.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reported-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

error_report() terminates the message with a newline.  Strip it it
from its arguments.

This fixes a few error messages lacking a newline:
net_handle_fd_param()'s "No file descriptor named %s found", and
tap_open()'s "vnet_hdr=1 requested, but no kernel support for
IFF_VNET_HDR available" (all three versions).

There's one place that passes arguments without newlines
intentionally: load_vmstate().  Fix it up.

Since commit 98b19252, all
serial devices declare MULTIPORT feature.
To allow 0.12 compatibility, we should clear this when
max_nr_ports is 1.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit enables one to use multiple virtio-serial devices and to
assign ports to arbitrary devices like this:

  -device virtio-serial,id=foo -device virtio-serial,id=bar \
  -device virtserialport,bus=foo.0,name=foo \
  -device virtserialport,bus=bar.0,name=bar
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>