backend_defaults property allow users to control if default block
properties should be decided with backend information.
If it is off, any backend information will be discarded, which is
suitable if you plan to perform live migration to a different disk backend.
If it is on, a block device may utilize backend information more
aggressively.
By default, it is auto, which uses backend information for block
sizes and ignores the others, which is consistent with the older
versions.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-id: 20210705130458.97642-2-akihiko.odaki@gmail.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Make -smp syntactic sugar for a compound property "-machine
smp.{cores,threads,cpu,...}". machine_smp_parse is replaced by the
setter for the property.
numa-test will now cover the new syntax, while other tests
still use -smp.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
As with previous performance optimization on Treaddir handling;
reduce the overall latency, i.e. overall time spent on processing
a Twalk request by reducing the amount of thread hops between the
9p server's main thread and fs worker thread(s).
In fact this patch even reduces the thread hops for Twalk handling
to its theoritical minimum of exactly 2 thread hops:
main thread -> fs worker thread -> main thread
This is achieved by doing all the required fs driver tasks altogether
in a single v9fs_co_run_in_worker({ ... }); code block.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <1a6701674afc4f08d40396e3aa2631e18a4dbb33.1622821729.git.qemu_oss@crudebyte.com>
As we are actually only comparing the filesystem ID (i.e. device number
and inode number pair) let's use the POSIX stat buffer instead of QIDs,
because resolving QIDs requires to be done on 9p server's main thread
only as it might mutate the server state if inode remapping is enabled.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <26aa465ff9cc9c07e053331554a02fdae3994417.1622821729.git.qemu_oss@crudebyte.com>
We already capture the QID of the exported 9p root path, i.e. to
prevent client access outside the defined, exported filesystem's tree.
This is currently checked by comparing the root QID with another FID's
QID.
The problem with the latter is that resolving a QID of any given 9p path
can only be done on 9p server's main thread, that's because it might
mutate the server's state if inode remapping is enabled.
For that reason also capture the POSIX stat info of the root path for
being able to identify on any (e.g. worker) thread whether an
arbitrary given path is identical to the export root.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <eb07d6c2e9925788454cfe33d3802e4ffb23ea9a.1622821729.git.qemu_oss@crudebyte.com>
There is only one user of not_same_qid() which is v9fs_walk() and the
latter is using it for comparing a client supplied path with the 9p
export root path, for the sole purpose to prevent a Twalk request
from escaping from the exported 9p tree via "..".
However for that specific purpose the implementation of not_same_qid()
is wrong; if mtime of the 9p export root path changed between Tattach
and Twalk then not_same_qid() returns true when actually comparing
against the export root path.
To fix for the actual semantic being used, only compare QID path
members, but do not compare version or type members.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <ca0abae4a899d81c6e87f683732d6c1f56915232.1622821729.git.qemu_oss@crudebyte.com>
PVRDMA queue
Several CVE fixes for the PVRDMA device.
# gpg: Signature made Sun 04 Jul 2021 20:56:05 BST
# gpg: using RSA key 36D4C0F0CF2FE46D
# gpg: Good signature from "Marcel Apfelbaum <marcel.apfelbaum@zoho.com>" [marginal]
# gpg: aka "Marcel Apfelbaum <marcel@redhat.com>" [marginal]
# gpg: aka "Marcel Apfelbaum <marcel.apfelbaum@gmail.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: B1C6 3A57 F92E 08F2 640F 31F5 36D4 C0F0 CF2F E46D
* remotes/marcel/tags/pvrdma-04-07-2021-v2:
pvrdma: Fix the ring init error flow (CVE-2021-3608)
pvrdma: Ensure correct input on ring init (CVE-2021-3607)
hw/rdma: Fix possible mremap overflow in the pvrdma device (CVE-2021-3582)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
MIPS patches queue
- Extract nanoMIPS, microMIPS, Code Compaction from translate.c
- Allow PCI config accesses smaller than 32-bit on Bonito64 device
- Fix migration of g364fb device on Jazz Magnum
- Fix dp8393x PROM checksum on Jazz Magnum and Quadra 800
- Map the UART devices unconditionally on Jazz Magnum
- Add functional test booting Linux on the Fuloong 2E
# gpg: Signature made Fri 02 Jul 2021 16:36:19 BST
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full]
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* remotes/philmd/tags/mips-20210702:
hw/mips/jazz: Map the UART devices unconditionally
hw/mips/jazz: specify correct endian for dp8393x device
hw/m68k/q800: fix PROM checksum and MAC address storage
qemu/bitops.h: add bitrev8 implementation
dp8393x: remove onboard PROM containing MAC address and checksum
hw/m68k/q800: move PROM and checksum calculation from dp8393x device to board
hw/mips/jazz: move PROM and checksum calculation from dp8393x device to board
dp8393x: convert to trace-events
dp8393x: checkpatch fixes
g364fb: add VMStateDescription for G364SysBusState
g364fb: use RAM memory region for framebuffer
tests/acceptance: Test Linux on the Fuloong 2E machine
hw/pci-host/bonito: Allow PCI config accesses smaller than 32-bit
hw/pci-host/bonito: Trace PCI config accesses smaller than 32-bit
target/mips: Extract nanoMIPS ISA translation routines
target/mips: Extract the microMIPS ISA translation routines
target/mips: Extract Code Compaction ASE translation routines
target/mips: Add declarations for generic TCG helpers
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit [1] moved _SUN variable from only hot-pluggable to
all devices. This made linux kernel enumerate extra slots
that weren't present before. If extra slot happens to be
be enumerated first and there is a device in th same slot
but on other bridge, linux kernel will add -N suffix to
slot name of the later, thus changing NIC name compared to
QEMU 5.2. This in some case confuses systemd, if it is
using SLOT NIC naming scheme and interface name becomes
not the same as it was under QEMU-5.2.
Reproducer QEMU CLI:
-M pc-i440fx-5.2 -nodefaults \
-device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x3 \
-device virtio-net-pci,id=nic1,bus=pci.1,addr=0x1 \
-device virtio-net-pci,id=nic2,bus=pci.1,addr=0x2 \
-device virtio-net-pci,id=nic3,bus=pci.1,addr=0x3
with RHEL8 guest produces following results:
v5.2:
kernel: virtio_net virtio0 ens1: renamed from eth0
kernel: virtio_net virtio2 ens3: renamed from eth2
kernel: virtio_net virtio1 enp1s2: renamed from eth1
(slot 2 is assigned to empty bus 0 slot and virtio1
is assigned to 2-2 slot, and renaming falls back,
for some reason, to path based naming scheme)
v6.0:
kernel: virtio_net virtio0 ens1: renamed from eth0
kernel: virtio_net virtio2 ens3: renamed from eth2
systemd-udevd[299]: Error changing net interface name 'eth1' to 'ens3': File exists
systemd-udevd[299]: could not rename interface '3' from 'eth1' to 'ens3': File exists
(with commit [1] kernel assigns virtio2 to 3-2 slot
since bridge advertises _SUN=0x3 and kernel assigns
slot 3 to bridge. Still it manages to rename virtio2
correctly to ens3, however systemd gets confused with virtio1
where slot allocation exactly the same (2-2) as in 5.2 case
and tries to rename it to ens3 which is rightfully taken by
virtio2)
I'm not sure what breaks in systemd interface renaming (it probably
should be investigated), but on QEMU side we can safely revert
_SUN to 5.2 behavior (i.e. avoid cold-plugged bridges and non
hot-pluggable device classes), without breaking acpi-index, which uses
slot numbers but it doesn't have to use _SUN, it could use an arbitrary
variable name that has the same slot value).
It will help existing VMs to keep networking with non trivial
configs in working order since systemd will do its interface
renaming magic as it used to do.
1)
Fixes: b7f23f62e4 (pci: acpi: add _DSM method to PCI devices)
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20210624204229.998824-3-imammedo@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: John Sucaet <john.sucaet@ekinops.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Now, if virtio device is not present on virtio-bus - pci config callbacks
will not lead to possible crush. The read will return "-1" which should be
interpreted by a driver that pci device may be unplugged.
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Message-Id: <20210609095843.141378-3-andrew@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
During unplug the virtio device is unplugged from virtio-bus on pci. In some cases,
requests to virtio-pci mm may acquire during/after unplug. Added check that virtio
device is on the bus, for "common" memory region.
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Message-Id: <20210609095843.141378-2-andrew@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
libFuzzer triggered the following assertion:
cat << EOF | qemu-system-i386 -M pc-q35-5.0 \
-nographic -monitor none -serial none \
-qtest stdio -d guest_errors -trace pci\*
outl 0xcf8 0xf2000060
outl 0xcfc 0x8400056e
EOF
pci_cfg_write mch 00:0 @0x60 <- 0x8400056e
Aborted (core dumped)
This is because guest wrote MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD
(reserved value) to the PCIE XBAR register.
There is no indication on the datasheet about what occurs when
this value is written. Simply ignore it on QEMU (and report an
guest error):
pci_cfg_write mch 00:0 @0x60 <- 0x8400056e
Q35: Reserved PCIEXBAR LENGTH
pci_cfg_read mch 00:0 @0x0 -> 0x8086
pci_cfg_read mch 00:0 @0x0 -> 0x29c08086
...
Cc: qemu-stable@nongnu.org
Reported-by: Alexander Bulekov <alxndr@bu.edu>
BugLink: https://bugs.launchpad.net/qemu/+bug/1878641
Fixes: df2d8b3ed4 ("q35: Introduce q35 pc based chipset emulator")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210526142438.281477-1-f4bug@amsat.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When using the Magnum ARC firmware we can see accesses to the
UART1 being rejected, because the device is not mapped:
$ qemu-system-mips64el -M magnum -d guest_errors,unimp -bios NTPROM.RAW
Invalid access at addr 0x80007004, size 1, region '(null)', reason: rejected
Invalid access at addr 0x80007001, size 1, region '(null)', reason: rejected
Invalid access at addr 0x80007002, size 1, region '(null)', reason: rejected
Invalid access at addr 0x80007003, size 1, region '(null)', reason: rejected
Invalid access at addr 0x80007004, size 1, region '(null)', reason: rejected
Since both UARTs are present (soldered on the board) regardless
of whether there are character devices connected, map them
unconditionally.
(This code pre-dated commit 12051d82f0 which made it safe to pass
NULL in as a chardev to serial devices.)
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210629053704.2584504-1-f4bug@amsat.org>
The checksum used by MacOS to validate the PROM content is an exclusive-OR
rather than a sum over the corresponding bytes. In addition the MAC address
must be stored in bit-reversed format as indicated in comments in Linux's
macsonic.c.
With the PROM contents fixed MacOS starts to probe the device registers
when AppleTalk is enabled in the Control Panel.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Tested-by: Finn Thain <fthain@linux-m68k.org>
Message-Id: <20210625065401.30170-8-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
According to the datasheet the dp8393x chipset does not contain any NVRAM capable
of storing a MAC address or checksum. Now that both the MIPS jazz and m68k q800
boards generate the PROM region and checksum themselves, remove the generated
PROM from the dp8393x device itself.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Tested-by: Finn Thain <fthain@linux-m68k.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210625065401.30170-6-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Currently when QEMU attempts to migrate the MIPS magnum machine it crashes due
to a mistake in the g364fb VMStateDescription configuration which expects a
G364SysBusState and not a G364State.
Resolve the issue by adding a new VMStateDescription for G364SysBusState and
embedding the existing vmstate_g364fb VMStateDescription inside it using
VMSTATE_STRUCT.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Fixes: 97a3f6ffbb ("g364fb: convert to qdev")
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210625163554.14879-3-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Since the migration stream is already broken, we can use this opportunity to
change the framebuffer so that it is migrated as a RAM memory region rather
than as an array of bytes.
In particular this helps the output of the analyze-migration.py tool which
no longer contains a huge array representing the framebuffer contents.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210625163554.14879-2-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
When running the official PMON firmware for the Fuloong 2E, we see
8-bit and 16-bit accesses to PCI config space:
$ qemu-system-mips64el -M fuloong2e -bios pmon_2e.bin \
-trace -trace bonito\* -trace pci_cfg\*
pci_cfg_write vt82c686b-pm 05:4 @0x90 <- 0xeee1
bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x4d2, size: 2
pci_cfg_write vt82c686b-pm 05:4 @0xd2 <- 0x1
pci_cfg_write vt82c686b-pm 05:4 @0x4 <- 0x1
pci_cfg_write vt82c686b-isa 05:0 @0x4 <- 0x7
bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x81, size: 1
pci_cfg_read vt82c686b-isa 05:0 @0x81 -> 0x0
bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x81, size: 1
pci_cfg_write vt82c686b-isa 05:0 @0x81 <- 0x80
bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x83, size: 1
pci_cfg_write vt82c686b-isa 05:0 @0x83 <- 0x89
bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x85, size: 1
pci_cfg_write vt82c686b-isa 05:0 @0x85 <- 0x3
bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x5a, size: 1
pci_cfg_write vt82c686b-isa 05:0 @0x5a <- 0x7
bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x85, size: 1
pci_cfg_write vt82c686b-isa 05:0 @0x85 <- 0x1
Also this is what the Linux kernel does since it supports the Bonito
north bridge:
https://elixir.bootlin.com/linux/v2.6.15/source/arch/mips/pci/ops-bonito64.c#L85
So it seems safe to assume the datasheet is incomplete or outdated
regarding the address constraints.
This problem was exposed by commit 911629e6d3
("vt82c686: Fix SMBus IO base and configuration registers").
Reported-by: BALATON Zoltan <balaton@eik.bme.hu>
Suggested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210624202747.1433023-4-f4bug@amsat.org>
Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
The device model batching its ioeventfds in a single MR transaction is
an optimization. Clarify this in virtio-scsi, virtio-blk and generic
virtio code. Also clarify that the transaction must commit before
closing ioeventfds so that no one is tempted to merge the loops
in the start functions error path and in the stop functions.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <162125799728.1394228.339855768563326832.stgit@bahia.lan>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio devices support separate iothreads waiting for
events from file descriptors. These are asynchronous
events that can't be recorded and replayed, therefore
this patch disables ioeventfd for all devices when
record or replay is enabled.
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
Message-Id: <162125678869.1252810.4317416444097392406.stgit@pasha-ThinkPad-X280>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This is just enough to make reboot and poweroff work. Works for
linux, u-boot, and the arm trusted firmware. Not tested, but should
work for plan9, and bare-metal/hobby OSes, since they seem to generally
do what linux does for reset.
The watchdog timer functionality is not yet implemented.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/64
Signed-off-by: Nolan Leake <nolan@sigbus.net>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210625210209.1870217-1-nolan@sigbus.net
[PMM: tweaked commit title; fixed region size to 0x200;
moved header file to include/]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Per the datasheet section "5.7.5. Accessing PCI configuration space"
the address must be 32-bit aligned. Trace eventual accesses not
aligned to 32-bit.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210624202747.1433023-3-f4bug@amsat.org>
hw/nvme patches
* namespace eui64 support (Heinrich)
* aiocb refactoring (Klaus)
* controller parameter for auto zone transitioning (Niklas)
* misc fixes and additions (Gollu, Klaus, Keith)
# gpg: Signature made Tue 29 Jun 2021 19:46:55 BST
# gpg: using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9
# gpg: Good signature from "Klaus Jensen <its@irrelevant.dk>" [unknown]
# gpg: aka "Klaus Jensen <k.jensen@samsung.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838
# Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9
* remotes/nvme/tags/nvme-next-pull-request: (23 commits)
hw/nvme: add 'zoned.zasl' to documentation
hw/nvme: fix pin-based interrupt behavior (again)
hw/nvme: fix missing check for PMR capability
hw/nvme: documentation fix
hw/nvme: fix endianess conversion and add controller list
Partially revert "hw/block/nvme: drain namespaces on sq deletion"
hw/nvme: reimplement format nvm to allow cancellation
hw/nvme: reimplement zone reset to allow cancellation
hw/nvme: reimplement the copy command to allow aio cancellation
hw/nvme: add dw0/1 to the req completion trace event
hw/nvme: use prinfo directly in nvme_check_prinfo and nvme_dif_check
hw/nvme: remove assert from nvme_get_zone_by_slba
hw/nvme: save reftag when generating pi
hw/nvme: reimplement dsm to allow cancellation
hw/nvme: add nvme_block_status_all helper
hw/nvme: reimplement flush to allow cancellation
hw/nvme: default for namespace EUI-64
hw/nvme: namespace parameter for EUI-64
hw/nvme: fix csi field for cns 0x00 and 0x11
hw/nvme: add param to control auto zone transitioning to zone state closed
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit dabefdd6 removed code that was supposed to try reconnecting
during .realize(), but actually just crashed and had several design
problems.
This adds the feature back without the crash in simple cases while also
fixing some design problems: Reconnection is now only tried if there was
a problem with the connection and not an error related to the content
(which would fail again the same way in the next attempt). Reconnection
is limited to three attempts (four with the initial attempt) so that we
won't end up in an infinite loop if a problem is permanent. If the
backend restarts three times in the very short time window of device
initialisation, we have bigger problems and erroring out is the right
course of action.
In the case that a connection error occurs and we reconnect, the error
message is printed using error_report_err(), but otherwise ignored.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20210609154658.350308-8-kwolf@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This function is the part that we will want to retry if the connection
is lost during initialisation, so factor it out to keep the following
patch simpler.
The error path for vhost_dev_get_config() forgot disconnecting the
chardev, add this while touching the code.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20210609154658.350308-7-kwolf@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Instead of just returning 0/-1 and letting the caller make up a
meaningless error message, add an Error parameter to allow reporting the
real error and switch to 0/-errno so that different kind of errors can
be distinguished in the caller.
config_len in vhost_user_get_config() is defined by the device, so if
it's larger than VHOST_USER_MAX_CONFIG_SIZE, this is a programming
error. Turn the corresponding check into an assertion.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20210609154658.350308-6-kwolf@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
