virtio: Don't ignore initialization failures

Don't ignore an error in the bus specific initialization function in
virtio_init; don't ignore the result of virtio_init; and don't return 0
in virtio_bl

virtio: Don't ignore initialization failures

Don't ignore an error in the bus specific initialization function in
virtio_init; don't ignore the result of virtio_init; and don't return 0
in virtio_blk__init and virtio_scsi__init when we encounter an error.
Hopefully this will save some developer's time debugging faulty virtio
devices in a guest.

To take advantage of the cleanup function virtio_blk__exit, move appending
the new device to the list before the call to virtio_init. Change
virtio_net__exit to free all allocated net_dev devices on exit, and
matching what virtio_blk__exit does.

To safeguard against this in the future, virtio_init has been annoted
with the compiler attribute warn_unused_result.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

virtio: use strlcpy

GCC 8.x complains about improper usage of strncpy in virtio/net.c and
virtio/scsi.c:
In function 'virtio_scsi_init_one',
inlined from 'virtio_scsi_init' at virtio/scsi.c:285:

virtio: use strlcpy

GCC 8.x complains about improper usage of strncpy in virtio/net.c and
virtio/scsi.c:
In function 'virtio_scsi_init_one',
inlined from 'virtio_scsi_init' at virtio/scsi.c:285:7:
virtio/scsi.c:247:2: error: 'strncpy' specified bound 224 equals destination size [-Werror=stringop-truncation]
strncpy((char *)&sdev->target.vhost_wwpn, disk->wwpn, sizeof(sdev->target.vhost_wwpn));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fix this and the other occurences in virtio/ by using strlcpy instead
of strncpy.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio: fix warning on strncpy

GCC 8.2 gives this warning:

virtio/net.c: In function ‘virtio_net__tap_init’:
virtio/net.c:336:47: error: argument to ‘sizeof’ in ‘strncpy’ call is the same expressio

virtio: fix warning on strncpy

GCC 8.2 gives this warning:

virtio/net.c: In function ‘virtio_net__tap_init’:
virtio/net.c:336:47: error: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
strncpy(ifr.ifr_name, ndev->tap_name, sizeof(ndev->tap_name));
^
virtio/net.c:348:47: error: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
strncpy(ifr.ifr_name, ndev->tap_name, sizeof(ndev->tap_name));
^

Fix it by using sizeof of destination instead, even if they're the same
size in this case.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Anisse Astier <aastier@freebox.fr>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio/net: Implement device and virtqueue reset

On exit_vq(), clean all resources allocated for the queue. When the device
is reset, clean the backend.

Signed-off-by: Jean-Philippe Brucker <jean-p

virtio/net: Implement device and virtqueue reset

On exit_vq(), clean all resources allocated for the queue. When the device
is reset, clean the backend.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio/net: Clean virtqueue state

Currently the virtqueue state is mixed with the netdev state. Move it to a
separate structure.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>

virtio/net: Clean virtqueue state

Currently the virtqueue state is mixed with the netdev state. Move it to a
separate structure.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio: Add get_vq() callback

To ease future changes to the core, replace get_pfn_vq() with get_vq().
This way adding new generic operation on virtqueues won't require
modifying every virtio device.

virtio: Add get_vq() callback

To ease future changes to the core, replace get_pfn_vq() with get_vq().
This way adding new generic operation on virtqueues won't require
modifying every virtio device.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio: Add get_vq_count() callback

Modern virtio requires devices to report how many queues they support. Add
an operation to query all devices about their capacities.

Signed-off-by: Jean-Philippe

virtio: Add get_vq_count() callback

Modern virtio requires devices to report how many queues they support. Add
an operation to query all devices about their capacities.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio: Implement notify_status

Modern virtio require proper status handling and reset. A "notify_status"
callback is already present in the virtio ops, but isn't implemented by
any device. Instead

virtio: Implement notify_status

Modern virtio require proper status handling and reset. A "notify_status"
callback is already present in the virtio ops, but isn't implemented by
any device. Instead they currently use "set_guest_feature" to reset the
device and deal with endianess. This isn't sufficient for proper device
reset, so add the notify_status callback to all devices that need it.

To add useful hints like "start" and "stop", extend the status variable to
32-bits.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
[Julien T: Remove VIRTIO_CONFIG_S_NEEDS_RESET from config mask, as
it is virtio v1+ macro and kvmtool only implements v0.9, this
macro should not be referenced for now]
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

irq: add irqfd helpers

Add helpers to add and remove IRQFD routing for both irqchips and MSIs.
We have to make a special case of IRQ lines on ARM where the
initialisation order goes like this:

(1)

irq: add irqfd helpers

Add helpers to add and remove IRQFD routing for both irqchips and MSIs.
We have to make a special case of IRQ lines on ARM where the
initialisation order goes like this:

(1) Devices reserve their IRQ lines
(2) VGIC is setup with VGIC_CTRL_INIT (in a late_init call)
(3) MSIs are reserved lazily, when the guest needs them

Since we cannot setup IRQFD before (2), store the IRQFD routing for IRQ
lines temporarily until we're ready to submit them.

Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

net: Check UFO offloading support for tap driver

In Linux commit fb652fdfe83710da0ca13448a41b7ed027d0a984:
https://www.spinics.net/lists/netdev/msg443562.html
The UFO support had been removed.

If w

net: Check UFO offloading support for tap driver

In Linux commit fb652fdfe83710da0ca13448a41b7ed027d0a984:
https://www.spinics.net/lists/netdev/msg443562.html
The UFO support had been removed.

If we use tap mode for network (--network mode=tap,tapif=...),
we will get following error:
"Warning: Config tap device TUNSETOFFLOAD error
You have requested a TAP device,
but creation of one has failed because: Invalid argument"

So, if we're running with latest kernel, we'd better to remove
TUN_F_UFO from TAP init. But if we're running with older kernels
without above commit. We'll miss the UFO feature. In this case,
we'd better to check the kernel UFO support status for tap driver.

The tap UFO state will used in get_host_features to return correct
VIRTIO_NET features. If we defer the tap UFO support check in
virtio_net__tap_init, it will be too later. So we separate the
tap create code from tap_init to a standalone function. This new
function will be used in virtio_net_init to create tap device and
check the tap UFO support status at the very beginning.

Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

virtio: fix endianness check for vhost support

Currently we deny any VHOST_* functionality if the architecture
supports guests with different endianness than the host. Most of the
time even on those

virtio: fix endianness check for vhost support

Currently we deny any VHOST_* functionality if the architecture
supports guests with different endianness than the host. Most of the
time even on those architectures the endianness of guest and host are
the same, though, so we are denying the glory of VHOST needlessly.
Switch from compile time determination to a run time scheme, which
takes the actual endianness of the guest into account.
For this we change the semantics of VIRTIO_ENDIAN_HOST to return the
actual endianness of the host (the endianness of kvmtool at compile
time, really). The actual check in vhost_net now compares this against
the guest endianness.
This enables vhost support on ARM and ARM64.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: virtio-net: fix VIRTIO_NET_F_MRG_RXBUF usage in rx thread

When merging virtio-net buffers using the VIRTIO_NET_F_MRG_RXBUF feature,
the first buffer added to the used ring should indicate t

kvmtool: virtio-net: fix VIRTIO_NET_F_MRG_RXBUF usage in rx thread

When merging virtio-net buffers using the VIRTIO_NET_F_MRG_RXBUF feature,
the first buffer added to the used ring should indicate the total number
of buffers used to hold the packet. Unfortunately, kvmtool has a number
of issues when constructing these merged buffers:

- Commit 5131332e3f1a ("kvmtool: convert net backend to support
bi-endianness") introduced a strange loop counter, which resulted in
hdr->num_buffers being set redundantly the first time round

- When adding the buffers to the ring, we actually add them one-by-one,
allowing the guest to see the header before we've inserted the rest
of the data buffers...

- ... which is made worse because we non-atomically increment the
num_buffers count in the header each time we insert a new data buffer

Consequently, the guest quickly becomes confused in its net rx code and
the whole thing grinds to a halt. This is easily exemplified by trying
to boot a root filesystem over NFS, which seldom succeeds.

This patch resolves the issues by allowing us to insert items into the
used ring without updating the index. Once the full payload has been
added and num_buffers corresponds to the total size, we *then* publish
the buffers to the guest.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: Introduce downscript option for virtio-net

To detach tap device automatically from bridge when exiting,
just like what the reverse of "script" does.

Signed-off-by: Fan Du <fan.du@intel.com

kvmtool: Introduce downscript option for virtio-net

To detach tap device automatically from bridge when exiting,
just like what the reverse of "script" does.

Signed-off-by: Fan Du <fan.du@intel.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

avoid casts when initializing structures

Due to our kernel heritage we have code in kvmtool that relies on
the (still) implicit -std=gnu89 compiler switch.
It turns out that this just affects some s

avoid casts when initializing structures

Due to our kernel heritage we have code in kvmtool that relies on
the (still) implicit -std=gnu89 compiler switch.
It turns out that this just affects some structure initialization,
where we currently provide a cast to the type, which upsets GCC for
anything beyond -std=gnu89 (for instance gnu99 or gnu11).
We do need the casts when initializing structures that are not
assigned to the same type, so we put it there explicitly.

This allows us to compile with all the three GNU standards GCC
currently supports: gnu89/90, gnu99 and gnu11.
GCC threatens people with moving to gnu11 as the new default standard,
so lets fix this better sooner than later.
(Compiling without GNU extensions still breaks and I don't bother to
fix that without very good reasons.)

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: Register each guest memory bank as vhost_memory_region

Otherwise vhost does not work if a virtio descriptor is used that was
allocated from a guest memory bank not registered as
vhost_memor

kvmtool: Register each guest memory bank as vhost_memory_region

Otherwise vhost does not work if a virtio descriptor is used that was
allocated from a guest memory bank not registered as
vhost_memory_region.

Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: Fix regression introduced with d2a7ddff4

Since commit d2a7ddff4 (Add minimal support for macvtap) opening
of tap device might fail. lkvm shows

Warning: Config tap device error. Are you r

kvmtool: Fix regression introduced with d2a7ddff4

Since commit d2a7ddff4 (Add minimal support for macvtap) opening
of tap device might fail. lkvm shows

Warning: Config tap device error. Are you root?

virtio_net_request_tap passed wrong pointer for struct ifreq to
TUNSETIFF ioctl.

Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: Set the thread names for terminal and virtio-net-ctrl

The terminal handling thread and the virtio-net-ctrl don't
set their name, which ends up as follows up:

terminal => lkvm
virtio-net-

kvmtool: Set the thread names for terminal and virtio-net-ctrl

The terminal handling thread and the virtio-net-ctrl don't
set their name, which ends up as follows up:

terminal => lkvm
virtio-net-ctrl => kvm-cpu-X !!

Set the thread name explicitly to term-poll and virtio-net-ctrl
respectively

Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: remove no longer needed kvm/types.h

include/kvm/types.h seemed to be in use once, but it does no longer
contain any useful definition. Remove it.

Signed-off-by: Andre Przywara <andre.przyw

kvmtool: remove no longer needed kvm/types.h

include/kvm/types.h seemed to be in use once, but it does no longer
contain any useful definition. Remove it.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: Add minimal support for macvtap

In order to be useable by kvmtool, a macvtap interface requires
some minimal configuration (basically setting up the offload bits).
This requires skipping so

kvmtool: Add minimal support for macvtap

In order to be useable by kvmtool, a macvtap interface requires
some minimal configuration (basically setting up the offload bits).
This requires skipping some of the low level TUN/TAP setup.

To avoid adding yet another option, we extend the 'tapif' option
to detect the use of a file (such as /dev/tap23).

Assuming you've run the following as root:

# ip link add link eth0 name kvmtap0 type macvtap mode bridge
# chgrp kvm /dev/tap$(< /sys/class/net/kvmtap0/ifindex)
# chmod g+rw /dev/tap$(< /sys/class/net/kvmtap0/ifindex)

it is fairly easy to have a script that does the following:

#!/bin/sh
addr=$(< /sys/class/net/kvmtap0/address)
tap=/dev/tap$(< /sys/class/net/kvmtap0/ifindex)

kvmtool/lkvm run --console virtio \
-k /boot/zImage \
-p "console=hvc0 earlyprintk" \
-n trans=mmio,mode=tap,tapif=$tap,guest_mac=$addr

and you now have your VM running, directly attached to the network.

This patch also removes the TUNSETNOCSUM ioctl that has declared
obsolete for quite some time now...

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

Use the arch default transport method for network

lkvm by default sets up a virtio-pci transport for network, if none is
specified. This can be a problem on archs (e.g ARM64), where virtio-pci is
no

Use the arch default transport method for network

lkvm by default sets up a virtio-pci transport for network, if none is
specified. This can be a problem on archs (e.g ARM64), where virtio-pci is
not supported yet and cause the following warning at exit.

# KVM compatibility warning.
virtio-net device was not detected.

This patch changes it to make use of the default transport method for the
architecture when none is specified. This will ensure that on every arch
we get the network up by default in the VM.

Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: convert net backend to support bi-endianness

Configure the queues to follow the guest endianness, and make sure
the configuration space is doing the same.

Extra care is taken for the handl

kvmtool: convert net backend to support bi-endianness

Configure the queues to follow the guest endianness, and make sure
the configuration space is doing the same.

Extra care is taken for the handling of the virtio_net_hdr structures
on both the TX and RX ends.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvmtool: allow the TAP interface to be specified on the command line

In order to overcome the fact that a TAP interface can only be created
by root, allow the use of an interface that has already be

kvmtool: allow the TAP interface to be specified on the command line

In order to overcome the fact that a TAP interface can only be created
by root, allow the use of an interface that has already been created,
configured, made persistent and owned by a specific user/group (such
as done with tunctl).

In this case, any kind of configuration can be skipped (IP, up and
running mode), and the TAP is assumed to be ready for use.

This is done by introducing the "tapif" option, as used here:
--network trans=mmio,mode=tap,tapif=blah

where "blah" is a TAP interface.

This allow the creation/configuration of the interface to be controlled
by root, and lkvm to be run as a normal user.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: net: allow a mixture of pci and mmio virtio devices

When attempting to initialise a mixture of pci and mmio virtio devices,
we cannot share an ops structure, otherwise the transport-speci

kvm tools: net: allow a mixture of pci and mmio virtio devices

When attempting to initialise a mixture of pci and mmio virtio devices,
we cannot share an ops structure, otherwise the transport-specific
fields (init/exit and signal handling) will be globally set to the
transport of the last registered device.

This patch dynamically allocates a new ops structure for each instance
of a virtio net device.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: net: don't propagate error codes from tx/rx operations

Currently, if a ->tx or ->rx callback into the net_dev_operations
encounters an error, it returns -1 to the virtio-net code, which i

kvm tools: net: don't propagate error codes from tx/rx operations

Currently, if a ->tx or ->rx callback into the net_dev_operations
encounters an error, it returns -1 to the virtio-net code, which in turn
treats this as an unsigned (size_t) size describing the data available.
The resulting memcpy operation then quickly explodes with a SEGV.

This patch detects the error code from the low-level callbacks and
exits the thread dealing with the erroneous queue.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: vhost-net: setup mergeable rx buffers feature

After features negotiation, kvmtool should tell vhost-net that he's
using mergeable rx buffers.

Signed-off-by: Ying-Shiuan Pan <yspan@itri.o

kvm tools: vhost-net: setup mergeable rx buffers feature

After features negotiation, kvmtool should tell vhost-net that he's
using mergeable rx buffers.

Signed-off-by: Ying-Shiuan Pan <yspan@itri.org.tw>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...