kvm tools: virtio-net has to open tap device before vhost-net init.

Enabling vhost-net encounted an error:
Fatal: VHOST_NET_SET_BACKEND failed 88

The reason is that vhost-net requires tap_fd for

kvm tools: virtio-net has to open tap device before vhost-net init.

Enabling vhost-net encounted an error:
Fatal: VHOST_NET_SET_BACKEND failed 88

The reason is that vhost-net requires tap_fd for VHOST_NET_SET_BACKEND,
however tap_fd is opened after VIRTIO_CONFIG_S_DRIVER_OK. Because the
initialization needs to know the guest features, I suppose the initialization
could be moved to set_guest_features(). Therefore, initialization can be
finished before status VIRTIO_CONFIG_S_DRIVER_OK, and tap_fd can be set
before vhost-net sets backend.

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

show more ...

kvm tools: Fix virtio-net iov memcpy

Milan Kocian writes:

I found the crash in virtio-net-rx thread (I can reproduce it every
time by 'aptitude update' in VM):

traps: virtio-net-rx[28933] ge

kvm tools: Fix virtio-net iov memcpy

Milan Kocian writes:

I found the crash in virtio-net-rx thread (I can reproduce it every
time by 'aptitude update' in VM):

traps: virtio-net-rx[28933] general protection ip:7f00dda3d107 sp:7f00c58f4de8 error:0 in libc-2.17.so[7f00dd90f000+1a2000]

gdb backtrace:

(gdb) bt
#0 0x00007fb6a548e107 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x000000000041259c in memcpy_toiovecend (iov=0x7fb68d346ea0, iov@entry=0x7fb68d345e90,
kdata=<optimized out>, kdata@entry=0x7fb68d346e90 "", offset=<optimized out>, len=<optimized out>)
at util/iovec.c:70
#2 0x000000000040c66d in virtio_net_rx_thread (p=0x23688a0) at virtio/net.c:117
#3 0x00007fb6a5b2ee0e in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007fb6a54489ed in clone () from /lib/x86_64-linux-gnu/libc.so.6

I tried to add some printf to diagnose it but it isn't clear to me:

virtio_net_rx_thread: before memcpy_toiovecend; copied: 0, len: 18890, iovsize: 4096, realiovsize: 4096
memcpy_toiovecend: offset: 0, len: 4096
memcpy_toiovecend: iov_len: 4096, len: 4096
virtio_net_rx_thread: before memcpy_toiovecend; copied: 4096, len: 18890, iovsize: 4096, realiovsize: 4096
memcpy_toiovecend: offset: 4096, len: 4096
memcpy_toiovecend: iov_len: 4096, len: 4096
memcpy_toiovecend: iov_len: 0, len: 4096
memcpy_toiovecend: iov_len: 0, len: 4096
.
N x memcpy_toiovecend: iov_len: 0, len: 4096
.
memcpy_toiovecend: iov_len: 0, len: 4096
memcpy_toiovecend: iov_len: 0, len: 4096
memcpy_toiovecend: iov_len: 1519143547641528320, len: 4096
memcpy_toiovecend: iov_len: 193827583623176, len: 4096
./runlkvm.sh: line 2: 16090 Segmentation fault

IMHO problem come when received len size is bigger than maximum of the
dst iovec (realiovsize). Only iovec size is copied and in the next run
isn't place to copy the rest of len size.

Asias He writes:

We should skip copied bytes from the buffer not from the iov itself
which memcpy_toiovecend does.

Reported-and-tested-by: Milan Kocian <milon@wq.cz>
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@iki.fi>

show more ...

kvm tools: plug race between uip_init and virtio_net_rx_thread

When fa7226f (kvm tools: init network devices only when the virtio
driver is ready to go) was introduced, a tiny detail was overlooked:

kvm tools: plug race between uip_init and virtio_net_rx_thread

When fa7226f (kvm tools: init network devices only when the virtio
driver is ready to go) was introduced, a tiny detail was overlooked:

- Initialization of the uip layer is now coming in very late (only
when the guest driver says it is ready).
- In parallel, the rx thread is created quite early (as soon as the
queues are allocated).

This cause the rx thread to call uip_rx, which calls uip_buf_get_used,
which starts to use buf_lock mutex/the buf_used_cond, which haven't
been initialized yet. Tears and devastation follow, not to mention a
certain lack of network connectivity for the unsuspecting guest.

The (not so pretty) fix is to split uip_init:
- uip_static_init: initialize the lists, mutexes and conditions,
called from virtio_net__init_one.
- uip_init: perform the dynamic memory allocations, called from
notify_status.

This allows the network to be safely initialized.

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

show more ...

kvm tools: fix boot of guests with more than 4gb of ram

Commit "kvm tools: virtio: remove hardcoded assumptions
about guest page size" has introduced a bug that prevented
guests with more than 4gb o

kvm tools: fix boot of guests with more than 4gb of ram

Commit "kvm tools: virtio: remove hardcoded assumptions
about guest page size" has introduced a bug that prevented
guests with more than 4gb of ram from booting.

The issue is that 'pfn' is a 32bit integer, so when multiplying
it by page size to get the actual page will cause an overflow if
the pfn referred to a memory area above 4gb.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: virtio-net mergable rx buffers

Support mergable rx buffers for virtio-net. This helps reduce the amount
of memory the guest kernel has to allocate per rx vq.

Signed-off-by: Sasha Levin <

kvm tools: virtio-net mergable rx buffers

Support mergable rx buffers for virtio-net. This helps reduce the amount
of memory the guest kernel has to allocate per rx vq.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: use correct vnet header size for mergable rx buffers

vnet header size depends on whether we use mergable rx buffers.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pe

kvm tools: use correct vnet header size for mergable rx buffers

vnet header size depends on whether we use mergable rx buffers.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: init network devices only when the virtio driver is ready to go

We may need to know what features are supported before we can init the
network on the host side.

Signed-off-by: Sasha Levi

kvm tools: init network devices only when the virtio driver is ready to go

We may need to know what features are supported before we can init the
network on the host side.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: fix vhost interaction with ctrl vq

We broke networking using vhost with the introduction of a ctrl vq,
make sure that that queue get treated like a special case.

Signed-off-by: Sasha Lev

kvm tools: fix vhost interaction with ctrl vq

We broke networking using vhost with the introduction of a ctrl vq,
make sure that that queue get treated like a special case.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: pass virtio header size to uip_init

We want to make the size of the virtio net header opaque to
uip.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penb

kvm tools: pass virtio header size to uip_init

We want to make the size of the virtio net header opaque to
uip.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: make virtio-net mq max queues configurable

This patch makes the maximum amount of vqs configurable. To use it pass a 'mq'
option to network device configuration. For example:

vm run -n

kvm tools: make virtio-net mq max queues configurable

This patch makes the maximum amount of vqs configurable. To use it pass a 'mq'
option to network device configuration. For example:

vm run -n mode=tap,mq=4

Will allow up to 4 queue pairs for that network device.

Note that not specifiying mq, or setting mq=0 will disable virtio-net
multiqueuing.

Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: virtio-net multiqueue support

This patch adds support for multiple virtio-net queues. Each queue gets
assigned to it's own corresponding rx/tx thread.

The max amount of queue pairs is 8

kvm tools: virtio-net multiqueue support

This patch adds support for multiple virtio-net queues. Each queue gets
assigned to it's own corresponding rx/tx thread.

The max amount of queue pairs is 8 right now, it's up to the guest
to decide the actual amount of queues it wants using ethtool. For
example, if I want 2 queue pairs on eth0:

ethtool -L eth0 combined 2

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: support virtio-net ctrl queue

We don't need much out of it at this point, but we will need it for virtio-net
mq patch.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by:

kvm tools: support virtio-net ctrl queue

We don't need much out of it at this point, but we will need it for virtio-net
mq patch.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: virtio: remove hardcoded assumptions about guest page size

virtio-based PCI devices deal only with 4k memory granules, making
direct use of the VIRTIO_PCI_VRING_ALIGN and VIRTIO_PCI_QUEUE

kvm tools: virtio: remove hardcoded assumptions about guest page size

virtio-based PCI devices deal only with 4k memory granules, making
direct use of the VIRTIO_PCI_VRING_ALIGN and VIRTIO_PCI_QUEUE_ADDR_SHIFT
constants when initialising the virtqueues for a device.

For MMIO-based devices, the guest page size is arbitrary and may differ
from that of the host (this is the case on AArch64, where both 4k and
64k pages are supported).

This patch fixes the virtio drivers to honour the guest page size passed
when configuring the virtio device and align the virtqueues accordingly.

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

show more ...

kvm tools: use mutex abstraction instead of pthread mutex

We already have something to wrap pthread with mutex_[init,lock,unlock]
calls. This patch creates a new struct mutex abstraction and moves
e

kvm tools: use mutex abstraction instead of pthread mutex

We already have something to wrap pthread with mutex_[init,lock,unlock]
calls. This patch creates a new struct mutex abstraction and moves
everything to work with it.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Specify names for VM internal threads

Give threads a meaningful name. This makes debugging much easier, and
everything else much prettier.

Suggested-by: Ingo Molnar <mingo@kernel.org>
Si

kvm tools: Specify names for VM internal threads

Give threads a meaningful name. This makes debugging much easier, and
everything else much prettier.

Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
[ penberg@kernel.org: specify vcpu names ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: remove global kvm object

This was ugly, and now we get rid of it.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

kvm tools: use init/exit where possible

Switch to using init/exit calls instead of the repeating call blocks in builtin-run.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekk

kvm tools: use init/exit where possible

Switch to using init/exit calls instead of the repeating call blocks in builtin-run.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: virtio-net init/exit

Make the init/exit of virtio-net self-contained, so the global init code
won't need to check if it was selected or not.

This also moves the bulk of the net-specific

kvm tools: virtio-net init/exit

Make the init/exit of virtio-net self-contained, so the global init code
won't need to check if it was selected or not.

This also moves the bulk of the net-specific initialization code, including
the parser, into virtio-net itself.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: simplify virtio config handling

Instead of a get/set for config values, just request the address of the
config region, and handle that by simply reading directly from that region.

Signed

kvm tools: simplify virtio config handling

Instead of a get/set for config values, just request the address of the
config region, and handle that by simply reading directly from that region.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Fix formatting of error message in TAP handling

This error message is missing a space, and has a redundant ":" at the end,
currently it produces:

You have requested a TAP device, but c

kvm tools: Fix formatting of error message in TAP handling

This error message is missing a space, and has a redundant ":" at the end,
currently it produces:

You have requested a TAP device, but creation of one hasfailed because:: No such file or directory

Add a space to "hasfailed" and remove the extra ":".

Don't split the line to improve grepability.

Acked-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Do not poll ioeventfd if vhost is enabled

If vhost is enabled for a virtio device, vhost will poll the ioeventfd
in kernel side and there is no need to poll it in userspace. Otherwise,
bo

kvm tools: Do not poll ioeventfd if vhost is enabled

If vhost is enabled for a virtio device, vhost will poll the ioeventfd
in kernel side and there is no need to poll it in userspace. Otherwise,
both vhost kernel and userspace will race to poll.

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Fix VHOST_SET_MEM_TABLE failure

VHOST_SET_MEM_TABLE failed: Operation not supported

In vhost_set_memory(), We have

if (mem.padding)
return -EOPNOTSUPP;

So, we n

kvm tools: Fix VHOST_SET_MEM_TABLE failure

VHOST_SET_MEM_TABLE failed: Operation not supported

In vhost_set_memory(), We have

if (mem.padding)
return -EOPNOTSUPP;

So, we need to zero struct vhost_memory.

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Fix compat message

compat_id is initialized to -1 for each type of device. We should add
compat message if the compat_id == -1 which means we haven't added
compat message for this type of

kvm tools: Fix compat message

compat_id is initialized to -1 for each type of device. We should add
compat message if the compat_id == -1 which means we haven't added
compat message for this type of device.

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Introduce virtio_compat_add_message() helper

This patch introduces a helper virtio_compat_add_message() to simplify
adding compat message for virtio device.

Signed-off-by: Asias He <asia

kvm tools: Introduce virtio_compat_add_message() helper

This patch introduces a helper virtio_compat_add_message() to simplify
adding compat message for virtio device.

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Code cleanup for virtio/net.c

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>