2020-07-01 16:55:38 +02:00
|
|
|
/*
|
|
|
|
* vhost-vdpa.c
|
|
|
|
*
|
|
|
|
* Copyright(c) 2017-2018 Intel Corporation.
|
|
|
|
* Copyright(c) 2020 Red Hat, Inc.
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu/osdep.h"
|
|
|
|
#include "clients.h"
|
2022-07-20 08:59:42 +02:00
|
|
|
#include "hw/virtio/virtio-net.h"
|
2020-07-01 16:55:38 +02:00
|
|
|
#include "net/vhost_net.h"
|
|
|
|
#include "net/vhost-vdpa.h"
|
|
|
|
#include "hw/virtio/vhost-vdpa.h"
|
|
|
|
#include "qemu/config-file.h"
|
|
|
|
#include "qemu/error-report.h"
|
2022-07-20 08:59:42 +02:00
|
|
|
#include "qemu/log.h"
|
|
|
|
#include "qemu/memalign.h"
|
2020-07-01 16:55:38 +02:00
|
|
|
#include "qemu/option.h"
|
|
|
|
#include "qapi/error.h"
|
2021-10-20 06:56:00 +02:00
|
|
|
#include <linux/vhost.h>
|
2020-07-01 16:55:38 +02:00
|
|
|
#include <sys/ioctl.h>
|
|
|
|
#include <err.h>
|
|
|
|
#include "standard-headers/linux/virtio_net.h"
|
|
|
|
#include "monitor/monitor.h"
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
#include "migration/migration.h"
|
|
|
|
#include "migration/misc.h"
|
2020-07-01 16:55:38 +02:00
|
|
|
#include "hw/virtio/vhost.h"
|
|
|
|
|
|
|
|
/* Todo:need to add the multiqueue support here */
|
|
|
|
typedef struct VhostVDPAState {
|
|
|
|
NetClientState nc;
|
|
|
|
struct vhost_vdpa vhost_vdpa;
|
2024-02-22 18:28:29 +01:00
|
|
|
NotifierWithReturn migration_state;
|
2020-07-01 16:55:38 +02:00
|
|
|
VHostNetState *vhost_net;
|
2022-07-20 08:59:43 +02:00
|
|
|
|
|
|
|
/* Control commands shadow buffers */
|
2022-09-06 17:07:14 +02:00
|
|
|
void *cvq_cmd_out_buffer;
|
|
|
|
virtio_net_ctrl_ack *status;
|
|
|
|
|
2022-12-15 12:31:42 +01:00
|
|
|
/* The device always have SVQ enabled */
|
|
|
|
bool always_svq;
|
2023-05-26 17:31:43 +02:00
|
|
|
|
|
|
|
/* The device can isolate CVQ in its own ASID */
|
|
|
|
bool cvq_isolated;
|
|
|
|
|
2020-07-01 16:55:38 +02:00
|
|
|
bool started;
|
|
|
|
} VhostVDPAState;
|
|
|
|
|
2023-06-30 15:21:48 +02:00
|
|
|
/*
|
|
|
|
* The array is sorted alphabetically in ascending order,
|
|
|
|
* with the exception of VHOST_INVALID_FEATURE_BIT,
|
|
|
|
* which should always be the last entry.
|
|
|
|
*/
|
2020-07-01 16:55:38 +02:00
|
|
|
const int vdpa_feature_bits[] = {
|
|
|
|
VIRTIO_F_ANY_LAYOUT,
|
2023-06-30 15:21:48 +02:00
|
|
|
VIRTIO_F_IOMMU_PLATFORM,
|
|
|
|
VIRTIO_F_NOTIFY_ON_EMPTY,
|
|
|
|
VIRTIO_F_RING_PACKED,
|
|
|
|
VIRTIO_F_RING_RESET,
|
2020-07-01 16:55:38 +02:00
|
|
|
VIRTIO_F_VERSION_1,
|
|
|
|
VIRTIO_NET_F_CSUM,
|
2023-06-02 19:33:28 +02:00
|
|
|
VIRTIO_NET_F_CTRL_GUEST_OFFLOADS,
|
2023-06-30 15:21:48 +02:00
|
|
|
VIRTIO_NET_F_CTRL_MAC_ADDR,
|
|
|
|
VIRTIO_NET_F_CTRL_RX,
|
|
|
|
VIRTIO_NET_F_CTRL_RX_EXTRA,
|
|
|
|
VIRTIO_NET_F_CTRL_VLAN,
|
|
|
|
VIRTIO_NET_F_CTRL_VQ,
|
2020-07-01 16:55:38 +02:00
|
|
|
VIRTIO_NET_F_GSO,
|
2023-06-30 15:21:48 +02:00
|
|
|
VIRTIO_NET_F_GUEST_CSUM,
|
|
|
|
VIRTIO_NET_F_GUEST_ECN,
|
2020-07-01 16:55:38 +02:00
|
|
|
VIRTIO_NET_F_GUEST_TSO4,
|
|
|
|
VIRTIO_NET_F_GUEST_TSO6,
|
|
|
|
VIRTIO_NET_F_GUEST_UFO,
|
2023-08-01 00:31:47 +02:00
|
|
|
VIRTIO_NET_F_GUEST_USO4,
|
|
|
|
VIRTIO_NET_F_GUEST_USO6,
|
2023-06-30 15:21:48 +02:00
|
|
|
VIRTIO_NET_F_HASH_REPORT,
|
|
|
|
VIRTIO_NET_F_HOST_ECN,
|
2020-07-01 16:55:38 +02:00
|
|
|
VIRTIO_NET_F_HOST_TSO4,
|
|
|
|
VIRTIO_NET_F_HOST_TSO6,
|
|
|
|
VIRTIO_NET_F_HOST_UFO,
|
2023-08-01 00:31:47 +02:00
|
|
|
VIRTIO_NET_F_HOST_USO,
|
2023-06-30 15:21:48 +02:00
|
|
|
VIRTIO_NET_F_MQ,
|
2020-07-01 16:55:38 +02:00
|
|
|
VIRTIO_NET_F_MRG_RXBUF,
|
|
|
|
VIRTIO_NET_F_MTU,
|
2021-05-14 13:48:33 +02:00
|
|
|
VIRTIO_NET_F_RSS,
|
2020-10-01 22:09:45 +02:00
|
|
|
VIRTIO_NET_F_STATUS,
|
2023-06-30 15:21:48 +02:00
|
|
|
VIRTIO_RING_F_EVENT_IDX,
|
|
|
|
VIRTIO_RING_F_INDIRECT_DESC,
|
|
|
|
|
|
|
|
/* VHOST_INVALID_FEATURE_BIT should always be the last entry */
|
2020-07-01 16:55:38 +02:00
|
|
|
VHOST_INVALID_FEATURE_BIT
|
|
|
|
};
|
|
|
|
|
2022-07-20 08:59:46 +02:00
|
|
|
/** Supported device specific feature bits with SVQ */
|
|
|
|
static const uint64_t vdpa_svq_device_features =
|
|
|
|
BIT_ULL(VIRTIO_NET_F_CSUM) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_GUEST_CSUM) |
|
2023-06-02 13:52:18 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) |
|
2022-07-20 08:59:46 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_MTU) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_MAC) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_GUEST_TSO4) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_GUEST_TSO6) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_GUEST_ECN) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_GUEST_UFO) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_HOST_TSO4) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_HOST_TSO6) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_HOST_ECN) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_HOST_UFO) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_MRG_RXBUF) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_STATUS) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_CTRL_VQ) |
|
2023-07-07 17:27:34 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_CTRL_RX) |
|
2023-07-23 14:09:14 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_CTRL_VLAN) |
|
2023-07-08 11:24:52 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_CTRL_RX_EXTRA) |
|
2022-09-06 17:07:19 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_MQ) |
|
2022-07-20 08:59:46 +02:00
|
|
|
BIT_ULL(VIRTIO_F_ANY_LAYOUT) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) |
|
2023-03-03 18:24:44 +01:00
|
|
|
/* VHOST_F_LOG_ALL is exposed by SVQ */
|
|
|
|
BIT_ULL(VHOST_F_LOG_ALL) |
|
2023-10-25 03:02:25 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_HASH_REPORT) |
|
2023-10-25 03:08:06 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_RSS) |
|
2022-07-20 08:59:46 +02:00
|
|
|
BIT_ULL(VIRTIO_NET_F_RSC_EXT) |
|
2023-03-07 18:00:18 +01:00
|
|
|
BIT_ULL(VIRTIO_NET_F_STANDBY) |
|
|
|
|
BIT_ULL(VIRTIO_NET_F_SPEED_DUPLEX);
|
2022-07-20 08:59:46 +02:00
|
|
|
|
2022-12-15 12:31:44 +01:00
|
|
|
#define VHOST_VDPA_NET_CVQ_ASID 1
|
|
|
|
|
2020-07-01 16:55:38 +02:00
|
|
|
VHostNetState *vhost_vdpa_get_vhost_net(NetClientState *nc)
|
|
|
|
{
|
|
|
|
VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
|
|
|
|
assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
return s->vhost_net;
|
|
|
|
}
|
|
|
|
|
2023-06-02 16:38:53 +02:00
|
|
|
static size_t vhost_vdpa_net_cvq_cmd_len(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* MAC_TABLE_SET is the ctrl command that produces the longer out buffer.
|
|
|
|
* In buffer is always 1 byte, so it should fit here
|
|
|
|
*/
|
|
|
|
return sizeof(struct virtio_net_ctrl_hdr) +
|
|
|
|
2 * sizeof(struct virtio_net_ctrl_mac) +
|
|
|
|
MAC_TABLE_ENTRIES * ETH_ALEN;
|
|
|
|
}
|
|
|
|
|
|
|
|
static size_t vhost_vdpa_net_cvq_cmd_page_len(void)
|
|
|
|
{
|
|
|
|
return ROUND_UP(vhost_vdpa_net_cvq_cmd_len(), qemu_real_host_page_size());
|
|
|
|
}
|
|
|
|
|
2022-12-15 12:31:37 +01:00
|
|
|
static bool vhost_vdpa_net_valid_svq_features(uint64_t features, Error **errp)
|
|
|
|
{
|
|
|
|
uint64_t invalid_dev_features =
|
|
|
|
features & ~vdpa_svq_device_features &
|
|
|
|
/* Transport are all accepted at this point */
|
|
|
|
~MAKE_64BIT_MASK(VIRTIO_TRANSPORT_F_START,
|
|
|
|
VIRTIO_TRANSPORT_F_END - VIRTIO_TRANSPORT_F_START);
|
|
|
|
|
|
|
|
if (invalid_dev_features) {
|
|
|
|
error_setg(errp, "vdpa svq does not work with features 0x%" PRIx64,
|
|
|
|
invalid_dev_features);
|
2022-12-15 12:31:39 +01:00
|
|
|
return false;
|
2022-12-15 12:31:37 +01:00
|
|
|
}
|
|
|
|
|
2022-12-15 12:31:39 +01:00
|
|
|
return vhost_svq_valid_features(features, errp);
|
2022-12-15 12:31:37 +01:00
|
|
|
}
|
|
|
|
|
2020-07-01 16:55:38 +02:00
|
|
|
static int vhost_vdpa_net_check_device_id(struct vhost_net *net)
|
|
|
|
{
|
|
|
|
uint32_t device_id;
|
|
|
|
int ret;
|
|
|
|
struct vhost_dev *hdev;
|
|
|
|
|
|
|
|
hdev = (struct vhost_dev *)&net->dev;
|
|
|
|
ret = hdev->vhost_ops->vhost_get_device_id(hdev, &device_id);
|
|
|
|
if (device_id != VIRTIO_ID_NET) {
|
|
|
|
return -ENOTSUP;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-10-20 06:56:00 +02:00
|
|
|
static int vhost_vdpa_add(NetClientState *ncs, void *be,
|
|
|
|
int queue_pair_index, int nvqs)
|
2020-07-01 16:55:38 +02:00
|
|
|
{
|
|
|
|
VhostNetOptions options;
|
|
|
|
struct vhost_net *net = NULL;
|
|
|
|
VhostVDPAState *s;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
options.backend_type = VHOST_BACKEND_TYPE_VDPA;
|
|
|
|
assert(ncs->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
s = DO_UPCAST(VhostVDPAState, nc, ncs);
|
|
|
|
options.net_backend = ncs;
|
|
|
|
options.opaque = be;
|
|
|
|
options.busyloop_timeout = 0;
|
2021-10-20 06:56:00 +02:00
|
|
|
options.nvqs = nvqs;
|
2020-07-01 16:55:38 +02:00
|
|
|
|
|
|
|
net = vhost_net_init(&options);
|
|
|
|
if (!net) {
|
|
|
|
error_report("failed to init vhost_net for queue");
|
2021-09-03 11:10:19 +02:00
|
|
|
goto err_init;
|
2020-07-01 16:55:38 +02:00
|
|
|
}
|
|
|
|
s->vhost_net = net;
|
|
|
|
ret = vhost_vdpa_net_check_device_id(net);
|
|
|
|
if (ret) {
|
2021-09-03 11:10:19 +02:00
|
|
|
goto err_check;
|
2020-07-01 16:55:38 +02:00
|
|
|
}
|
|
|
|
return 0;
|
2021-09-03 11:10:19 +02:00
|
|
|
err_check:
|
|
|
|
vhost_net_cleanup(net);
|
|
|
|
g_free(net);
|
|
|
|
err_init:
|
2020-07-01 16:55:38 +02:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void vhost_vdpa_cleanup(NetClientState *nc)
|
|
|
|
{
|
|
|
|
VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
|
|
|
|
|
2023-06-19 08:52:09 +02:00
|
|
|
/*
|
|
|
|
* If a peer NIC is attached, do not cleanup anything.
|
|
|
|
* Cleanup will happen as a part of qemu_cleanup() -> net_cleanup()
|
|
|
|
* when the guest is shutting down.
|
|
|
|
*/
|
|
|
|
if (nc->peer && nc->peer->info->type == NET_CLIENT_DRIVER_NIC) {
|
|
|
|
return;
|
|
|
|
}
|
2023-06-02 16:38:54 +02:00
|
|
|
munmap(s->cvq_cmd_out_buffer, vhost_vdpa_net_cvq_cmd_page_len());
|
|
|
|
munmap(s->status, vhost_vdpa_net_cvq_cmd_page_len());
|
2020-07-01 16:55:38 +02:00
|
|
|
if (s->vhost_net) {
|
|
|
|
vhost_net_cleanup(s->vhost_net);
|
|
|
|
g_free(s->vhost_net);
|
|
|
|
s->vhost_net = NULL;
|
2020-10-16 05:09:08 +02:00
|
|
|
}
|
2023-12-21 18:43:10 +01:00
|
|
|
if (s->vhost_vdpa.index != 0) {
|
|
|
|
return;
|
|
|
|
}
|
2023-12-21 18:43:15 +01:00
|
|
|
qemu_close(s->vhost_vdpa.shared->device_fd);
|
2023-12-21 18:43:10 +01:00
|
|
|
g_free(s->vhost_vdpa.shared);
|
2020-07-01 16:55:38 +02:00
|
|
|
}
|
|
|
|
|
2023-10-25 03:08:04 +02:00
|
|
|
/** Dummy SetSteeringEBPF to support RSS for vhost-vdpa backend */
|
|
|
|
static bool vhost_vdpa_set_steering_ebpf(NetClientState *nc, int prog_fd)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-07-01 16:55:38 +02:00
|
|
|
static bool vhost_vdpa_has_vnet_hdr(NetClientState *nc)
|
|
|
|
{
|
|
|
|
assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool vhost_vdpa_has_ufo(NetClientState *nc)
|
|
|
|
{
|
|
|
|
assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
|
|
|
|
uint64_t features = 0;
|
|
|
|
features |= (1ULL << VIRTIO_NET_F_HOST_UFO);
|
|
|
|
features = vhost_net_get_features(s->vhost_net, features);
|
|
|
|
return !!(features & (1ULL << VIRTIO_NET_F_HOST_UFO));
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2021-10-08 15:34:30 +02:00
|
|
|
static bool vhost_vdpa_check_peer_type(NetClientState *nc, ObjectClass *oc,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
const char *driver = object_class_get_name(oc);
|
|
|
|
|
|
|
|
if (!g_str_has_prefix(driver, "virtio-net-")) {
|
|
|
|
error_setg(errp, "vhost-vdpa requires frontend driver virtio-net-*");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-11-25 11:16:13 +01:00
|
|
|
/** Dummy receive in case qemu falls back to userland tap networking */
|
|
|
|
static ssize_t vhost_vdpa_receive(NetClientState *nc, const uint8_t *buf,
|
|
|
|
size_t size)
|
|
|
|
{
|
vhost-vdpa: fix assert !virtio_net_get_subqueue(nc)->async_tx.elem in virtio_net_reset
The citing commit has incorrect code in vhost_vdpa_receive() that returns
zero instead of full packet size to the caller. This renders pending packets
unable to be freed so then get clogged in the tx queue forever. When device
is being reset later on, below assertion failure ensues:
0 0x00007f86d53bb387 in raise () from /lib64/libc.so.6
1 0x00007f86d53bca78 in abort () from /lib64/libc.so.6
2 0x00007f86d53b41a6 in __assert_fail_base () from /lib64/libc.so.6
3 0x00007f86d53b4252 in __assert_fail () from /lib64/libc.so.6
4 0x000055b8f6ff6fcc in virtio_net_reset (vdev=<optimized out>) at /usr/src/debug/qemu/hw/net/virtio-net.c:563
5 0x000055b8f7012fcf in virtio_reset (opaque=0x55b8faf881f0) at /usr/src/debug/qemu/hw/virtio/virtio.c:1993
6 0x000055b8f71f0086 in virtio_bus_reset (bus=bus@entry=0x55b8faf88178) at /usr/src/debug/qemu/hw/virtio/virtio-bus.c:102
7 0x000055b8f71f1620 in virtio_pci_reset (qdev=<optimized out>) at /usr/src/debug/qemu/hw/virtio/virtio-pci.c:1845
8 0x000055b8f6fafc6c in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>,
size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /usr/src/debug/qemu/memory.c:483
9 0x000055b8f6fadce9 in access_with_adjusted_size (addr=addr@entry=20, value=value@entry=0x7f867e7fb7e8, size=size@entry=1,
access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55b8f6fafc20 <memory_region_write_accessor>,
mr=0x55b8faf80a50, attrs=...) at /usr/src/debug/qemu/memory.c:544
10 0x000055b8f6fb1d0b in memory_region_dispatch_write (mr=mr@entry=0x55b8faf80a50, addr=addr@entry=20, data=0, op=<optimized out>,
attrs=attrs@entry=...) at /usr/src/debug/qemu/memory.c:1470
11 0x000055b8f6f62ada in flatview_write_continue (fv=fv@entry=0x7f86ac04cd20, addr=addr@entry=549755813908, attrs=...,
attrs@entry=..., buf=buf@entry=0x7f86d0223028 <Address 0x7f86d0223028 out of bounds>, len=len@entry=1, addr1=20, l=1,
mr=0x55b8faf80a50) at /usr/src/debug/qemu/exec.c:3266
12 0x000055b8f6f62c8f in flatview_write (fv=0x7f86ac04cd20, addr=549755813908, attrs=...,
buf=0x7f86d0223028 <Address 0x7f86d0223028 out of bounds>, len=1) at /usr/src/debug/qemu/exec.c:3306
13 0x000055b8f6f674cb in address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=<optimized out>,
len=<optimized out>) at /usr/src/debug/qemu/exec.c:3396
14 0x000055b8f6f67575 in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., attrs@entry=...,
buf=buf@entry=0x7f86d0223028 <Address 0x7f86d0223028 out of bounds>, len=<optimized out>, is_write=<optimized out>)
at /usr/src/debug/qemu/exec.c:3406
15 0x000055b8f6fc1cc8 in kvm_cpu_exec (cpu=cpu@entry=0x55b8f9aa0e10) at /usr/src/debug/qemu/accel/kvm/kvm-all.c:2410
16 0x000055b8f6fa5f5e in qemu_kvm_cpu_thread_fn (arg=0x55b8f9aa0e10) at /usr/src/debug/qemu/cpus.c:1318
17 0x000055b8f7336e16 in qemu_thread_start (args=0x55b8f9ac8480) at /usr/src/debug/qemu/util/qemu-thread-posix.c:519
18 0x00007f86d575aea5 in start_thread () from /lib64/libpthread.so.0
19 0x00007f86d5483b2d in clone () from /lib64/libc.so.6
Make vhost_vdpa_receive() return the size passed in as is, so that the
caller qemu_deliver_packet_iov() would eventually propagate it back to
virtio_net_flush_tx() to release pending packets from the async_tx queue.
Which corresponds to the drop path where qemu_sendv_packet_async() returns
non-zero in virtio_net_flush_tx().
Fixes: 846a1e85da64 ("vdpa: Add dummy receive callback")
Cc: Eugenio Perez Martin <eperezma@redhat.com>
Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20221108041929.18417-2-jasowang@redhat.com>
2022-11-08 05:19:28 +01:00
|
|
|
return size;
|
2021-11-25 11:16:13 +01:00
|
|
|
}
|
|
|
|
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
static void vhost_vdpa_net_log_global_enable(VhostVDPAState *s, bool enable)
|
|
|
|
{
|
|
|
|
struct vhost_vdpa *v = &s->vhost_vdpa;
|
|
|
|
VirtIONet *n;
|
|
|
|
VirtIODevice *vdev;
|
|
|
|
int data_queue_pairs, cvq, r;
|
|
|
|
|
|
|
|
/* We are only called on the first data vqs and only if x-svq is not set */
|
|
|
|
if (s->vhost_vdpa.shadow_vqs_enabled == enable) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
vdev = v->dev->vdev;
|
|
|
|
n = VIRTIO_NET(vdev);
|
|
|
|
if (!n->vhost_started) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
data_queue_pairs = n->multiqueue ? n->max_queue_pairs : 1;
|
|
|
|
cvq = virtio_vdev_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) ?
|
|
|
|
n->max_ncs - n->max_queue_pairs : 0;
|
|
|
|
/*
|
|
|
|
* TODO: vhost_net_stop does suspend, get_base and reset. We can be smarter
|
|
|
|
* in the future and resume the device if read-only operations between
|
|
|
|
* suspend and reset goes wrong.
|
|
|
|
*/
|
|
|
|
vhost_net_stop(vdev, n->nic->ncs, data_queue_pairs, cvq);
|
|
|
|
|
|
|
|
/* Start will check migration setup_or_active to configure or not SVQ */
|
|
|
|
r = vhost_net_start(vdev, n->nic->ncs, data_queue_pairs, cvq);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
error_report("unable to start vhost net: %s(%d)", g_strerror(-r), -r);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-02-22 18:28:29 +01:00
|
|
|
static int vdpa_net_migration_state_notifier(NotifierWithReturn *notifier,
|
2024-02-22 18:28:32 +01:00
|
|
|
MigrationEvent *e, Error **errp)
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
{
|
2024-02-22 18:28:32 +01:00
|
|
|
VhostVDPAState *s = container_of(notifier, VhostVDPAState, migration_state);
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
|
2024-02-22 18:28:30 +01:00
|
|
|
if (e->type == MIG_EVENT_PRECOPY_SETUP) {
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
vhost_vdpa_net_log_global_enable(s, true);
|
2024-02-22 18:28:30 +01:00
|
|
|
} else if (e->type == MIG_EVENT_PRECOPY_FAILED) {
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
vhost_vdpa_net_log_global_enable(s, false);
|
|
|
|
}
|
2024-02-22 18:28:29 +01:00
|
|
|
return 0;
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
}
|
|
|
|
|
2023-03-03 18:24:32 +01:00
|
|
|
static void vhost_vdpa_net_data_start_first(VhostVDPAState *s)
|
|
|
|
{
|
|
|
|
struct vhost_vdpa *v = &s->vhost_vdpa;
|
|
|
|
|
2023-06-07 16:42:34 +02:00
|
|
|
migration_add_notifier(&s->migration_state,
|
|
|
|
vdpa_net_migration_state_notifier);
|
2023-03-03 18:24:32 +01:00
|
|
|
if (v->shadow_vqs_enabled) {
|
2023-12-21 18:43:12 +01:00
|
|
|
v->shared->iova_tree = vhost_iova_tree_new(v->shared->iova_range.first,
|
|
|
|
v->shared->iova_range.last);
|
2023-03-03 18:24:32 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vhost_vdpa_net_data_start(NetClientState *nc)
|
|
|
|
{
|
|
|
|
VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
|
|
|
|
struct vhost_vdpa *v = &s->vhost_vdpa;
|
|
|
|
|
|
|
|
assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
if (s->always_svq ||
|
|
|
|
migration_is_setup_or_active(migrate_get_current()->state)) {
|
|
|
|
v->shadow_vqs_enabled = true;
|
|
|
|
} else {
|
|
|
|
v->shadow_vqs_enabled = false;
|
|
|
|
}
|
|
|
|
|
2023-03-03 18:24:32 +01:00
|
|
|
if (v->index == 0) {
|
2023-12-21 18:43:13 +01:00
|
|
|
v->shared->shadow_data = v->shadow_vqs_enabled;
|
2023-03-03 18:24:32 +01:00
|
|
|
vhost_vdpa_net_data_start_first(s);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-08-22 10:53:29 +02:00
|
|
|
static int vhost_vdpa_net_data_load(NetClientState *nc)
|
|
|
|
{
|
|
|
|
VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
|
|
|
|
struct vhost_vdpa *v = &s->vhost_vdpa;
|
|
|
|
bool has_cvq = v->dev->vq_index_end % 2;
|
|
|
|
|
|
|
|
if (has_cvq) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = 0; i < v->dev->nvqs; ++i) {
|
|
|
|
vhost_vdpa_set_vring_ready(v, i + v->dev->vq_index);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-03-03 18:24:32 +01:00
|
|
|
static void vhost_vdpa_net_client_stop(NetClientState *nc)
|
|
|
|
{
|
|
|
|
VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
|
|
|
|
struct vhost_dev *dev;
|
|
|
|
|
|
|
|
assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
if (s->vhost_vdpa.index == 0) {
|
2023-06-07 16:42:34 +02:00
|
|
|
migration_remove_notifier(&s->migration_state);
|
vdpa: add vdpa net migration state notifier
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific and they could be done
in:
* vhost_vdpa_set_features (with VHOST_F_LOG_ALL)
* vhost_vdpa_set_vring_addr (with .enable_log)
* vhost_vdpa_set_log_base.
However, the vdpa net backend is the one with enough knowledge to
configure everything because of some reasons:
* Queues might need to be shadowed or not depending on its kind (control
vs data).
* Queues need to share the same map translations (iova tree).
Also, there are other problems that may have solutions but complicates
the implementation at this stage:
* We're basically duplicating vhost_dev_start and vhost_dev_stop, and
they could go out of sync. If we want to reuse them, we need a way to
skip some function calls to avoid recursiveness (either vhost_ops ->
vhost_set_features, vhost_set_vring_addr, ...).
* We need to traverse all vhost_dev of a given net device twice: one to
stop and get the vq state and another one after the reset to
configure properties like address, fd, etc.
Because of that it is cleaner to restart the whole net backend and
configure again as expected, similar to how vhost-kernel moves between
userspace and passthrough.
If more kinds of devices need dynamic switching to SVQ we can:
* Create a callback struct like VhostOps and move most of the code
there. VhostOps cannot be reused since all vdpa backend share them,
and to personalize just for networking would be too heavy.
* Add a parent struct or link all the vhost_vdpa or vhost_dev structs so
we can traverse them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230303172445.1089785-9-eperezma@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-03 18:24:39 +01:00
|
|
|
}
|
|
|
|
|
2023-03-03 18:24:32 +01:00
|
|
|
dev = s->vhost_vdpa.dev;
|
|
|
|
if (dev->vq_index + dev->nvqs == dev->vq_index_end) {
|
2023-12-21 18:43:11 +01:00
|
|
|
g_clear_pointer(&s->vhost_vdpa.shared->iova_tree,
|
|
|
|
vhost_iova_tree_delete);
|
2023-03-03 18:24:32 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-07-01 16:55:38 +02:00
|
|
|
static NetClientInfo net_vhost_vdpa_info = {
|
|
|
|
.type = NET_CLIENT_DRIVER_VHOST_VDPA,
|
|
|
|
.size = sizeof(VhostVDPAState),
|
2021-11-25 11:16:13 +01:00
|
|
|
.receive = vhost_vdpa_receive,
|
2023-03-03 18:24:32 +01:00
|
|
|
.start = vhost_vdpa_net_data_start,
|
2023-08-22 10:53:29 +02:00
|
|
|
.load = vhost_vdpa_net_data_load,
|
2023-03-03 18:24:32 +01:00
|
|
|
.stop = vhost_vdpa_net_client_stop,
|
2020-07-01 16:55:38 +02:00
|
|
|
.cleanup = vhost_vdpa_cleanup,
|
|
|
|
.has_vnet_hdr = vhost_vdpa_has_vnet_hdr,
|
|
|
|
.has_ufo = vhost_vdpa_has_ufo,
|
2021-10-08 15:34:30 +02:00
|
|
|
.check_peer_type = vhost_vdpa_check_peer_type,
|
2023-10-25 03:08:04 +02:00
|
|
|
.set_steering_ebpf = vhost_vdpa_set_steering_ebpf,
|
2020-07-01 16:55:38 +02:00
|
|
|
};
|
|
|
|
|
2023-05-26 17:31:43 +02:00
|
|
|
static int64_t vhost_vdpa_get_vring_group(int device_fd, unsigned vq_index,
|
|
|
|
Error **errp)
|
2022-12-15 12:31:44 +01:00
|
|
|
{
|
|
|
|
struct vhost_vring_state state = {
|
|
|
|
.index = vq_index,
|
|
|
|
};
|
|
|
|
int r = ioctl(device_fd, VHOST_VDPA_GET_VRING_GROUP, &state);
|
|
|
|
|
|
|
|
if (unlikely(r < 0)) {
|
2023-05-26 17:31:42 +02:00
|
|
|
r = -errno;
|
2023-05-26 17:31:43 +02:00
|
|
|
error_setg_errno(errp, errno, "Cannot get VQ %u group", vq_index);
|
2022-12-15 12:31:44 +01:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return state.num;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vhost_vdpa_set_address_space_id(struct vhost_vdpa *v,
|
|
|
|
unsigned vq_group,
|
|
|
|
unsigned asid_num)
|
|
|
|
{
|
|
|
|
struct vhost_vring_state asid = {
|
|
|
|
.index = vq_group,
|
|
|
|
.num = asid_num,
|
|
|
|
};
|
|
|
|
int r;
|
|
|
|
|
2023-12-21 18:43:15 +01:00
|
|
|
r = ioctl(v->shared->device_fd, VHOST_VDPA_SET_GROUP_ASID, &asid);
|
2022-12-15 12:31:44 +01:00
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
error_report("Can't set vq group %u asid %u, errno=%d (%s)",
|
|
|
|
asid.index, asid.num, errno, g_strerror(errno));
|
|
|
|
}
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2022-07-20 08:59:43 +02:00
|
|
|
static void vhost_vdpa_cvq_unmap_buf(struct vhost_vdpa *v, void *addr)
|
|
|
|
{
|
2023-12-21 18:43:11 +01:00
|
|
|
VhostIOVATree *tree = v->shared->iova_tree;
|
2022-07-20 08:59:43 +02:00
|
|
|
DMAMap needle = {
|
|
|
|
/*
|
|
|
|
* No need to specify size or to look for more translations since
|
|
|
|
* this contiguous chunk was allocated by us.
|
|
|
|
*/
|
|
|
|
.translated_addr = (hwaddr)(uintptr_t)addr,
|
|
|
|
};
|
|
|
|
const DMAMap *map = vhost_iova_tree_find_iova(tree, &needle);
|
|
|
|
int r;
|
|
|
|
|
|
|
|
if (unlikely(!map)) {
|
|
|
|
error_report("Cannot locate expected map");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-12-21 18:43:20 +01:00
|
|
|
r = vhost_vdpa_dma_unmap(v->shared, v->address_space_id, map->iova,
|
|
|
|
map->size + 1);
|
2022-07-20 08:59:43 +02:00
|
|
|
if (unlikely(r != 0)) {
|
|
|
|
error_report("Device cannot unmap: %s(%d)", g_strerror(r), r);
|
|
|
|
}
|
|
|
|
|
2022-08-23 20:20:04 +02:00
|
|
|
vhost_iova_tree_remove(tree, *map);
|
2022-07-20 08:59:43 +02:00
|
|
|
}
|
|
|
|
|
2022-08-23 20:30:33 +02:00
|
|
|
/** Map CVQ buffer. */
|
|
|
|
static int vhost_vdpa_cvq_map_buf(struct vhost_vdpa *v, void *buf, size_t size,
|
|
|
|
bool write)
|
2022-07-20 08:59:43 +02:00
|
|
|
{
|
|
|
|
DMAMap map = {};
|
|
|
|
int r;
|
|
|
|
|
|
|
|
map.translated_addr = (hwaddr)(uintptr_t)buf;
|
2022-08-23 20:30:33 +02:00
|
|
|
map.size = size - 1;
|
2022-07-20 08:59:43 +02:00
|
|
|
map.perm = write ? IOMMU_RW : IOMMU_RO,
|
2023-12-21 18:43:11 +01:00
|
|
|
r = vhost_iova_tree_map_alloc(v->shared->iova_tree, &map);
|
2022-07-20 08:59:43 +02:00
|
|
|
if (unlikely(r != IOVA_OK)) {
|
|
|
|
error_report("Cannot map injected element");
|
2022-08-23 20:30:33 +02:00
|
|
|
return r;
|
2022-07-20 08:59:43 +02:00
|
|
|
}
|
|
|
|
|
2023-12-21 18:43:20 +01:00
|
|
|
r = vhost_vdpa_dma_map(v->shared, v->address_space_id, map.iova,
|
2022-12-15 12:31:41 +01:00
|
|
|
vhost_vdpa_net_cvq_cmd_page_len(), buf, !write);
|
2022-07-20 08:59:43 +02:00
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
goto dma_map_err;
|
|
|
|
}
|
|
|
|
|
2022-08-23 20:30:33 +02:00
|
|
|
return 0;
|
2022-07-20 08:59:43 +02:00
|
|
|
|
|
|
|
dma_map_err:
|
2023-12-21 18:43:11 +01:00
|
|
|
vhost_iova_tree_remove(v->shared->iova_tree, map);
|
2022-08-23 20:30:33 +02:00
|
|
|
return r;
|
2022-07-20 08:59:43 +02:00
|
|
|
}
|
|
|
|
|
2022-08-23 20:30:33 +02:00
|
|
|
static int vhost_vdpa_net_cvq_start(NetClientState *nc)
|
2022-07-20 08:59:43 +02:00
|
|
|
{
|
2023-12-21 18:43:13 +01:00
|
|
|
VhostVDPAState *s;
|
2022-12-15 12:31:44 +01:00
|
|
|
struct vhost_vdpa *v;
|
|
|
|
int64_t cvq_group;
|
2023-05-26 17:31:43 +02:00
|
|
|
int r;
|
|
|
|
Error *err = NULL;
|
2022-07-20 08:59:43 +02:00
|
|
|
|
2022-08-23 20:30:33 +02:00
|
|
|
assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
|
|
|
|
s = DO_UPCAST(VhostVDPAState, nc, nc);
|
2022-12-15 12:31:44 +01:00
|
|
|
v = &s->vhost_vdpa;
|
|
|
|
|
2023-12-21 18:43:13 +01:00
|
|
|
v->shadow_vqs_enabled = v->shared->shadow_data;
|
2022-12-15 12:31:44 +01:00
|
|
|
s->vhost_vdpa.address_space_id = VHOST_VDPA_GUEST_PA_ASID;
|
|
|
|
|
2023-12-21 18:43:13 +01:00
|
|
|
if (v->shared->shadow_data) {
|
2022-12-15 12:31:44 +01:00
|
|
|
/* SVQ is already configured for all virtqueues */
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we early return in these cases SVQ will not be enabled. The migration
|
|
|
|
* will be blocked as long as vhost-vdpa backends will not offer _F_LOG.
|
|
|
|
*/
|
2023-05-26 17:31:43 +02:00
|
|
|
if (!vhost_vdpa_net_valid_svq_features(v->dev->features, NULL)) {
|
|
|
|
return 0;
|
2022-12-15 12:31:44 +01:00
|
|
|
}
|
2023-05-26 17:31:43 +02:00
|
|
|
|
|
|
|
if (!s->cvq_isolated) {
|
2022-12-15 12:31:44 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-12-21 18:43:15 +01:00
|
|
|
cvq_group = vhost_vdpa_get_vring_group(v->shared->device_fd,
|
2023-05-26 17:31:43 +02:00
|
|
|
v->dev->vq_index_end - 1,
|
|
|
|
&err);
|
2022-12-15 12:31:44 +01:00
|
|
|
if (unlikely(cvq_group < 0)) {
|
2023-05-26 17:31:43 +02:00
|
|
|
error_report_err(err);
|
2022-12-15 12:31:44 +01:00
|
|
|
return cvq_group;
|
|
|
|
}
|
|
|
|
|
|
|
|
r = vhost_vdpa_set_address_space_id(v, cvq_group, VHOST_VDPA_NET_CVQ_ASID);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
v->shadow_vqs_enabled = true;
|
|
|
|
s->vhost_vdpa.address_space_id = VHOST_VDPA_NET_CVQ_ASID;
|
|
|
|
|
|
|
|
out:
|
2022-08-23 20:30:33 +02:00
|
|
|
if (!s->vhost_vdpa.shadow_vqs_enabled) {
|
|
|
|
return 0;
|
2022-07-20 08:59:43 +02:00
|
|
|
}
|
|
|
|
|
2023-12-21 18:43:11 +01:00
|
|
|
/*
|
|
|
|
* If other vhost_vdpa already have an iova_tree, reuse it for simplicity,
|
|
|
|
* whether CVQ shares ASID with guest or not, because:
|
|
|
|
* - Memory listener need access to guest's memory addresses allocated in
|
|
|
|
* the IOVA tree.
|
|
|
|
* - There should be plenty of IOVA address space for both ASID not to
|
|
|
|
* worry about collisions between them. Guest's translations are still
|
|
|
|
* validated with virtio virtqueue_pop so there is no risk for the guest
|
|
|
|
* to access memory that it shouldn't.
|
|
|
|
*
|
|
|
|
* To allocate a iova tree per ASID is doable but it complicates the code
|
|
|
|
* and it is not worth it for the moment.
|
|
|
|
*/
|
|
|
|
if (!v->shared->iova_tree) {
|
2023-12-21 18:43:12 +01:00
|
|
|
v->shared->iova_tree = vhost_iova_tree_new(v->shared->iova_range.first,
|
|
|
|
v->shared->iova_range.last);
|
2023-03-03 18:24:32 +01:00
|
|
|
}
|
|
|
|
|
2022-08-23 20:30:33 +02:00
|
|
|
r = vhost_vdpa_cvq_map_buf(&s->vhost_vdpa, s->cvq_cmd_out_buffer,
|
|
|
|
vhost_vdpa_net_cvq_cmd_page_len(), false);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2022-09-06 17:07:14 +02:00
|
|
|
r = vhost_vdpa_cvq_map_buf(&s->vhost_vdpa, s->status,
|
2022-08-23 20:30:33 +02:00
|
|
|
vhost_vdpa_net_cvq_cmd_page_len(), true);
|
|
|
|
if (unlikely(r < 0)) {
|
2022-07-20 08:59:43 +02:00
|
|
|
vhost_vdpa_cvq_unmap_buf(&s->vhost_vdpa, s->cvq_cmd_out_buffer);
|
|
|
|
}
|
|
|
|
|
2022-08-23 20:30:33 +02:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void vhost_vdpa_net_cvq_stop(NetClientState *nc)
|
|
|
|
{
|
|
|
|
VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
|
|
|
|
|
|
|
|
assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
|
|
|
|
if (s->vhost_vdpa.shadow_vqs_enabled) {
|
|
|
|
vhost_vdpa_cvq_unmap_buf(&s->vhost_vdpa, s->cvq_cmd_out_buffer);
|
2022-09-06 17:07:14 +02:00
|
|
|
vhost_vdpa_cvq_unmap_buf(&s->vhost_vdpa, s->status);
|
2022-08-23 20:30:33 +02:00
|
|
|
}
|
2023-03-03 18:24:32 +01:00
|
|
|
|
|
|
|
vhost_vdpa_net_client_stop(nc);
|
2022-07-20 08:59:43 +02:00
|
|
|
}
|
|
|
|
|
2023-10-13 10:09:36 +02:00
|
|
|
static ssize_t vhost_vdpa_net_cvq_add(VhostVDPAState *s,
|
|
|
|
const struct iovec *out_sg, size_t out_num,
|
|
|
|
const struct iovec *in_sg, size_t in_num)
|
2022-08-23 20:30:34 +02:00
|
|
|
{
|
|
|
|
VhostShadowVirtqueue *svq = g_ptr_array_index(s->vhost_vdpa.shadow_vqs, 0);
|
|
|
|
int r;
|
|
|
|
|
2023-10-13 10:09:36 +02:00
|
|
|
r = vhost_svq_add(svq, out_sg, out_num, in_sg, in_num, NULL);
|
2022-08-23 20:30:34 +02:00
|
|
|
if (unlikely(r != 0)) {
|
|
|
|
if (unlikely(r == -ENOSPC)) {
|
|
|
|
qemu_log_mask(LOG_GUEST_ERROR, "%s: No space on device queue\n",
|
|
|
|
__func__);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-10-13 10:09:39 +02:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Convenience wrapper to poll SVQ for multiple control commands.
|
|
|
|
*
|
|
|
|
* Caller should hold the BQL when invoking this function, and should take
|
|
|
|
* the answer before SVQ pulls by itself when BQL is released.
|
|
|
|
*/
|
|
|
|
static ssize_t vhost_vdpa_net_svq_poll(VhostVDPAState *s, size_t cmds_in_flight)
|
|
|
|
{
|
|
|
|
VhostShadowVirtqueue *svq = g_ptr_array_index(s->vhost_vdpa.shadow_vqs, 0);
|
|
|
|
return vhost_svq_poll(svq, cmds_in_flight);
|
2022-08-23 20:30:34 +02:00
|
|
|
}
|
|
|
|
|
2023-10-13 10:09:40 +02:00
|
|
|
static void vhost_vdpa_net_load_cursor_reset(VhostVDPAState *s,
|
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor)
|
|
|
|
{
|
|
|
|
/* reset the cursor of the output buffer for the device */
|
|
|
|
out_cursor->iov_base = s->cvq_cmd_out_buffer;
|
|
|
|
out_cursor->iov_len = vhost_vdpa_net_cvq_cmd_page_len();
|
|
|
|
|
|
|
|
/* reset the cursor of the in buffer for the device */
|
|
|
|
in_cursor->iov_base = s->status;
|
|
|
|
in_cursor->iov_len = vhost_vdpa_net_cvq_cmd_page_len();
|
|
|
|
}
|
|
|
|
|
2023-10-13 10:09:42 +02:00
|
|
|
/*
|
|
|
|
* Poll SVQ for multiple pending control commands and check the device's ack.
|
|
|
|
*
|
|
|
|
* Caller should hold the BQL when invoking this function.
|
|
|
|
*
|
|
|
|
* @s: The VhostVDPAState
|
|
|
|
* @len: The length of the pending status shadow buffer
|
|
|
|
*/
|
|
|
|
static ssize_t vhost_vdpa_net_svq_flush(VhostVDPAState *s, size_t len)
|
|
|
|
{
|
|
|
|
/* device uses a one-byte length ack for each control command */
|
|
|
|
ssize_t dev_written = vhost_vdpa_net_svq_poll(s, len);
|
|
|
|
if (unlikely(dev_written != len)) {
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* check the device's ack */
|
|
|
|
for (int i = 0; i < len; ++i) {
|
|
|
|
if (s->status[i] != VIRTIO_NET_OK) {
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
2022-08-23 20:30:34 +02:00
|
|
|
}
|
|
|
|
|
2023-10-13 10:09:40 +02:00
|
|
|
static ssize_t vhost_vdpa_net_load_cmd(VhostVDPAState *s,
|
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor, uint8_t class,
|
2023-07-07 17:27:28 +02:00
|
|
|
uint8_t cmd, const struct iovec *data_sg,
|
|
|
|
size_t data_num)
|
2022-09-06 17:07:15 +02:00
|
|
|
{
|
|
|
|
const struct virtio_net_ctrl_hdr ctrl = {
|
|
|
|
.class = class,
|
|
|
|
.cmd = cmd,
|
|
|
|
};
|
2023-10-13 10:09:42 +02:00
|
|
|
size_t data_size = iov_size(data_sg, data_num), cmd_size;
|
2023-10-13 10:09:40 +02:00
|
|
|
struct iovec out, in;
|
2023-10-13 10:09:39 +02:00
|
|
|
ssize_t r;
|
2023-10-13 10:09:42 +02:00
|
|
|
unsigned dummy_cursor_iov_cnt;
|
|
|
|
VhostShadowVirtqueue *svq = g_ptr_array_index(s->vhost_vdpa.shadow_vqs, 0);
|
2022-09-06 17:07:15 +02:00
|
|
|
|
|
|
|
assert(data_size < vhost_vdpa_net_cvq_cmd_page_len() - sizeof(ctrl));
|
2023-10-13 10:09:42 +02:00
|
|
|
cmd_size = sizeof(ctrl) + data_size;
|
|
|
|
if (vhost_svq_available_slots(svq) < 2 ||
|
|
|
|
iov_size(out_cursor, 1) < cmd_size) {
|
|
|
|
/*
|
|
|
|
* It is time to flush all pending control commands if SVQ is full
|
|
|
|
* or control commands shadow buffers are full.
|
|
|
|
*
|
|
|
|
* We can poll here since we've had BQL from the time
|
|
|
|
* we sent the descriptor.
|
|
|
|
*/
|
|
|
|
r = vhost_vdpa_net_svq_flush(s, in_cursor->iov_base -
|
|
|
|
(void *)s->status);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
2022-09-06 17:07:15 +02:00
|
|
|
|
2023-10-13 10:09:42 +02:00
|
|
|
vhost_vdpa_net_load_cursor_reset(s, out_cursor, in_cursor);
|
|
|
|
}
|
2022-09-06 17:07:15 +02:00
|
|
|
|
2023-07-07 17:27:28 +02:00
|
|
|
/* pack the CVQ command header */
|
2023-10-13 10:09:40 +02:00
|
|
|
iov_from_buf(out_cursor, 1, 0, &ctrl, sizeof(ctrl));
|
2023-07-07 17:27:28 +02:00
|
|
|
/* pack the CVQ command command-specific-data */
|
|
|
|
iov_to_buf(data_sg, data_num, 0,
|
2023-10-13 10:09:40 +02:00
|
|
|
out_cursor->iov_base + sizeof(ctrl), data_size);
|
|
|
|
|
|
|
|
/* extract the required buffer from the cursor for output */
|
2023-10-13 10:09:42 +02:00
|
|
|
iov_copy(&out, 1, out_cursor, 1, 0, cmd_size);
|
2023-10-13 10:09:40 +02:00
|
|
|
/* extract the required buffer from the cursor for input */
|
|
|
|
iov_copy(&in, 1, in_cursor, 1, 0, sizeof(*s->status));
|
2023-07-07 17:27:28 +02:00
|
|
|
|
2023-10-13 10:09:39 +02:00
|
|
|
r = vhost_vdpa_net_cvq_add(s, &out, 1, &in, 1);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2023-10-13 10:09:42 +02:00
|
|
|
/* iterate the cursors */
|
|
|
|
dummy_cursor_iov_cnt = 1;
|
|
|
|
iov_discard_front(&out_cursor, &dummy_cursor_iov_cnt, cmd_size);
|
|
|
|
dummy_cursor_iov_cnt = 1;
|
|
|
|
iov_discard_front(&in_cursor, &dummy_cursor_iov_cnt, sizeof(*s->status));
|
2023-07-07 17:27:28 +02:00
|
|
|
|
2023-10-13 10:09:42 +02:00
|
|
|
return 0;
|
2022-09-06 17:07:15 +02:00
|
|
|
}
|
|
|
|
|
2023-10-13 10:09:40 +02:00
|
|
|
static int vhost_vdpa_net_load_mac(VhostVDPAState *s, const VirtIONet *n,
|
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor)
|
2022-09-06 17:07:15 +02:00
|
|
|
{
|
2023-06-02 13:52:14 +02:00
|
|
|
if (virtio_vdev_has_feature(&n->parent_obj, VIRTIO_NET_F_CTRL_MAC_ADDR)) {
|
2023-07-07 17:27:28 +02:00
|
|
|
const struct iovec data = {
|
|
|
|
.iov_base = (void *)n->mac,
|
|
|
|
.iov_len = sizeof(n->mac),
|
|
|
|
};
|
2023-10-13 10:09:42 +02:00
|
|
|
ssize_t r = vhost_vdpa_net_load_cmd(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_MAC,
|
|
|
|
VIRTIO_NET_CTRL_MAC_ADDR_SET,
|
|
|
|
&data, 1);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
2023-07-04 05:34:33 +02:00
|
|
|
}
|
2022-09-06 17:07:15 +02:00
|
|
|
}
|
|
|
|
|
2023-07-07 17:27:29 +02:00
|
|
|
/*
|
|
|
|
* According to VirtIO standard, "The device MUST have an
|
|
|
|
* empty MAC filtering table on reset.".
|
|
|
|
*
|
|
|
|
* Therefore, there is no need to send this CVQ command if the
|
|
|
|
* driver also sets an empty MAC filter table, which aligns with
|
|
|
|
* the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
if (!virtio_vdev_has_feature(&n->parent_obj, VIRTIO_NET_F_CTRL_RX) ||
|
|
|
|
n->mac_table.in_use == 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t uni_entries = n->mac_table.first_multi,
|
|
|
|
uni_macs_size = uni_entries * ETH_ALEN,
|
|
|
|
mul_entries = n->mac_table.in_use - uni_entries,
|
|
|
|
mul_macs_size = mul_entries * ETH_ALEN;
|
|
|
|
struct virtio_net_ctrl_mac uni = {
|
|
|
|
.entries = cpu_to_le32(uni_entries),
|
|
|
|
};
|
|
|
|
struct virtio_net_ctrl_mac mul = {
|
|
|
|
.entries = cpu_to_le32(mul_entries),
|
|
|
|
};
|
|
|
|
const struct iovec data[] = {
|
|
|
|
{
|
|
|
|
.iov_base = &uni,
|
|
|
|
.iov_len = sizeof(uni),
|
|
|
|
}, {
|
|
|
|
.iov_base = n->mac_table.macs,
|
|
|
|
.iov_len = uni_macs_size,
|
|
|
|
}, {
|
|
|
|
.iov_base = &mul,
|
|
|
|
.iov_len = sizeof(mul),
|
|
|
|
}, {
|
|
|
|
.iov_base = &n->mac_table.macs[uni_macs_size],
|
|
|
|
.iov_len = mul_macs_size,
|
|
|
|
},
|
|
|
|
};
|
2023-10-13 10:09:42 +02:00
|
|
|
ssize_t r = vhost_vdpa_net_load_cmd(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_MAC,
|
|
|
|
VIRTIO_NET_CTRL_MAC_TABLE_SET,
|
|
|
|
data, ARRAY_SIZE(data));
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
2023-07-07 17:27:29 +02:00
|
|
|
}
|
|
|
|
|
2022-09-06 17:07:15 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-10-25 03:02:24 +02:00
|
|
|
static int vhost_vdpa_net_load_rss(VhostVDPAState *s, const VirtIONet *n,
|
|
|
|
struct iovec *out_cursor,
|
2023-10-25 03:08:05 +02:00
|
|
|
struct iovec *in_cursor, bool do_rss)
|
2023-10-25 03:02:24 +02:00
|
|
|
{
|
|
|
|
struct virtio_net_rss_config cfg = {};
|
|
|
|
ssize_t r;
|
|
|
|
g_autofree uint16_t *table = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to VirtIO standard, "Initially the device has all hash
|
|
|
|
* types disabled and reports only VIRTIO_NET_HASH_REPORT_NONE.".
|
|
|
|
*
|
|
|
|
* Therefore, there is no need to send this CVQ command if the
|
|
|
|
* driver disables the all hash types, which aligns with
|
|
|
|
* the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
if (!n->rss_data.enabled ||
|
|
|
|
n->rss_data.hash_types == VIRTIO_NET_HASH_REPORT_NONE) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
table = g_malloc_n(n->rss_data.indirections_len,
|
|
|
|
sizeof(n->rss_data.indirections_table[0]));
|
|
|
|
cfg.hash_types = cpu_to_le32(n->rss_data.hash_types);
|
|
|
|
|
2023-10-25 03:08:05 +02:00
|
|
|
if (do_rss) {
|
|
|
|
/*
|
|
|
|
* According to VirtIO standard, "Number of entries in indirection_table
|
|
|
|
* is (indirection_table_mask + 1)".
|
|
|
|
*/
|
|
|
|
cfg.indirection_table_mask = cpu_to_le16(n->rss_data.indirections_len -
|
|
|
|
1);
|
|
|
|
cfg.unclassified_queue = cpu_to_le16(n->rss_data.default_queue);
|
|
|
|
for (int i = 0; i < n->rss_data.indirections_len; ++i) {
|
|
|
|
table[i] = cpu_to_le16(n->rss_data.indirections_table[i]);
|
|
|
|
}
|
|
|
|
cfg.max_tx_vq = cpu_to_le16(n->curr_queue_pairs);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* According to VirtIO standard, "Field reserved MUST contain zeroes.
|
|
|
|
* It is defined to make the structure to match the layout of
|
|
|
|
* virtio_net_rss_config structure, defined in 5.1.6.5.7.".
|
|
|
|
*
|
|
|
|
* Therefore, we need to zero the fields in
|
|
|
|
* struct virtio_net_rss_config, which corresponds to the
|
|
|
|
* `reserved` field in struct virtio_net_hash_config.
|
|
|
|
*
|
|
|
|
* Note that all other fields are zeroed at their definitions,
|
|
|
|
* except for the `indirection_table` field, where the actual data
|
|
|
|
* is stored in the `table` variable to ensure compatibility
|
|
|
|
* with RSS case. Therefore, we need to zero the `table` variable here.
|
|
|
|
*/
|
|
|
|
table[0] = 0;
|
|
|
|
}
|
2023-10-25 03:02:24 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Considering that virtio_net_handle_rss() currently does not restore
|
|
|
|
* the hash key length parsed from the CVQ command sent from the guest
|
|
|
|
* into n->rss_data and uses the maximum key length in other code, so
|
|
|
|
* we also employ the maximum key length here.
|
|
|
|
*/
|
|
|
|
cfg.hash_key_length = sizeof(n->rss_data.key);
|
|
|
|
|
|
|
|
const struct iovec data[] = {
|
|
|
|
{
|
|
|
|
.iov_base = &cfg,
|
|
|
|
.iov_len = offsetof(struct virtio_net_rss_config,
|
|
|
|
indirection_table),
|
|
|
|
}, {
|
|
|
|
.iov_base = table,
|
|
|
|
.iov_len = n->rss_data.indirections_len *
|
|
|
|
sizeof(n->rss_data.indirections_table[0]),
|
|
|
|
}, {
|
|
|
|
.iov_base = &cfg.max_tx_vq,
|
|
|
|
.iov_len = offsetof(struct virtio_net_rss_config, hash_key_data) -
|
|
|
|
offsetof(struct virtio_net_rss_config, max_tx_vq),
|
|
|
|
}, {
|
|
|
|
.iov_base = (void *)n->rss_data.key,
|
|
|
|
.iov_len = sizeof(n->rss_data.key),
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
r = vhost_vdpa_net_load_cmd(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_MQ,
|
2023-10-25 03:08:05 +02:00
|
|
|
do_rss ? VIRTIO_NET_CTRL_MQ_RSS_CONFIG :
|
2023-10-25 03:02:24 +02:00
|
|
|
VIRTIO_NET_CTRL_MQ_HASH_CONFIG,
|
|
|
|
data, ARRAY_SIZE(data));
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-09-06 17:07:16 +02:00
|
|
|
static int vhost_vdpa_net_load_mq(VhostVDPAState *s,
|
2023-10-13 10:09:40 +02:00
|
|
|
const VirtIONet *n,
|
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor)
|
2022-09-06 17:07:16 +02:00
|
|
|
{
|
|
|
|
struct virtio_net_ctrl_mq mq;
|
2023-10-13 10:09:42 +02:00
|
|
|
ssize_t r;
|
2022-09-06 17:07:16 +02:00
|
|
|
|
2023-06-02 13:52:14 +02:00
|
|
|
if (!virtio_vdev_has_feature(&n->parent_obj, VIRTIO_NET_F_MQ)) {
|
2022-09-06 17:07:16 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
mq.virtqueue_pairs = cpu_to_le16(n->curr_queue_pairs);
|
2023-07-07 17:27:28 +02:00
|
|
|
const struct iovec data = {
|
|
|
|
.iov_base = &mq,
|
|
|
|
.iov_len = sizeof(mq),
|
|
|
|
};
|
2023-10-13 10:09:42 +02:00
|
|
|
r = vhost_vdpa_net_load_cmd(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_MQ,
|
|
|
|
VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET,
|
|
|
|
&data, 1);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
2023-07-04 05:34:34 +02:00
|
|
|
}
|
2022-09-06 17:07:16 +02:00
|
|
|
|
2023-10-25 03:08:05 +02:00
|
|
|
if (virtio_vdev_has_feature(&n->parent_obj, VIRTIO_NET_F_RSS)) {
|
|
|
|
/* load the receive-side scaling state */
|
|
|
|
r = vhost_vdpa_net_load_rss(s, n, out_cursor, in_cursor, true);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
} else if (virtio_vdev_has_feature(&n->parent_obj,
|
|
|
|
VIRTIO_NET_F_HASH_REPORT)) {
|
|
|
|
/* load the hash calculation state */
|
|
|
|
r = vhost_vdpa_net_load_rss(s, n, out_cursor, in_cursor, false);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
2023-10-25 03:02:24 +02:00
|
|
|
}
|
|
|
|
|
2023-07-04 05:34:34 +02:00
|
|
|
return 0;
|
2022-09-06 17:07:16 +02:00
|
|
|
}
|
|
|
|
|
2023-06-02 13:52:17 +02:00
|
|
|
static int vhost_vdpa_net_load_offloads(VhostVDPAState *s,
|
2023-10-13 10:09:40 +02:00
|
|
|
const VirtIONet *n,
|
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor)
|
2023-06-02 13:52:17 +02:00
|
|
|
{
|
|
|
|
uint64_t offloads;
|
2023-10-13 10:09:42 +02:00
|
|
|
ssize_t r;
|
2023-06-02 13:52:17 +02:00
|
|
|
|
|
|
|
if (!virtio_vdev_has_feature(&n->parent_obj,
|
|
|
|
VIRTIO_NET_F_CTRL_GUEST_OFFLOADS)) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (n->curr_guest_offloads == virtio_net_supported_guest_offloads(n)) {
|
|
|
|
/*
|
|
|
|
* According to VirtIO standard, "Upon feature negotiation
|
|
|
|
* corresponding offload gets enabled to preserve
|
|
|
|
* backward compatibility.".
|
|
|
|
*
|
|
|
|
* Therefore, there is no need to send this CVQ command if the
|
|
|
|
* driver also enables all supported offloads, which aligns with
|
|
|
|
* the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
offloads = cpu_to_le64(n->curr_guest_offloads);
|
2023-07-07 17:27:28 +02:00
|
|
|
const struct iovec data = {
|
|
|
|
.iov_base = &offloads,
|
|
|
|
.iov_len = sizeof(offloads),
|
|
|
|
};
|
2023-10-13 10:09:42 +02:00
|
|
|
r = vhost_vdpa_net_load_cmd(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_GUEST_OFFLOADS,
|
|
|
|
VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET,
|
|
|
|
&data, 1);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
2023-07-04 05:34:35 +02:00
|
|
|
}
|
2023-06-02 13:52:17 +02:00
|
|
|
|
2023-07-04 05:34:35 +02:00
|
|
|
return 0;
|
2023-06-02 13:52:17 +02:00
|
|
|
}
|
|
|
|
|
2023-07-07 17:27:30 +02:00
|
|
|
static int vhost_vdpa_net_load_rx_mode(VhostVDPAState *s,
|
2023-10-13 10:09:40 +02:00
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor,
|
2023-07-07 17:27:30 +02:00
|
|
|
uint8_t cmd,
|
|
|
|
uint8_t on)
|
|
|
|
{
|
|
|
|
const struct iovec data = {
|
|
|
|
.iov_base = &on,
|
|
|
|
.iov_len = sizeof(on),
|
|
|
|
};
|
2023-10-13 10:09:42 +02:00
|
|
|
ssize_t r;
|
2023-10-13 10:09:38 +02:00
|
|
|
|
2023-10-13 10:09:42 +02:00
|
|
|
r = vhost_vdpa_net_load_cmd(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_RX, cmd, &data, 1);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
2023-10-13 10:09:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2023-07-07 17:27:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static int vhost_vdpa_net_load_rx(VhostVDPAState *s,
|
2023-10-13 10:09:40 +02:00
|
|
|
const VirtIONet *n,
|
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor)
|
2023-07-07 17:27:30 +02:00
|
|
|
{
|
2023-10-13 10:09:38 +02:00
|
|
|
ssize_t r;
|
2023-07-07 17:27:30 +02:00
|
|
|
|
|
|
|
if (!virtio_vdev_has_feature(&n->parent_obj, VIRTIO_NET_F_CTRL_RX)) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to virtio_net_reset(), device turns promiscuous mode
|
|
|
|
* on by default.
|
|
|
|
*
|
2023-07-14 13:33:49 +02:00
|
|
|
* Additionally, according to VirtIO standard, "Since there are
|
2023-07-07 17:27:30 +02:00
|
|
|
* no guarantees, it can use a hash filter or silently switch to
|
|
|
|
* allmulti or promiscuous mode if it is given too many addresses.".
|
|
|
|
* QEMU marks `n->mac_table.uni_overflow` if guest sets too many
|
|
|
|
* non-multicast MAC addresses, indicating that promiscuous mode
|
|
|
|
* should be enabled.
|
|
|
|
*
|
|
|
|
* Therefore, QEMU should only send this CVQ command if the
|
|
|
|
* `n->mac_table.uni_overflow` is not marked and `n->promisc` is off,
|
|
|
|
* which sets promiscuous mode on, different from the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
if (!n->mac_table.uni_overflow && !n->promisc) {
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_rx_mode(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_RX_PROMISC, 0);
|
2023-10-13 10:09:38 +02:00
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
2023-07-07 17:27:30 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to virtio_net_reset(), device turns all-multicast mode
|
|
|
|
* off by default.
|
|
|
|
*
|
|
|
|
* According to VirtIO standard, "Since there are no guarantees,
|
|
|
|
* it can use a hash filter or silently switch to allmulti or
|
|
|
|
* promiscuous mode if it is given too many addresses.". QEMU marks
|
|
|
|
* `n->mac_table.multi_overflow` if guest sets too many
|
|
|
|
* non-multicast MAC addresses.
|
|
|
|
*
|
|
|
|
* Therefore, QEMU should only send this CVQ command if the
|
|
|
|
* `n->mac_table.multi_overflow` is marked or `n->allmulti` is on,
|
|
|
|
* which sets all-multicast mode on, different from the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
if (n->mac_table.multi_overflow || n->allmulti) {
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_rx_mode(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_RX_ALLMULTI, 1);
|
2023-10-13 10:09:38 +02:00
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
2023-07-07 17:27:30 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-07-08 11:24:51 +02:00
|
|
|
if (!virtio_vdev_has_feature(&n->parent_obj, VIRTIO_NET_F_CTRL_RX_EXTRA)) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to virtio_net_reset(), device turns all-unicast mode
|
|
|
|
* off by default.
|
|
|
|
*
|
|
|
|
* Therefore, QEMU should only send this CVQ command if the driver
|
|
|
|
* sets all-unicast mode on, different from the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
if (n->alluni) {
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_rx_mode(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_RX_ALLUNI, 1);
|
2023-10-13 10:09:38 +02:00
|
|
|
if (r < 0) {
|
|
|
|
return r;
|
2023-07-08 11:24:51 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to virtio_net_reset(), device turns non-multicast mode
|
|
|
|
* off by default.
|
|
|
|
*
|
|
|
|
* Therefore, QEMU should only send this CVQ command if the driver
|
|
|
|
* sets non-multicast mode on, different from the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
if (n->nomulti) {
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_rx_mode(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_RX_NOMULTI, 1);
|
2023-10-13 10:09:38 +02:00
|
|
|
if (r < 0) {
|
|
|
|
return r;
|
2023-07-08 11:24:51 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to virtio_net_reset(), device turns non-unicast mode
|
|
|
|
* off by default.
|
|
|
|
*
|
|
|
|
* Therefore, QEMU should only send this CVQ command if the driver
|
|
|
|
* sets non-unicast mode on, different from the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
if (n->nouni) {
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_rx_mode(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_RX_NOUNI, 1);
|
2023-10-13 10:09:38 +02:00
|
|
|
if (r < 0) {
|
|
|
|
return r;
|
2023-07-08 11:24:51 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to virtio_net_reset(), device turns non-broadcast mode
|
|
|
|
* off by default.
|
|
|
|
*
|
|
|
|
* Therefore, QEMU should only send this CVQ command if the driver
|
|
|
|
* sets non-broadcast mode on, different from the device's defaults.
|
|
|
|
*
|
|
|
|
* Note that the device's defaults can mismatch the driver's
|
|
|
|
* configuration only at live migration.
|
|
|
|
*/
|
|
|
|
if (n->nobcast) {
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_rx_mode(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_RX_NOBCAST, 1);
|
2023-10-13 10:09:38 +02:00
|
|
|
if (r < 0) {
|
|
|
|
return r;
|
2023-07-08 11:24:51 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-07-07 17:27:30 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-07-23 14:09:13 +02:00
|
|
|
static int vhost_vdpa_net_load_single_vlan(VhostVDPAState *s,
|
|
|
|
const VirtIONet *n,
|
2023-10-13 10:09:40 +02:00
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor,
|
2023-07-23 14:09:13 +02:00
|
|
|
uint16_t vid)
|
|
|
|
{
|
|
|
|
const struct iovec data = {
|
|
|
|
.iov_base = &vid,
|
|
|
|
.iov_len = sizeof(vid),
|
|
|
|
};
|
2023-10-13 10:09:42 +02:00
|
|
|
ssize_t r = vhost_vdpa_net_load_cmd(s, out_cursor, in_cursor,
|
|
|
|
VIRTIO_NET_CTRL_VLAN,
|
|
|
|
VIRTIO_NET_CTRL_VLAN_ADD,
|
|
|
|
&data, 1);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
2023-07-23 14:09:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vhost_vdpa_net_load_vlan(VhostVDPAState *s,
|
2023-10-13 10:09:40 +02:00
|
|
|
const VirtIONet *n,
|
|
|
|
struct iovec *out_cursor,
|
|
|
|
struct iovec *in_cursor)
|
2023-07-23 14:09:13 +02:00
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
|
|
|
if (!virtio_vdev_has_feature(&n->parent_obj, VIRTIO_NET_F_CTRL_VLAN)) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = 0; i < MAX_VLAN >> 5; i++) {
|
|
|
|
for (int j = 0; n->vlans[i] && j <= 0x1f; j++) {
|
|
|
|
if (n->vlans[i] & (1U << j)) {
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_single_vlan(s, n, out_cursor,
|
|
|
|
in_cursor, (i << 5) + j);
|
2023-07-23 14:09:13 +02:00
|
|
|
if (unlikely(r != 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-08-22 10:53:28 +02:00
|
|
|
static int vhost_vdpa_net_cvq_load(NetClientState *nc)
|
2022-08-23 20:30:36 +02:00
|
|
|
{
|
|
|
|
VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
|
2022-09-06 17:07:15 +02:00
|
|
|
struct vhost_vdpa *v = &s->vhost_vdpa;
|
2022-08-23 20:30:36 +02:00
|
|
|
const VirtIONet *n;
|
2022-09-06 17:07:15 +02:00
|
|
|
int r;
|
2023-10-13 10:09:40 +02:00
|
|
|
struct iovec out_cursor, in_cursor;
|
2022-08-23 20:30:36 +02:00
|
|
|
|
|
|
|
assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
|
2023-08-22 10:53:29 +02:00
|
|
|
vhost_vdpa_set_vring_ready(v, v->dev->vq_index);
|
2022-08-23 20:30:36 +02:00
|
|
|
|
2023-08-22 10:53:29 +02:00
|
|
|
if (v->shadow_vqs_enabled) {
|
|
|
|
n = VIRTIO_NET(v->dev->vdev);
|
2023-10-13 10:09:40 +02:00
|
|
|
vhost_vdpa_net_load_cursor_reset(s, &out_cursor, &in_cursor);
|
|
|
|
r = vhost_vdpa_net_load_mac(s, n, &out_cursor, &in_cursor);
|
2023-08-22 10:53:29 +02:00
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_mq(s, n, &out_cursor, &in_cursor);
|
2023-08-22 10:53:29 +02:00
|
|
|
if (unlikely(r)) {
|
|
|
|
return r;
|
|
|
|
}
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_offloads(s, n, &out_cursor, &in_cursor);
|
2023-08-22 10:53:29 +02:00
|
|
|
if (unlikely(r)) {
|
|
|
|
return r;
|
|
|
|
}
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_rx(s, n, &out_cursor, &in_cursor);
|
2023-08-22 10:53:29 +02:00
|
|
|
if (unlikely(r)) {
|
|
|
|
return r;
|
|
|
|
}
|
2023-10-13 10:09:40 +02:00
|
|
|
r = vhost_vdpa_net_load_vlan(s, n, &out_cursor, &in_cursor);
|
2023-08-22 10:53:29 +02:00
|
|
|
if (unlikely(r)) {
|
|
|
|
return r;
|
|
|
|
}
|
2023-10-13 10:09:42 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to poll and check all pending device's used buffers.
|
|
|
|
*
|
|
|
|
* We can poll here since we've had BQL from the time
|
|
|
|
* we sent the descriptor.
|
|
|
|
*/
|
|
|
|
r = vhost_vdpa_net_svq_flush(s, in_cursor.iov_base - (void *)s->status);
|
2023-08-22 10:53:29 +02:00
|
|
|
if (unlikely(r)) {
|
|
|
|
return r;
|
|
|
|
}
|
2023-07-07 17:27:30 +02:00
|
|
|
}
|
2023-08-22 10:53:29 +02:00
|
|
|
|
|
|
|
for (int i = 0; i < v->dev->vq_index; ++i) {
|
|
|
|
vhost_vdpa_set_vring_ready(v, i);
|
2023-07-23 14:09:13 +02:00
|
|
|
}
|
2022-08-23 20:30:36 +02:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-08-23 20:30:32 +02:00
|
|
|
static NetClientInfo net_vhost_vdpa_cvq_info = {
|
|
|
|
.type = NET_CLIENT_DRIVER_VHOST_VDPA,
|
|
|
|
.size = sizeof(VhostVDPAState),
|
|
|
|
.receive = vhost_vdpa_receive,
|
2022-08-23 20:30:33 +02:00
|
|
|
.start = vhost_vdpa_net_cvq_start,
|
2023-08-22 10:53:28 +02:00
|
|
|
.load = vhost_vdpa_net_cvq_load,
|
2022-08-23 20:30:33 +02:00
|
|
|
.stop = vhost_vdpa_net_cvq_stop,
|
2022-08-23 20:30:32 +02:00
|
|
|
.cleanup = vhost_vdpa_cleanup,
|
|
|
|
.has_vnet_hdr = vhost_vdpa_has_vnet_hdr,
|
|
|
|
.has_ufo = vhost_vdpa_has_ufo,
|
|
|
|
.check_peer_type = vhost_vdpa_check_peer_type,
|
2023-10-25 03:08:04 +02:00
|
|
|
.set_steering_ebpf = vhost_vdpa_set_steering_ebpf,
|
2022-08-23 20:30:32 +02:00
|
|
|
};
|
|
|
|
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
/*
|
|
|
|
* Forward the excessive VIRTIO_NET_CTRL_MAC_TABLE_SET CVQ command to
|
|
|
|
* vdpa device.
|
|
|
|
*
|
|
|
|
* Considering that QEMU cannot send the entire filter table to the
|
|
|
|
* vdpa device, it should send the VIRTIO_NET_CTRL_RX_PROMISC CVQ
|
|
|
|
* command to enable promiscuous mode to receive all packets,
|
|
|
|
* according to VirtIO standard, "Since there are no guarantees,
|
|
|
|
* it can use a hash filter or silently switch to allmulti or
|
|
|
|
* promiscuous mode if it is given too many addresses.".
|
|
|
|
*
|
|
|
|
* Since QEMU ignores MAC addresses beyond `MAC_TABLE_ENTRIES` and
|
|
|
|
* marks `n->mac_table.x_overflow` accordingly, it should have
|
|
|
|
* the same effect on the device model to receive
|
|
|
|
* (`MAC_TABLE_ENTRIES` + 1) or more non-multicast MAC addresses.
|
|
|
|
* The same applies to multicast MAC addresses.
|
|
|
|
*
|
|
|
|
* Therefore, QEMU can provide the device model with a fake
|
|
|
|
* VIRTIO_NET_CTRL_MAC_TABLE_SET command with (`MAC_TABLE_ENTRIES` + 1)
|
|
|
|
* non-multicast MAC addresses and (`MAC_TABLE_ENTRIES` + 1) multicast
|
|
|
|
* MAC addresses. This ensures that the device model marks
|
|
|
|
* `n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
|
|
|
|
* allowing all packets to be received, which aligns with the
|
|
|
|
* state of the vdpa device.
|
|
|
|
*/
|
|
|
|
static int vhost_vdpa_net_excessive_mac_filter_cvq_add(VhostVDPAState *s,
|
|
|
|
VirtQueueElement *elem,
|
2023-10-13 10:09:37 +02:00
|
|
|
struct iovec *out,
|
|
|
|
const struct iovec *in)
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
{
|
|
|
|
struct virtio_net_ctrl_mac mac_data, *mac_ptr;
|
|
|
|
struct virtio_net_ctrl_hdr *hdr_ptr;
|
|
|
|
uint32_t cursor;
|
|
|
|
ssize_t r;
|
2023-10-13 10:09:37 +02:00
|
|
|
uint8_t on = 1;
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
|
|
|
|
/* parse the non-multicast MAC address entries from CVQ command */
|
|
|
|
cursor = sizeof(*hdr_ptr);
|
|
|
|
r = iov_to_buf(elem->out_sg, elem->out_num, cursor,
|
|
|
|
&mac_data, sizeof(mac_data));
|
|
|
|
if (unlikely(r != sizeof(mac_data))) {
|
|
|
|
/*
|
|
|
|
* If the CVQ command is invalid, we should simulate the vdpa device
|
|
|
|
* to reject the VIRTIO_NET_CTRL_MAC_TABLE_SET CVQ command
|
|
|
|
*/
|
|
|
|
*s->status = VIRTIO_NET_ERR;
|
|
|
|
return sizeof(*s->status);
|
|
|
|
}
|
|
|
|
cursor += sizeof(mac_data) + le32_to_cpu(mac_data.entries) * ETH_ALEN;
|
|
|
|
|
|
|
|
/* parse the multicast MAC address entries from CVQ command */
|
|
|
|
r = iov_to_buf(elem->out_sg, elem->out_num, cursor,
|
|
|
|
&mac_data, sizeof(mac_data));
|
|
|
|
if (r != sizeof(mac_data)) {
|
|
|
|
/*
|
|
|
|
* If the CVQ command is invalid, we should simulate the vdpa device
|
|
|
|
* to reject the VIRTIO_NET_CTRL_MAC_TABLE_SET CVQ command
|
|
|
|
*/
|
|
|
|
*s->status = VIRTIO_NET_ERR;
|
|
|
|
return sizeof(*s->status);
|
|
|
|
}
|
|
|
|
cursor += sizeof(mac_data) + le32_to_cpu(mac_data.entries) * ETH_ALEN;
|
|
|
|
|
|
|
|
/* validate the CVQ command */
|
|
|
|
if (iov_size(elem->out_sg, elem->out_num) != cursor) {
|
|
|
|
/*
|
|
|
|
* If the CVQ command is invalid, we should simulate the vdpa device
|
|
|
|
* to reject the VIRTIO_NET_CTRL_MAC_TABLE_SET CVQ command
|
|
|
|
*/
|
|
|
|
*s->status = VIRTIO_NET_ERR;
|
|
|
|
return sizeof(*s->status);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to VirtIO standard, "Since there are no guarantees,
|
|
|
|
* it can use a hash filter or silently switch to allmulti or
|
|
|
|
* promiscuous mode if it is given too many addresses.".
|
|
|
|
*
|
|
|
|
* Therefore, considering that QEMU is unable to send the entire
|
|
|
|
* filter table to the vdpa device, it should send the
|
|
|
|
* VIRTIO_NET_CTRL_RX_PROMISC CVQ command to enable promiscuous mode
|
|
|
|
*/
|
2023-10-13 10:09:37 +02:00
|
|
|
hdr_ptr = out->iov_base;
|
|
|
|
out->iov_len = sizeof(*hdr_ptr) + sizeof(on);
|
|
|
|
|
|
|
|
hdr_ptr->class = VIRTIO_NET_CTRL_RX;
|
|
|
|
hdr_ptr->cmd = VIRTIO_NET_CTRL_RX_PROMISC;
|
|
|
|
iov_from_buf(out, 1, sizeof(*hdr_ptr), &on, sizeof(on));
|
|
|
|
r = vhost_vdpa_net_cvq_add(s, out, 1, in, 1);
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
return r;
|
|
|
|
}
|
2023-10-13 10:09:39 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We can poll here since we've had BQL from the time
|
|
|
|
* we sent the descriptor.
|
|
|
|
*/
|
|
|
|
r = vhost_vdpa_net_svq_poll(s, 1);
|
|
|
|
if (unlikely(r < sizeof(*s->status))) {
|
|
|
|
return r;
|
|
|
|
}
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
if (*s->status != VIRTIO_NET_OK) {
|
|
|
|
return sizeof(*s->status);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* QEMU should also send a fake VIRTIO_NET_CTRL_MAC_TABLE_SET CVQ
|
|
|
|
* command to the device model, including (`MAC_TABLE_ENTRIES` + 1)
|
|
|
|
* non-multicast MAC addresses and (`MAC_TABLE_ENTRIES` + 1)
|
|
|
|
* multicast MAC addresses.
|
|
|
|
*
|
|
|
|
* By doing so, the device model can mark `n->mac_table.uni_overflow`
|
|
|
|
* and `n->mac_table.multi_overflow`, enabling all packets to be
|
|
|
|
* received, which aligns with the state of the vdpa device.
|
|
|
|
*/
|
|
|
|
cursor = 0;
|
|
|
|
uint32_t fake_uni_entries = MAC_TABLE_ENTRIES + 1,
|
|
|
|
fake_mul_entries = MAC_TABLE_ENTRIES + 1,
|
|
|
|
fake_cvq_size = sizeof(struct virtio_net_ctrl_hdr) +
|
|
|
|
sizeof(mac_data) + fake_uni_entries * ETH_ALEN +
|
|
|
|
sizeof(mac_data) + fake_mul_entries * ETH_ALEN;
|
|
|
|
|
|
|
|
assert(fake_cvq_size < vhost_vdpa_net_cvq_cmd_page_len());
|
|
|
|
out->iov_len = fake_cvq_size;
|
|
|
|
|
|
|
|
/* pack the header for fake CVQ command */
|
|
|
|
hdr_ptr = out->iov_base + cursor;
|
|
|
|
hdr_ptr->class = VIRTIO_NET_CTRL_MAC;
|
|
|
|
hdr_ptr->cmd = VIRTIO_NET_CTRL_MAC_TABLE_SET;
|
|
|
|
cursor += sizeof(*hdr_ptr);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pack the non-multicast MAC addresses part for fake CVQ command.
|
|
|
|
*
|
|
|
|
* According to virtio_net_handle_mac(), QEMU doesn't verify the MAC
|
2023-07-14 13:33:49 +02:00
|
|
|
* addresses provided in CVQ command. Therefore, only the entries
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
* field need to be prepared in the CVQ command.
|
|
|
|
*/
|
|
|
|
mac_ptr = out->iov_base + cursor;
|
|
|
|
mac_ptr->entries = cpu_to_le32(fake_uni_entries);
|
|
|
|
cursor += sizeof(*mac_ptr) + fake_uni_entries * ETH_ALEN;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pack the multicast MAC addresses part for fake CVQ command.
|
|
|
|
*
|
|
|
|
* According to virtio_net_handle_mac(), QEMU doesn't verify the MAC
|
2023-07-14 13:33:49 +02:00
|
|
|
* addresses provided in CVQ command. Therefore, only the entries
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
* field need to be prepared in the CVQ command.
|
|
|
|
*/
|
|
|
|
mac_ptr = out->iov_base + cursor;
|
|
|
|
mac_ptr->entries = cpu_to_le32(fake_mul_entries);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Simulating QEMU poll a vdpa device used buffer
|
|
|
|
* for VIRTIO_NET_CTRL_MAC_TABLE_SET CVQ command
|
|
|
|
*/
|
|
|
|
return sizeof(*s->status);
|
|
|
|
}
|
|
|
|
|
2022-07-20 08:59:43 +02:00
|
|
|
/**
|
|
|
|
* Validate and copy control virtqueue commands.
|
|
|
|
*
|
|
|
|
* Following QEMU guidelines, we offer a copy of the buffers to the device to
|
|
|
|
* prevent TOCTOU bugs.
|
2022-07-20 08:59:42 +02:00
|
|
|
*/
|
|
|
|
static int vhost_vdpa_net_handle_ctrl_avail(VhostShadowVirtqueue *svq,
|
|
|
|
VirtQueueElement *elem,
|
|
|
|
void *opaque)
|
|
|
|
{
|
2022-07-20 08:59:43 +02:00
|
|
|
VhostVDPAState *s = opaque;
|
2022-08-23 20:30:34 +02:00
|
|
|
size_t in_len;
|
2023-07-07 17:27:32 +02:00
|
|
|
const struct virtio_net_ctrl_hdr *ctrl;
|
2022-07-20 08:59:42 +02:00
|
|
|
virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
|
2022-08-23 20:30:33 +02:00
|
|
|
/* Out buffer sent to both the vdpa device and the device model */
|
|
|
|
struct iovec out = {
|
|
|
|
.iov_base = s->cvq_cmd_out_buffer,
|
|
|
|
};
|
2022-07-20 08:59:43 +02:00
|
|
|
/* in buffer used for device model */
|
2023-10-13 10:09:36 +02:00
|
|
|
const struct iovec model_in = {
|
2022-07-20 08:59:43 +02:00
|
|
|
.iov_base = &status,
|
|
|
|
.iov_len = sizeof(status),
|
|
|
|
};
|
2023-10-13 10:09:36 +02:00
|
|
|
/* in buffer used for vdpa device */
|
|
|
|
const struct iovec vdpa_in = {
|
|
|
|
.iov_base = s->status,
|
|
|
|
.iov_len = sizeof(*s->status),
|
|
|
|
};
|
2022-08-23 20:30:34 +02:00
|
|
|
ssize_t dev_written = -EINVAL;
|
2022-07-20 08:59:43 +02:00
|
|
|
|
2022-08-23 20:30:33 +02:00
|
|
|
out.iov_len = iov_to_buf(elem->out_sg, elem->out_num, 0,
|
|
|
|
s->cvq_cmd_out_buffer,
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
vhost_vdpa_net_cvq_cmd_page_len());
|
2023-07-07 17:27:32 +02:00
|
|
|
|
|
|
|
ctrl = s->cvq_cmd_out_buffer;
|
|
|
|
if (ctrl->class == VIRTIO_NET_CTRL_ANNOUNCE) {
|
2022-12-21 12:50:14 +01:00
|
|
|
/*
|
|
|
|
* Guest announce capability is emulated by qemu, so don't forward to
|
|
|
|
* the device.
|
|
|
|
*/
|
|
|
|
dev_written = sizeof(status);
|
|
|
|
*s->status = VIRTIO_NET_OK;
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
} else if (unlikely(ctrl->class == VIRTIO_NET_CTRL_MAC &&
|
|
|
|
ctrl->cmd == VIRTIO_NET_CTRL_MAC_TABLE_SET &&
|
|
|
|
iov_size(elem->out_sg, elem->out_num) > out.iov_len)) {
|
|
|
|
/*
|
|
|
|
* Due to the size limitation of the out buffer sent to the vdpa device,
|
|
|
|
* which is determined by vhost_vdpa_net_cvq_cmd_page_len(), excessive
|
|
|
|
* MAC addresses set by the driver for the filter table can cause
|
|
|
|
* truncation of the CVQ command in QEMU. As a result, the vdpa device
|
|
|
|
* rejects the flawed CVQ command.
|
|
|
|
*
|
|
|
|
* Therefore, QEMU must handle this situation instead of sending
|
2023-07-14 13:33:49 +02:00
|
|
|
* the CVQ command directly.
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
*/
|
|
|
|
dev_written = vhost_vdpa_net_excessive_mac_filter_cvq_add(s, elem,
|
2023-10-13 10:09:37 +02:00
|
|
|
&out, &vdpa_in);
|
vdpa: Avoid forwarding large CVQ command failures
Due to the size limitation of the out buffer sent to the vdpa device,
which is determined by vhost_vdpa_net_cvq_cmd_len(), excessive CVQ
command is truncated in QEMU. As a result, the vdpa device rejects
this flawd CVQ command.
However, the problem is that, the VIRTIO_NET_CTRL_MAC_TABLE_SET
CVQ command has a variable length, which may exceed
vhost_vdpa_net_cvq_cmd_len() if the guest sets more than
`MAC_TABLE_ENTRIES` MAC addresses for the filter table.
This patch solves this problem by following steps:
* Increase the out buffer size to vhost_vdpa_net_cvq_cmd_page_len(),
which represents the size of the buffer that is allocated and mmaped.
This ensures that everything works correctly as long as the guest
sets fewer than `(vhost_vdpa_net_cvq_cmd_page_len() -
sizeof(struct virtio_net_ctrl_hdr)
- 2 * sizeof(struct virtio_net_ctrl_mac)) / ETH_ALEN` MAC addresses.
Considering the highly unlikely scenario for the guest setting
more than that number of MAC addresses for the filter table, this
should work fine for the majority of cases.
* If the CVQ command exceeds vhost_vdpa_net_cvq_cmd_page_len(),
instead of directly sending this CVQ command, QEMU should send
a VIRTIO_NET_CTRL_RX_PROMISC CVQ command to vdpa device. Addtionally,
a fake VIRTIO_NET_CTRL_MAC_TABLE_SET command including
(`MAC_TABLE_ENTRIES` + 1) non-multicast MAC addresses and
(`MAC_TABLE_ENTRIES` + 1) multicast MAC addresses should be provided
to the device model.
By doing so, the vdpa device turns promiscuous mode on, aligning
with the VirtIO standard. The device model marks
`n->mac_table.uni_overflow` and `n->mac_table.multi_overflow`,
which aligns with the state of the vdpa device.
Note that the bug cannot be triggered at the moment, since
VIRTIO_NET_F_CTRL_RX feature is not enabled for SVQ.
Fixes: 7a7f87e94c ("vdpa: Move command buffers map to start of net device")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <267e15e4eed2d7aeb9887f193da99a13d22a2f1d.1688743107.git.yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-07 17:27:33 +02:00
|
|
|
if (unlikely(dev_written < 0)) {
|
|
|
|
goto out;
|
|
|
|
}
|
2022-12-21 12:50:14 +01:00
|
|
|
} else {
|
2023-10-13 10:09:39 +02:00
|
|
|
ssize_t r;
|
|
|
|
r = vhost_vdpa_net_cvq_add(s, &out, 1, &vdpa_in, 1);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
dev_written = r;
|
2022-12-21 12:50:14 +01:00
|
|
|
goto out;
|
|
|
|
}
|
2023-10-13 10:09:39 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We can poll here since we've had BQL from the time
|
|
|
|
* we sent the descriptor.
|
|
|
|
*/
|
|
|
|
dev_written = vhost_vdpa_net_svq_poll(s, 1);
|
2022-07-20 08:59:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (unlikely(dev_written < sizeof(status))) {
|
|
|
|
error_report("Insufficient written data (%zu)", dev_written);
|
2022-07-20 08:59:43 +02:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2022-09-06 17:07:14 +02:00
|
|
|
if (*s->status != VIRTIO_NET_OK) {
|
2023-06-02 19:34:51 +02:00
|
|
|
goto out;
|
2022-07-20 08:59:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
status = VIRTIO_NET_ERR;
|
2023-10-13 10:09:36 +02:00
|
|
|
virtio_net_handle_ctrl_iov(svq->vdev, &model_in, 1, &out, 1);
|
2022-07-20 08:59:43 +02:00
|
|
|
if (status != VIRTIO_NET_OK) {
|
|
|
|
error_report("Bad CVQ processing in model");
|
2022-07-20 08:59:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
in_len = iov_from_buf(elem->in_sg, elem->in_num, 0, &status,
|
|
|
|
sizeof(status));
|
|
|
|
if (unlikely(in_len < sizeof(status))) {
|
|
|
|
error_report("Bad device CVQ written length");
|
|
|
|
}
|
|
|
|
vhost_svq_push_elem(svq, elem, MIN(in_len, sizeof(status)));
|
2023-07-07 18:44:42 +02:00
|
|
|
/*
|
|
|
|
* `elem` belongs to vhost_vdpa_net_handle_ctrl_avail() only when
|
|
|
|
* the function successfully forwards the CVQ command, indicated
|
|
|
|
* by a non-negative value of `dev_written`. Otherwise, it still
|
|
|
|
* belongs to SVQ.
|
|
|
|
* This function should only free the `elem` when it owns.
|
|
|
|
*/
|
|
|
|
if (dev_written >= 0) {
|
|
|
|
g_free(elem);
|
|
|
|
}
|
2022-08-23 20:30:34 +02:00
|
|
|
return dev_written < 0 ? dev_written : 0;
|
2022-07-20 08:59:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static const VhostShadowVirtqueueOps vhost_vdpa_net_svq_ops = {
|
|
|
|
.avail_handler = vhost_vdpa_net_handle_ctrl_avail,
|
|
|
|
};
|
|
|
|
|
2023-05-26 17:31:43 +02:00
|
|
|
/**
|
|
|
|
* Probe if CVQ is isolated
|
|
|
|
*
|
|
|
|
* @device_fd The vdpa device fd
|
|
|
|
* @features Features offered by the device.
|
|
|
|
* @cvq_index The control vq pair index
|
|
|
|
*
|
|
|
|
* Returns <0 in case of failure, 0 if false and 1 if true.
|
|
|
|
*/
|
|
|
|
static int vhost_vdpa_probe_cvq_isolation(int device_fd, uint64_t features,
|
|
|
|
int cvq_index, Error **errp)
|
|
|
|
{
|
|
|
|
uint64_t backend_features;
|
|
|
|
int64_t cvq_group;
|
|
|
|
uint8_t status = VIRTIO_CONFIG_S_ACKNOWLEDGE |
|
2023-09-15 19:08:36 +02:00
|
|
|
VIRTIO_CONFIG_S_DRIVER;
|
2023-05-26 17:31:43 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
ERRP_GUARD();
|
|
|
|
|
|
|
|
r = ioctl(device_fd, VHOST_GET_BACKEND_FEATURES, &backend_features);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
error_setg_errno(errp, errno, "Cannot get vdpa backend_features");
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(backend_features & BIT_ULL(VHOST_BACKEND_F_IOTLB_ASID))) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-09-15 19:08:36 +02:00
|
|
|
r = ioctl(device_fd, VHOST_VDPA_SET_STATUS, &status);
|
|
|
|
if (unlikely(r)) {
|
|
|
|
error_setg_errno(errp, -r, "Cannot set device status");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2023-05-26 17:31:43 +02:00
|
|
|
r = ioctl(device_fd, VHOST_SET_FEATURES, &features);
|
|
|
|
if (unlikely(r)) {
|
2023-09-15 19:08:36 +02:00
|
|
|
error_setg_errno(errp, -r, "Cannot set features");
|
2023-09-15 19:08:35 +02:00
|
|
|
goto out;
|
2023-05-26 17:31:43 +02:00
|
|
|
}
|
|
|
|
|
2023-09-15 19:08:36 +02:00
|
|
|
status |= VIRTIO_CONFIG_S_FEATURES_OK;
|
2023-05-26 17:31:43 +02:00
|
|
|
r = ioctl(device_fd, VHOST_VDPA_SET_STATUS, &status);
|
|
|
|
if (unlikely(r)) {
|
2023-09-15 19:08:36 +02:00
|
|
|
error_setg_errno(errp, -r, "Cannot set device status");
|
2023-05-26 17:31:43 +02:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
cvq_group = vhost_vdpa_get_vring_group(device_fd, cvq_index, errp);
|
|
|
|
if (unlikely(cvq_group < 0)) {
|
|
|
|
if (cvq_group != -ENOTSUP) {
|
|
|
|
r = cvq_group;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The kernel report VHOST_BACKEND_F_IOTLB_ASID if the vdpa frontend
|
|
|
|
* support ASID even if the parent driver does not. The CVQ cannot be
|
|
|
|
* isolated in this case.
|
|
|
|
*/
|
|
|
|
error_free(*errp);
|
|
|
|
*errp = NULL;
|
|
|
|
r = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = 0; i < cvq_index; ++i) {
|
|
|
|
int64_t group = vhost_vdpa_get_vring_group(device_fd, i, errp);
|
|
|
|
if (unlikely(group < 0)) {
|
|
|
|
r = group;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (group == (int64_t)cvq_group) {
|
|
|
|
r = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
r = 1;
|
|
|
|
|
|
|
|
out:
|
|
|
|
status = 0;
|
|
|
|
ioctl(device_fd, VHOST_VDPA_SET_STATUS, &status);
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2021-10-20 06:55:54 +02:00
|
|
|
static NetClientState *net_vhost_vdpa_init(NetClientState *peer,
|
2022-12-15 12:31:38 +01:00
|
|
|
const char *device,
|
|
|
|
const char *name,
|
|
|
|
int vdpa_device_fd,
|
|
|
|
int queue_pair_index,
|
|
|
|
int nvqs,
|
|
|
|
bool is_datapath,
|
|
|
|
bool svq,
|
2023-03-03 18:24:42 +01:00
|
|
|
struct vhost_vdpa_iova_range iova_range,
|
2023-05-26 17:31:43 +02:00
|
|
|
uint64_t features,
|
2023-12-21 18:43:10 +01:00
|
|
|
VhostVDPAShared *shared,
|
2023-05-26 17:31:43 +02:00
|
|
|
Error **errp)
|
2020-07-01 16:55:38 +02:00
|
|
|
{
|
|
|
|
NetClientState *nc = NULL;
|
|
|
|
VhostVDPAState *s;
|
|
|
|
int ret = 0;
|
|
|
|
assert(name);
|
2023-09-11 23:54:35 +02:00
|
|
|
int cvq_isolated = 0;
|
2023-05-26 17:31:43 +02:00
|
|
|
|
2021-10-20 06:56:00 +02:00
|
|
|
if (is_datapath) {
|
|
|
|
nc = qemu_new_net_client(&net_vhost_vdpa_info, peer, device,
|
|
|
|
name);
|
|
|
|
} else {
|
2023-05-26 17:31:43 +02:00
|
|
|
cvq_isolated = vhost_vdpa_probe_cvq_isolation(vdpa_device_fd, features,
|
|
|
|
queue_pair_index * 2,
|
|
|
|
errp);
|
|
|
|
if (unlikely(cvq_isolated < 0)) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2022-08-23 20:30:32 +02:00
|
|
|
nc = qemu_new_net_control_client(&net_vhost_vdpa_cvq_info, peer,
|
2021-10-20 06:56:00 +02:00
|
|
|
device, name);
|
|
|
|
}
|
2022-10-21 11:09:10 +02:00
|
|
|
qemu_set_info_str(nc, TYPE_VHOST_VDPA);
|
2020-07-01 16:55:38 +02:00
|
|
|
s = DO_UPCAST(VhostVDPAState, nc, nc);
|
2021-10-20 06:55:51 +02:00
|
|
|
|
2021-10-20 06:56:00 +02:00
|
|
|
s->vhost_vdpa.index = queue_pair_index;
|
2022-12-15 12:31:42 +01:00
|
|
|
s->always_svq = svq;
|
2023-06-07 16:42:34 +02:00
|
|
|
s->migration_state.notify = NULL;
|
2022-07-20 08:59:46 +02:00
|
|
|
s->vhost_vdpa.shadow_vqs_enabled = svq;
|
2023-03-03 18:24:42 +01:00
|
|
|
if (queue_pair_index == 0) {
|
|
|
|
vhost_vdpa_net_valid_svq_features(features,
|
|
|
|
&s->vhost_vdpa.migration_blocker);
|
2023-12-21 18:43:10 +01:00
|
|
|
s->vhost_vdpa.shared = g_new0(VhostVDPAShared, 1);
|
2023-12-21 18:43:15 +01:00
|
|
|
s->vhost_vdpa.shared->device_fd = vdpa_device_fd;
|
2023-12-21 18:43:12 +01:00
|
|
|
s->vhost_vdpa.shared->iova_range = iova_range;
|
2023-12-21 18:43:13 +01:00
|
|
|
s->vhost_vdpa.shared->shadow_data = svq;
|
2023-03-03 18:24:42 +01:00
|
|
|
} else if (!is_datapath) {
|
2023-06-02 16:38:54 +02:00
|
|
|
s->cvq_cmd_out_buffer = mmap(NULL, vhost_vdpa_net_cvq_cmd_page_len(),
|
|
|
|
PROT_READ | PROT_WRITE,
|
|
|
|
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
|
|
|
|
s->status = mmap(NULL, vhost_vdpa_net_cvq_cmd_page_len(),
|
|
|
|
PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS,
|
|
|
|
-1, 0);
|
2022-07-20 08:59:43 +02:00
|
|
|
|
2022-07-20 08:59:42 +02:00
|
|
|
s->vhost_vdpa.shadow_vq_ops = &vhost_vdpa_net_svq_ops;
|
|
|
|
s->vhost_vdpa.shadow_vq_ops_opaque = s;
|
2023-05-26 17:31:43 +02:00
|
|
|
s->cvq_isolated = cvq_isolated;
|
2022-07-20 08:59:42 +02:00
|
|
|
}
|
2023-12-21 18:43:10 +01:00
|
|
|
if (queue_pair_index != 0) {
|
|
|
|
s->vhost_vdpa.shared = shared;
|
|
|
|
}
|
|
|
|
|
2021-10-20 06:56:00 +02:00
|
|
|
ret = vhost_vdpa_add(nc, (void *)&s->vhost_vdpa, queue_pair_index, nvqs);
|
2021-09-03 11:10:20 +02:00
|
|
|
if (ret) {
|
|
|
|
qemu_del_net_client(nc);
|
2021-10-20 06:55:54 +02:00
|
|
|
return NULL;
|
2021-09-03 11:10:20 +02:00
|
|
|
}
|
2023-12-21 18:43:10 +01:00
|
|
|
|
2021-10-20 06:55:54 +02:00
|
|
|
return nc;
|
2020-07-01 16:55:38 +02:00
|
|
|
}
|
|
|
|
|
2022-07-20 08:59:44 +02:00
|
|
|
static int vhost_vdpa_get_features(int fd, uint64_t *features, Error **errp)
|
|
|
|
{
|
|
|
|
int ret = ioctl(fd, VHOST_GET_FEATURES, features);
|
|
|
|
if (unlikely(ret < 0)) {
|
|
|
|
error_setg_errno(errp, errno,
|
|
|
|
"Fail to query features from vhost-vDPA device");
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vhost_vdpa_get_max_queue_pairs(int fd, uint64_t features,
|
|
|
|
int *has_cvq, Error **errp)
|
2021-10-20 06:56:00 +02:00
|
|
|
{
|
|
|
|
unsigned long config_size = offsetof(struct vhost_vdpa_config, buf);
|
2021-11-02 16:51:57 +01:00
|
|
|
g_autofree struct vhost_vdpa_config *config = NULL;
|
2021-10-20 06:56:00 +02:00
|
|
|
__virtio16 *max_queue_pairs;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (features & (1 << VIRTIO_NET_F_CTRL_VQ)) {
|
|
|
|
*has_cvq = 1;
|
|
|
|
} else {
|
|
|
|
*has_cvq = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (features & (1 << VIRTIO_NET_F_MQ)) {
|
|
|
|
config = g_malloc0(config_size + sizeof(*max_queue_pairs));
|
|
|
|
config->off = offsetof(struct virtio_net_config, max_virtqueue_pairs);
|
|
|
|
config->len = sizeof(*max_queue_pairs);
|
|
|
|
|
|
|
|
ret = ioctl(fd, VHOST_VDPA_GET_CONFIG, config);
|
|
|
|
if (ret) {
|
|
|
|
error_setg(errp, "Fail to get config from vhost-vDPA device");
|
|
|
|
return -ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
max_queue_pairs = (__virtio16 *)&config->buf;
|
|
|
|
|
|
|
|
return lduw_le_p(max_queue_pairs);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-07-01 16:55:38 +02:00
|
|
|
int net_init_vhost_vdpa(const Netdev *netdev, const char *name,
|
|
|
|
NetClientState *peer, Error **errp)
|
|
|
|
{
|
|
|
|
const NetdevVhostVDPAOptions *opts;
|
2022-07-20 08:59:44 +02:00
|
|
|
uint64_t features;
|
2021-10-20 06:55:54 +02:00
|
|
|
int vdpa_device_fd;
|
2022-02-14 20:34:15 +01:00
|
|
|
g_autofree NetClientState **ncs = NULL;
|
2022-12-15 12:31:38 +01:00
|
|
|
struct vhost_vdpa_iova_range iova_range;
|
2022-02-14 20:34:15 +01:00
|
|
|
NetClientState *nc;
|
2022-08-02 13:24:46 +02:00
|
|
|
int queue_pairs, r, i = 0, has_cvq = 0;
|
2020-07-01 16:55:38 +02:00
|
|
|
|
|
|
|
assert(netdev->type == NET_CLIENT_DRIVER_VHOST_VDPA);
|
|
|
|
opts = &netdev->u.vhost_vdpa;
|
2022-11-04 17:07:00 +01:00
|
|
|
if (!opts->vhostdev && !opts->vhostfd) {
|
2022-10-08 09:58:58 +02:00
|
|
|
error_setg(errp,
|
|
|
|
"vhost-vdpa: neither vhostdev= nor vhostfd= was specified");
|
2021-11-12 20:34:31 +01:00
|
|
|
return -1;
|
|
|
|
}
|
2021-10-20 06:55:51 +02:00
|
|
|
|
2022-11-04 17:07:00 +01:00
|
|
|
if (opts->vhostdev && opts->vhostfd) {
|
2022-10-08 09:58:58 +02:00
|
|
|
error_setg(errp,
|
|
|
|
"vhost-vdpa: vhostdev= and vhostfd= are mutually exclusive");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2022-11-04 17:07:00 +01:00
|
|
|
if (opts->vhostdev) {
|
2022-10-08 09:58:58 +02:00
|
|
|
vdpa_device_fd = qemu_open(opts->vhostdev, O_RDWR, errp);
|
|
|
|
if (vdpa_device_fd == -1) {
|
|
|
|
return -errno;
|
|
|
|
}
|
2022-10-31 14:29:01 +01:00
|
|
|
} else {
|
|
|
|
/* has_vhostfd */
|
2022-10-08 09:58:58 +02:00
|
|
|
vdpa_device_fd = monitor_fd_param(monitor_cur(), opts->vhostfd, errp);
|
|
|
|
if (vdpa_device_fd == -1) {
|
|
|
|
error_prepend(errp, "vhost-vdpa: unable to parse vhostfd: ");
|
|
|
|
return -1;
|
|
|
|
}
|
2021-10-20 06:55:51 +02:00
|
|
|
}
|
|
|
|
|
2022-07-20 08:59:44 +02:00
|
|
|
r = vhost_vdpa_get_features(vdpa_device_fd, &features, errp);
|
|
|
|
if (unlikely(r < 0)) {
|
2022-08-02 13:24:46 +02:00
|
|
|
goto err;
|
2022-07-20 08:59:44 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
queue_pairs = vhost_vdpa_get_max_queue_pairs(vdpa_device_fd, features,
|
2021-10-20 06:56:00 +02:00
|
|
|
&has_cvq, errp);
|
|
|
|
if (queue_pairs < 0) {
|
2021-10-20 06:55:51 +02:00
|
|
|
qemu_close(vdpa_device_fd);
|
2021-10-20 06:56:00 +02:00
|
|
|
return queue_pairs;
|
|
|
|
}
|
|
|
|
|
2022-12-24 12:48:48 +01:00
|
|
|
r = vhost_vdpa_get_iova_range(vdpa_device_fd, &iova_range);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
error_setg(errp, "vhost-vdpa: get iova range failed: %s",
|
|
|
|
strerror(-r));
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2023-03-03 18:24:32 +01:00
|
|
|
if (opts->x_svq && !vhost_vdpa_net_valid_svq_features(features, errp)) {
|
|
|
|
goto err;
|
2022-07-20 08:59:46 +02:00
|
|
|
}
|
|
|
|
|
2021-10-20 06:56:00 +02:00
|
|
|
ncs = g_malloc0(sizeof(*ncs) * queue_pairs);
|
|
|
|
|
|
|
|
for (i = 0; i < queue_pairs; i++) {
|
2023-12-21 18:43:10 +01:00
|
|
|
VhostVDPAShared *shared = NULL;
|
|
|
|
|
|
|
|
if (i) {
|
|
|
|
shared = DO_UPCAST(VhostVDPAState, nc, ncs[0])->vhost_vdpa.shared;
|
|
|
|
}
|
2021-10-20 06:56:00 +02:00
|
|
|
ncs[i] = net_vhost_vdpa_init(peer, TYPE_VHOST_VDPA, name,
|
2022-07-20 08:59:46 +02:00
|
|
|
vdpa_device_fd, i, 2, true, opts->x_svq,
|
2023-12-21 18:43:10 +01:00
|
|
|
iova_range, features, shared, errp);
|
2021-10-20 06:56:00 +02:00
|
|
|
if (!ncs[i])
|
|
|
|
goto err;
|
2021-10-20 06:55:51 +02:00
|
|
|
}
|
|
|
|
|
2021-10-20 06:56:00 +02:00
|
|
|
if (has_cvq) {
|
2023-12-21 18:43:10 +01:00
|
|
|
VhostVDPAState *s0 = DO_UPCAST(VhostVDPAState, nc, ncs[0]);
|
|
|
|
VhostVDPAShared *shared = s0->vhost_vdpa.shared;
|
|
|
|
|
2021-10-20 06:56:00 +02:00
|
|
|
nc = net_vhost_vdpa_init(peer, TYPE_VHOST_VDPA, name,
|
2022-07-20 08:59:46 +02:00
|
|
|
vdpa_device_fd, i, 1, false,
|
2023-12-21 18:43:10 +01:00
|
|
|
opts->x_svq, iova_range, features, shared,
|
|
|
|
errp);
|
2021-10-20 06:56:00 +02:00
|
|
|
if (!nc)
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2021-10-20 06:55:54 +02:00
|
|
|
return 0;
|
2021-10-20 06:56:00 +02:00
|
|
|
|
|
|
|
err:
|
|
|
|
if (i) {
|
2022-05-07 04:28:14 +02:00
|
|
|
for (i--; i >= 0; i--) {
|
|
|
|
qemu_del_net_client(ncs[i]);
|
|
|
|
}
|
2021-10-20 06:56:00 +02:00
|
|
|
}
|
2022-07-20 08:59:46 +02:00
|
|
|
|
2021-10-20 06:56:00 +02:00
|
|
|
qemu_close(vdpa_device_fd);
|
|
|
|
|
|
|
|
return -1;
|
2020-07-01 16:55:38 +02:00
|
|
|
}
|