Re: [PATCH] util: basic support for vendor-specific vfio drivers
On 8/5/22 2:20 PM, Jason Gunthorpe wrote: On Fri, Aug 05, 2022 at 11:24:08AM -0600, Alex Williamson wrote: On Thu, 4 Aug 2022 21:11:07 -0300 Jason Gunthorpe wrote: On Thu, Aug 04, 2022 at 01:36:24PM -0600, Alex Williamson wrote: That is reasonable, but I'd say those three kernels only have two drivers and they both have vfio as a substring in their name - so the simple thing of just substring searching 'vfio' would get us over that gap. Looking at the aliases for exactly "vfio_pci" isn't that much more complicated, and "feels" a lot more reliable than just doing a substring search for "vfio" in the driver's name. (It would be, uh, "not smart" to name a driver "vfio" if it wasn't actually a vfio variant driver (or the opposite), but I could imagine it happening; :-/) This is still pretty hacky. I'm worried about what happens to the kernel if this becames some crazy unintended uAPI that we never really thought about carefully... This was not a use case when we designed the modules.alias stuff at least. BTW - why not do things the normal way? 1. readlink /sys/bus/pci/devices/XX/iommu_group 2. Compute basename of #1 3. Check if /dev/vfio/#2 exists (or /sys/class/vfio/#2) It has a small edge case where a multi-device group might give a false positive for an undrivered device, but for the purposes of libvirt that seems pretty obscure.. (while the above has false negative issues, obviously) This is not a small edge case, it's extremely common. We have a *lot* of users assigning desktop GPUs and other consumer grade hardware, which are usually multi-function devices without isolation exposed via ACS or quirks. The edge case is that the user has created a multi-device group, manually assigned device 1 in the group to VFIO, left device 2 with no driver and then told libvirt to manually use device 2. With the above approach libvirt won't detect this misconfiguration and qemu will fail. libvirt will see that there is no driver at all, and recognize that, by definition, "no driver" == "not a vfio variant driver" :-). So in this case libvirt catches the misconfiguration. The vfio group exists if any devices in the group are bound to a vfio driver, but the device is not accessible from the group unless the viability test passes. That means QEMU may not be able to get access to the device because the device we want isn't actually bound to a vfio driver or another device in the group is not in a viable state. Thanks, This is a different misconfiguration that libvirt also won't detect, right? In this case ownership claiming in the kernel will fail and qemu will fail too, like above. Right. If we're relying on "iommu group matching" as you suggest, then libvirt will mistakenly conclude that the driver is a vfio variant, but then qemu will fail. This, and the above, could be handled by having libvirt also open the group FD and get the device. It would prove both correct binding and viability. I had understood the point of this logic was to give better error reporting to users so that common misconfigurations could be diagnosed earlier. Correct. In the end QEMU and the kernel have the final say of course, but if we can detect the problem sooner then it's more likely the user will get a meaningful error message. When I say 'small edge case' I mean it seems like an unlikely misconfiguration that someone would know to setup VFIO but then use the wrong BDFs to do it - arguably less likely than someone would know to setup VFIO but forget to unbind the other drivers in the group? You obviously haven't spent enough time trying to remotely troubleshoot the setups of noobs on IRC :-). If anything can be done wrong, there is certainly someone around who will do it that way. Of course we can't eliminate 100% of these, but the more misconfigurations we can catch, and the earlier we can catch them, the better. All of this without any false error reports of course. It's better that some edge cases get through (and be shot down by QEMU) rather than that we would mistakenly prevent someone from using a totally viable config (which is the case right now). But maybe I don't get it at all ... Nah, you get it. We just have minor differences of opinion of which choice will be the best combination of simple to implement + less user headaches (and in the end any of us could be right; personally my opinion sways from minute to minute).
Re: [PATCH] util: basic support for vendor-specific vfio drivers
On 8/5/22 2:56 PM, Alex Williamson wrote: On Fri, 5 Aug 2022 15:20:24 -0300 Jason Gunthorpe wrote: On Fri, Aug 05, 2022 at 11:24:08AM -0600, Alex Williamson wrote: On Thu, 4 Aug 2022 21:11:07 -0300 Jason Gunthorpe wrote: On Thu, Aug 04, 2022 at 01:36:24PM -0600, Alex Williamson wrote: That is reasonable, but I'd say those three kernels only have two drivers and they both have vfio as a substring in their name - so the simple thing of just substring searching 'vfio' would get us over that gap. Looking at the aliases for exactly "vfio_pci" isn't that much more complicated, and "feels" a lot more reliable than just doing a substring search for "vfio" in the driver's name. (It would be, uh, "not smart" to name a driver "vfio" if it wasn't actually a vfio variant driver (or the opposite), but I could imagine it happening; :-/) This is still pretty hacky. I'm worried about what happens to the kernel if this becames some crazy unintended uAPI that we never really thought about carefully... This was not a use case when we designed the modules.alias stuff at least. BTW - why not do things the normal way? 1. readlink /sys/bus/pci/devices/XX/iommu_group 2. Compute basename of #1 3. Check if /dev/vfio/#2 exists (or /sys/class/vfio/#2) It has a small edge case where a multi-device group might give a false positive for an undrivered device, but for the purposes of libvirt that seems pretty obscure.. (while the above has false negative issues, obviously) This is not a small edge case, it's extremely common. We have a *lot* of users assigning desktop GPUs and other consumer grade hardware, which are usually multi-function devices without isolation exposed via ACS or quirks. The edge case is that the user has created a multi-device group, manually assigned device 1 in the group to VFIO, left device 2 with no driver and then told libvirt to manually use device 2. With the above approach libvirt won't detect this misconfiguration and qemu will fail. The vfio group exists if any devices in the group are bound to a vfio driver, but the device is not accessible from the group unless the viability test passes. That means QEMU may not be able to get access to the device because the device we want isn't actually bound to a vfio driver or another device in the group is not in a viable state. Thanks, This is a different misconfiguration that libvirt also won't detect, right? In this case ownership claiming in the kernel will fail and qemu will fail too, like above. This, and the above, could be handled by having libvirt also open the group FD and get the device. It would prove both correct binding and viability. libvirt cannot do this in the group model because the group must be isolated in a container before the device can be accessed and libvirt cannot presume the QEMU container configuration. For direct device access, this certainly becomes a possibility and I've been trying to steer things in that direction, libvirt has the option to pass an fd for the iommufd and can then pass fds for each of the devices in the new uAPI paradigm. I had understood the point of this logic was to give better error reporting to users so that common misconfigurations could be diagnosed earlier. When I say 'small edge case' I mean it seems like an unlikely misconfiguration that someone would know to setup VFIO but then use the wrong BDFs to do it - arguably less likely than someone would know to setup VFIO but forget to unbind the other drivers in the group? I'm not sure how much testing libvirt does of other devices in a group, Laine? It had been so long since I looked at that, and the code was so obtuse, that I had to set something up to see what happened. 1) if there is another devices in the same group, and that device is bound to vfio-pci and in use by a different QEMU process, then libvirt refuses assign the device in question (it will allow assigning the device to the same guest as other devices in the same group. 2) if there is another device in the same group, and that device is bound to some other driver than vfio-pci, then libvirt doesn't notice, tells QEMU to do the assignment, and QEMU fails. Without looking/trying, I would have said that libvirt would check for (2), but I guess nobody ever tried it :-/ AIUI here, libvirt has a managed='yes|no' option per device. In the 'yes' case libvirt will unbind devices from their host driver and bind them to vfio-pci. In the 'no' case, I believe libvirt is still doing a sanity test on the driver, but only knows about vfio-pci. Correct. The initial step is to then enlighten libvirt that other drivers can be compatible for the 'no' case and later we can make smarter choices about which driver to use or allow the user to specify (ie. a user should be able to use vfio-pci rather than a variant driver if they choose) in the 'yes' case. Yes, that's the next step. I just wanted to first add a simple (i.e. difficult to botch up)
Re: [PATCH] util: basic support for vendor-specific vfio drivers
On Fri, 5 Aug 2022 15:20:24 -0300 Jason Gunthorpe wrote: > On Fri, Aug 05, 2022 at 11:24:08AM -0600, Alex Williamson wrote: > > On Thu, 4 Aug 2022 21:11:07 -0300 > > Jason Gunthorpe wrote: > > > > > On Thu, Aug 04, 2022 at 01:36:24PM -0600, Alex Williamson wrote: > > > > > > > > > That is reasonable, but I'd say those three kernels only have two > > > > > > drivers and they both have vfio as a substring in their name - so > > > > > > the > > > > > > simple thing of just substring searching 'vfio' would get us over > > > > > > that > > > > > > gap. > > > > > > > > > > Looking at the aliases for exactly "vfio_pci" isn't that much more > > > > > complicated, and "feels" a lot more reliable than just doing a > > > > > substring > > > > > search for "vfio" in the driver's name. (It would be, uh, "not > > > > > smart" to name a driver "vfio" if it wasn't actually a vfio > > > > > variant driver (or the opposite), but I could imagine it happening; > > > > > :-/) > > > > > > This is still pretty hacky. I'm worried about what happens to the > > > kernel if this becames some crazy unintended uAPI that we never really > > > thought about carefully... This was not a use case when we designed > > > the modules.alias stuff at least. > > > > > > BTW - why not do things the normal way? > > > > > > 1. readlink /sys/bus/pci/devices/XX/iommu_group > > > 2. Compute basename of #1 > > > 3. Check if /dev/vfio/#2 exists (or /sys/class/vfio/#2) > > > > > > It has a small edge case where a multi-device group might give a false > > > positive for an undrivered device, but for the purposes of libvirt > > > that seems pretty obscure.. (while the above has false negative > > > issues, obviously) > > > > This is not a small edge case, it's extremely common. We have a *lot* > > of users assigning desktop GPUs and other consumer grade hardware, which > > are usually multi-function devices without isolation exposed via ACS or > > quirks. > > The edge case is that the user has created a multi-device group, > manually assigned device 1 in the group to VFIO, left device 2 with no > driver and then told libvirt to manually use device 2. With the above > approach libvirt won't detect this misconfiguration and qemu will > fail. > > > The vfio group exists if any devices in the group are bound to a vfio > > driver, but the device is not accessible from the group unless the > > viability test passes. That means QEMU may not be able to get access > > to the device because the device we want isn't actually bound to a vfio > > driver or another device in the group is not in a viable state. Thanks, > > This is a different misconfiguration that libvirt also won't detect, > right? In this case ownership claiming in the kernel will fail and > qemu will fail too, like above. > > This, and the above, could be handled by having libvirt also open the > group FD and get the device. It would prove both correct binding and > viability. libvirt cannot do this in the group model because the group must be isolated in a container before the device can be accessed and libvirt cannot presume the QEMU container configuration. For direct device access, this certainly becomes a possibility and I've been trying to steer things in that direction, libvirt has the option to pass an fd for the iommufd and can then pass fds for each of the devices in the new uAPI paradigm. > I had understood the point of this logic was to give better error > reporting to users so that common misconfigurations could be diagnosed > earlier. When I say 'small edge case' I mean it seems like an unlikely > misconfiguration that someone would know to setup VFIO but then use > the wrong BDFs to do it - arguably less likely than someone would know > to setup VFIO but forget to unbind the other drivers in the group? I'm not sure how much testing libvirt does of other devices in a group, Laine? AIUI here, libvirt has a managed='yes|no' option per device. In the 'yes' case libvirt will unbind devices from their host driver and bind them to vfio-pci. In the 'no' case, I believe libvirt is still doing a sanity test on the driver, but only knows about vfio-pci. The initial step is to then enlighten libvirt that other drivers can be compatible for the 'no' case and later we can make smarter choices about which driver to use or allow the user to specify (ie. a user should be able to use vfio-pci rather than a variant driver if they choose) in the 'yes' case. If libvirt is currently testing that only the target device is bound to vfio-pci, then maybe we do have gaps for the ancillary devices in the group, but that gap changes if instead we only test that a vfio group exists relative to the iommu group of the target device. Thanks, Alex
Re: [PATCH] util: basic support for vendor-specific vfio drivers
On Thu, 4 Aug 2022 21:11:07 -0300 Jason Gunthorpe wrote: > On Thu, Aug 04, 2022 at 01:36:24PM -0600, Alex Williamson wrote: > > > > > That is reasonable, but I'd say those three kernels only have two > > > > drivers and they both have vfio as a substring in their name - so the > > > > simple thing of just substring searching 'vfio' would get us over that > > > > gap. > > > > > > Looking at the aliases for exactly "vfio_pci" isn't that much more > > > complicated, and "feels" a lot more reliable than just doing a substring > > > search for "vfio" in the driver's name. (It would be, uh, "not > > > smart" to name a driver "vfio" if it wasn't actually a vfio > > > variant driver (or the opposite), but I could imagine it happening; :-/) > > This is still pretty hacky. I'm worried about what happens to the > kernel if this becames some crazy unintended uAPI that we never really > thought about carefully... This was not a use case when we designed > the modules.alias stuff at least. > > BTW - why not do things the normal way? > > 1. readlink /sys/bus/pci/devices/XX/iommu_group > 2. Compute basename of #1 > 3. Check if /dev/vfio/#2 exists (or /sys/class/vfio/#2) > > It has a small edge case where a multi-device group might give a false > positive for an undrivered device, but for the purposes of libvirt > that seems pretty obscure.. (while the above has false negative > issues, obviously) This is not a small edge case, it's extremely common. We have a *lot* of users assigning desktop GPUs and other consumer grade hardware, which are usually multi-function devices without isolation exposed via ACS or quirks. The vfio group exists if any devices in the group are bound to a vfio driver, but the device is not accessible from the group unless the viability test passes. That means QEMU may not be able to get access to the device because the device we want isn't actually bound to a vfio driver or another device in the group is not in a viable state. Thanks, Alex
Re: [PATCH] util: basic support for vendor-specific vfio drivers
On Fri, Aug 05, 2022 at 11:46:17AM -0400, Laine Stump wrote: > On 8/5/22 5:40 AM, Daniel P. Berrangé wrote: > > On Mon, Aug 01, 2022 at 09:30:38AM -0400, Laine Stump wrote: > > > On 8/1/22 7:58 AM, Erik Skultety wrote: > > > > > > > > Instead of calling an external program and then grepping its output > > > > which > > > > technically could change in the future, wouldn't it be better if we read > > > > /lib/modules/`uname -r`/modules.alias and filtered whatever line had the > > > > vfio-pci' substring and compared the module name with the user-provided > > > > device > > > > driver? > > > > > > Again, although I was hesistant about calling an external command, and > > > asked > > > if there was something simpler, Alex still suggested modinfo, so I'll let > > > him answer that. Alex? > > > > > > (Also, although the format of the output of "uname -r" is pretty much > > > written in stone, you're still running an external command :-)) > > > > You wouldn't actually call 'uname -r', you'd invoke uname(2) function > > and use the 'release' field in 'struct utsname'. > > Yeah, I wasn't thinking clearly when I said that :-P > > > > > I'd favour reading modules.alias directly over invoking modinfo for > > sure, though I'd be even more in favour of the kernel just exposing > > the sysfs attribute and in the meanwhile just hardcoding the only 2 > > driver names that exist so far. > > The problem with hardcoding the 2 existing driver names is that it wouldn't > do any good to anyone developing a new driver, and part of the aim of doing > this is to make it possible for developers to test their new drivers using > libvirt (and management systems based on libvirt). I'm only suggesting hardcoding the driver names, *if* the kernel folks agree to expose the sysfs directory. Anyone developing new drivers is unlikely to have their drivers merged before this new sysfs dir is added, so it is not a significant enough real world blocker for them for us to worry about. Best to focus on what the best long term approach is, and not worry about problems that will only exist for a couple of kernel releases today. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] util: basic support for vendor-specific vfio drivers
On 8/5/22 5:40 AM, Daniel P. Berrangé wrote: On Mon, Aug 01, 2022 at 09:30:38AM -0400, Laine Stump wrote: On 8/1/22 7:58 AM, Erik Skultety wrote: Instead of calling an external program and then grepping its output which technically could change in the future, wouldn't it be better if we read /lib/modules/`uname -r`/modules.alias and filtered whatever line had the vfio-pci' substring and compared the module name with the user-provided device driver? Again, although I was hesistant about calling an external command, and asked if there was something simpler, Alex still suggested modinfo, so I'll let him answer that. Alex? (Also, although the format of the output of "uname -r" is pretty much written in stone, you're still running an external command :-)) You wouldn't actually call 'uname -r', you'd invoke uname(2) function and use the 'release' field in 'struct utsname'. Yeah, I wasn't thinking clearly when I said that :-P I'd favour reading modules.alias directly over invoking modinfo for sure, though I'd be even more in favour of the kernel just exposing the sysfs attribute and in the meanwhile just hardcoding the only 2 driver names that exist so far. The problem with hardcoding the 2 existing driver names is that it wouldn't do any good to anyone developing a new driver, and part of the aim of doing this is to make it possible for developers to test their new drivers using libvirt (and management systems based on libvirt).
[PULL 0/6] Misc next patches
The following changes since commit 09ed077d7fae5f825e18ff9a2004dcdd1b165edb: Merge tag 'trivial-branch-for-7.1-pull-request' of https://gitlab.com/laurent_vivier/qemu into staging (2022-08-04 17:21:13 -0700) are available in the Git repository at: https://gitlab.com/berrange/qemu tags/misc-next-pull-request for you to fetch changes up to e3fdb13e8851be570db41a50589ce82d11d61c12: util/qemu-sockets: Replace the call to close a socket with closesocket() (2022-08-05 16:18:15 +0100) Merge misc patches * Display deprecation warnings in -cpu help * Fix zerocopy IPv6 handling * Clarify platform support policy on minor release/backports * Fix closesocket call in error path Andrea Bolognani (1): docs: build-platforms: Clarify stance on minor releases and backports Bin Meng (1): util/qemu-sockets: Replace the call to close a socket with closesocket() Daniel P. Berrangé (3): target/i386: display deprecation status in '-cpu help' target/s390x: display deprecation status in '-cpu help' target/arm: display deprecation status in '-cpu help' Leonardo Bras (1): QIOChannelSocket: Add support for MSG_ZEROCOPY + IPV6 docs/about/build-platforms.rst | 5 - io/channel-socket.c| 4 ++-- target/arm/helper.c| 7 ++- target/i386/cpu.c | 5 + target/s390x/cpu_models.c | 23 ++- util/qemu-sockets.c| 4 ++-- 6 files changed, 37 insertions(+), 11 deletions(-) -- 2.37.1
[PULL 6/6] util/qemu-sockets: Replace the call to close a socket with closesocket()
From: Bin Meng
close() is a *nix function. It works on any file descriptor, and
sockets in *nix are an example of a file descriptor.
closesocket() is a Windows-specific function, which works only
specifically with sockets. Sockets on Windows do not use *nix-style
file descriptors, and socket() returns a handle to a kernel object
instead, so it must be closed with closesocket().
In QEMU there is already a logic to handle such platform difference
in os-posix.h and os-win32.h, that:
* closesocket maps to close on POSIX
* closesocket maps to a wrapper that calls the real closesocket()
on Windows
Replace the call to close a socket with closesocket() instead.
Signed-off-by: Bin Meng
Reviewed-by: Marc-André Lureau
Signed-off-by: Daniel P. Berrangé
---
util/qemu-sockets.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index 13b5b197f9..0e2298278f 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -487,7 +487,7 @@ int inet_connect_saddr(InetSocketAddress *saddr, Error
**errp)
if (ret < 0) {
error_setg_errno(errp, errno, "Unable to set KEEPALIVE");
-close(sock);
+closesocket(sock);
return -1;
}
}
@@ -1050,7 +1050,7 @@ static int unix_connect_saddr(UnixSocketAddress *saddr,
Error **errp)
return sock;
err:
-close(sock);
+closesocket(sock);
return -1;
}
--
2.37.1
[PULL 5/6] target/arm: display deprecation status in '-cpu help'
When the user queries CPU models via QMP there is a 'deprecated' flag
present, however, this is not done for the CLI '-cpu help' command.
Reviewed-by: Cornelia Huck
Signed-off-by: Daniel P. Berrangé
---
target/arm/helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index e1bdc80c35..d7bc467a2a 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -8185,12 +8185,17 @@ static gint arm_cpu_list_compare(gconstpointer a,
gconstpointer b)
static void arm_cpu_list_entry(gpointer data, gpointer user_data)
{
ObjectClass *oc = data;
+CPUClass *cc = CPU_CLASS(oc);
const char *typename;
char *name;
typename = object_class_get_name(oc);
name = g_strndup(typename, strlen(typename) - strlen("-" TYPE_ARM_CPU));
-qemu_printf(" %s\n", name);
+if (cc->deprecation_note) {
+qemu_printf(" %s (deprecated)\n", name);
+} else {
+qemu_printf(" %s\n", name);
+}
g_free(name);
}
--
2.37.1
[PULL 4/6] target/s390x: display deprecation status in '-cpu help'
When the user queries CPU models via QMP there is a 'deprecated' flag
present, however, this is not done for the CLI '-cpu help' command.
Reviewed-by: Cornelia Huck
Signed-off-by: Daniel P. Berrangé
---
target/s390x/cpu_models.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 1a562d2801..c3a4f80633 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -334,18 +334,31 @@ const S390CPUDef *s390_find_cpu_def(uint16_t type,
uint8_t gen, uint8_t ec_ga,
static void s390_print_cpu_model_list_entry(gpointer data, gpointer user_data)
{
const S390CPUClass *scc = S390_CPU_CLASS((ObjectClass *)data);
+CPUClass *cc = CPU_CLASS(scc);
char *name = g_strdup(object_class_get_name((ObjectClass *)data));
-const char *details = "";
+g_autoptr(GString) details = g_string_new("");
if (scc->is_static) {
-details = "(static, migration-safe)";
-} else if (scc->is_migration_safe) {
-details = "(migration-safe)";
+g_string_append(details, "static, ");
+}
+if (scc->is_migration_safe) {
+g_string_append(details, "migration-safe, ");
+}
+if (cc->deprecation_note) {
+g_string_append(details, "deprecated, ");
+}
+if (details->len) {
+/* cull trailing ', ' */
+g_string_truncate(details, details->len - 2);
}
/* strip off the -s390x-cpu */
g_strrstr(name, "-" TYPE_S390_CPU)[0] = 0;
-qemu_printf("s390 %-15s %-35s %s\n", name, scc->desc, details);
+if (details->len) {
+qemu_printf("s390 %-15s %-35s (%s)\n", name, scc->desc, details->str);
+} else {
+qemu_printf("s390 %-15s %-35s\n", name, scc->desc);
+}
g_free(name);
}
--
2.37.1
[PULL 3/6] target/i386: display deprecation status in '-cpu help'
When the user queries CPU models via QMP there is a 'deprecated' flag
present, however, this is not done for the CLI '-cpu help' command.
Reviewed-by: Cornelia Huck
Signed-off-by: Daniel P. Berrangé
---
target/i386/cpu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 194b5a31af..1db1278a59 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4837,6 +4837,11 @@ static void x86_cpu_list_entry(gpointer data, gpointer
user_data)
desc = g_strdup_printf("%s", model_id);
}
+if (cc->model && cc->model->cpudef->deprecation_note) {
+g_autofree char *olddesc = desc;
+desc = g_strdup_printf("%s (deprecated)", olddesc);
+}
+
qemu_printf("x86 %-20s %s\n", name, desc);
}
--
2.37.1
[PULL 2/6] QIOChannelSocket: Add support for MSG_ZEROCOPY + IPV6
From: Leonardo Bras
For using MSG_ZEROCOPY, there are two steps:
1 - io_writev() the packet, which enqueues the packet for sending, and
2 - io_flush(), which gets confirmation that all packets got correctly sent
Currently, if MSG_ZEROCOPY is used to send packets over IPV6, no error will
be reported in (1), but it will fail in the first time (2) happens.
This happens because (2) currently checks for cmsg_level & cmsg_type
associated with IPV4 only, before reporting any error.
Add checks for cmsg_level & cmsg_type associated with IPV6, and thus enable
support for MSG_ZEROCOPY + IPV6
Fixes: 2bc58ffc29 ("QIOChannelSocket: Implement io_writev zero copy flag &
io_flush for CONFIG_LINUX")
Signed-off-by: Leonardo Bras
Signed-off-by: Daniel P. Berrangé
---
io/channel-socket.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/io/channel-socket.c b/io/channel-socket.c
index 74a936cc1f..b76dca9cc1 100644
--- a/io/channel-socket.c
+++ b/io/channel-socket.c
@@ -746,8 +746,8 @@ static int qio_channel_socket_flush(QIOChannel *ioc,
}
cm = CMSG_FIRSTHDR();
-if (cm->cmsg_level != SOL_IP &&
-cm->cmsg_type != IP_RECVERR) {
+if (cm->cmsg_level != SOL_IP && cm->cmsg_type != IP_RECVERR &&
+cm->cmsg_level != SOL_IPV6 && cm->cmsg_type != IPV6_RECVERR) {
error_setg_errno(errp, EPROTOTYPE,
"Wrong cmsg in errqueue");
return -1;
--
2.37.1
[PULL 1/6] docs: build-platforms: Clarify stance on minor releases and backports
From: Andrea Bolognani These changes match those made in the following libvirt commits: 2ac78307af docs: Clarify our stance on backported packages 78cffd450a docs: Spell out our policy concerning minor releases Since QEMU's platform support policy is based on libvirt's, it makes sense to mirror these recent changes made to the latter. The policy is not altered significantly - we're simply spelling out some rules that were likely already being implicitly enforced. Signed-off-by: Andrea Bolognani Signed-off-by: Daniel P. Berrangé --- docs/about/build-platforms.rst | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst index 6b8496c430..26028756d0 100644 --- a/docs/about/build-platforms.rst +++ b/docs/about/build-platforms.rst @@ -71,7 +71,10 @@ The project aims to support the most recent major version at all times. Support for the previous major version will be dropped 2 years after the new major version is released or when the vendor itself drops support, whichever comes first. In this context, third-party efforts to extend the lifetime of a distro -are not considered, even when they are endorsed by the vendor (eg. Debian LTS). +are not considered, even when they are endorsed by the vendor (eg. Debian LTS); +the same is true of repositories that contain packages backported from later +releases (e.g. Debian backports). Within each major release, only the most +recent minor release is considered. For the purposes of identifying supported software versions available on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, RHEL, SLES and -- 2.37.1
Re: [PATCH] RFC: char: deprecate usage of bidirectional pipe
On Fri, Aug 05, 2022 at 01:55:41PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Tue, Jul 26, 2022 at 12:44 PM Daniel P. Berrangé
> wrote:
> >
> > On Tue, Jul 26, 2022 at 12:32:32PM +0400, marcandre.lur...@redhat.com wrote:
> > > From: Marc-André Lureau
> > >
> > > As Ed Swierk explained back in 2006:
> > > https://lists.nongnu.org/archive/html/qemu-devel/2006-12/msg00160.html
> > >
> > > "When qemu writes into the pipe, it immediately reads back what it just
> > > wrote and treats it as a monitor command, endlessly breathing its own
> > > exhaust."
> > >
> > > This is similarly confusing when using the chardev with a serial device,
> > > as reported in https://bugzilla.redhat.com/show_bug.cgi?id=2106975.
> > >
> > > It seems we have kept the support for bidirectional pipes for historical
> > > reasons and odd systems, however it's not documented in qemu -chardev
> > > options. I suggest to stop supporting it, for portability reasons.
> >
> > Hmm, I always assumed that in this scenario the pipe was operating
> > in output-only mode. Obviously not the case with the code as it
> > exists, but perhaps this would be useful ? eg its good as a serial
> > console logging mechanism at least.
>
> The current "-chardev pipe,id=id,path=path" option handling will first
> check the presence of unidirectional "path.in" & "path.out" (although
> they are opened RDWR...), and fallback on bidirectional "path".
>
> We could allow for the presence of "path.out" alone, although this may
> be a behaviour/breaking change:
If we allow path.out alone, then we loose error diagnostic when
path.out is succesfully opened, but path.in fails. I wouldn't
call that a back compat breakage.
My preference would always be to use the exact path that was
given as the CLI parameter.
IOW, we really ought to have had
-chardev pipe,id=id,input=path,output=path
and allowed both of them to be optional, eg both of them should
semantically mean /dev/null in behavioural terms if omitted
IOW we could just deprecate 'path' entirely and introduce this
saner approach to config.
Alternatively, I would just unconditionally change
diff --git a/chardev/char-pipe.c b/chardev/char-pipe.c
index 66d3b85091..3dda3d5cc6 100644
--- a/chardev/char-pipe.c
+++ b/chardev/char-pipe.c
@@ -142,7 +142,7 @@ static void qemu_chr_open_pipe(Chardev *chr,
if (fd_out >= 0) {
close(fd_out);
}
-TFR(fd_in = fd_out = qemu_open_old(filename, O_RDWR | O_BINARY));
+TFR(fd_in = fd_out = qemu_open_old(filename, O_WRONLY | O_BINARY));
if (fd_in < 0) {
error_setg_file_open(errp, errno, filename);
return;
given that semantics on any UNIX platform we target are for pipes to be
unidirectional, and eating our own output is uselessly broken, we could
reasonably justify doing that change simply as a bug fix and ignore any
notion of 'deprecation',
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] RFC: char: deprecate usage of bidirectional pipe
Hi
On Tue, Jul 26, 2022 at 12:44 PM Daniel P. Berrangé wrote:
>
> On Tue, Jul 26, 2022 at 12:32:32PM +0400, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > As Ed Swierk explained back in 2006:
> > https://lists.nongnu.org/archive/html/qemu-devel/2006-12/msg00160.html
> >
> > "When qemu writes into the pipe, it immediately reads back what it just
> > wrote and treats it as a monitor command, endlessly breathing its own
> > exhaust."
> >
> > This is similarly confusing when using the chardev with a serial device,
> > as reported in https://bugzilla.redhat.com/show_bug.cgi?id=2106975.
> >
> > It seems we have kept the support for bidirectional pipes for historical
> > reasons and odd systems, however it's not documented in qemu -chardev
> > options. I suggest to stop supporting it, for portability reasons.
>
> Hmm, I always assumed that in this scenario the pipe was operating
> in output-only mode. Obviously not the case with the code as it
> exists, but perhaps this would be useful ? eg its good as a serial
> console logging mechanism at least.
The current "-chardev pipe,id=id,path=path" option handling will first
check the presence of unidirectional "path.in" & "path.out" (although
they are opened RDWR...), and fallback on bidirectional "path".
We could allow for the presence of "path.out" alone, although this may
be a behaviour/breaking change:
diff --git a/chardev/char-pipe.c b/chardev/char-pipe.c
index 7db963035e..f78bcd7daf 100644
--- a/chardev/char-pipe.c
+++ b/chardev/char-pipe.c
@@ -137,12 +137,12 @@ static void qemu_chr_open_pipe(Chardev *chr,
g_free(filename_in);
g_free(filename_out);
if (fd_in < 0 || fd_out < 0) {
+if (fd_out >= 0) {
+goto out;
+}
if (fd_in >= 0) {
close(fd_in);
}
-if (fd_out >= 0) {
-close(fd_out);
-}
warn_report("Support for bidirectional pipe is deprecated,");
warn_report("please use portable one-way pipes instead (%s.in
& %s.out).",
filename, filename);
@@ -152,6 +152,7 @@ static void qemu_chr_open_pipe(Chardev *chr,
return;
}
}
+out:
qemu_chr_open_fd(chr, fd_in, fd_out);
or we introduce a new "access=write" option, or a new chardev type ?
>
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > docs/about/deprecated.rst | 6 ++
> > chardev/char-pipe.c | 4
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > index 7ee26626d5cf..dd5ca30d527b 100644
> > --- a/docs/about/deprecated.rst
> > +++ b/docs/about/deprecated.rst
> > @@ -45,6 +45,12 @@ transmit audio through the VNC protocol.
> > ``tty`` and ``parport`` are aliases that will be removed. Instead, the
> > actual backend names ``serial`` and ``parallel`` should be used.
> >
> > +``-chardev pipe`` support for bidirectional pipes (since 7.1)
> > +
> > +
> > +For portability reasons, the support for bidirectional ``pipe`` will
> > +be removed. Instead, use ``file.in`` & ``file.out`` unidirectional pipes.
> > +
> > Short-form boolean options (since 6.0)
> > ''
> >
> > diff --git a/chardev/char-pipe.c b/chardev/char-pipe.c
> > index 66d3b8509183..7db963035e7d 100644
> > --- a/chardev/char-pipe.c
> > +++ b/chardev/char-pipe.c
> > @@ -27,6 +27,7 @@
> > #include "qemu/main-loop.h"
> > #include "qemu/module.h"
> > #include "qemu/option.h"
> > +#include "qemu/error-report.h"
> > #include "chardev/char.h"
> >
> > #ifdef _WIN32
> > @@ -142,6 +143,9 @@ static void qemu_chr_open_pipe(Chardev *chr,
> > if (fd_out >= 0) {
> > close(fd_out);
> > }
> > +warn_report("Support for bidirectional pipe is deprecated,");
> > +warn_report("please use portable one-way pipes instead (%s.in &
> > %s.out).",
> > +filename, filename);
> > TFR(fd_in = fd_out = qemu_open_old(filename, O_RDWR | O_BINARY));
> > if (fd_in < 0) {
> > error_setg_file_open(errp, errno, filename);
> > --
> > 2.37.0.rc0
> >
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>
Re: [PATCH] util: basic support for vendor-specific vfio drivers
On Mon, Aug 01, 2022 at 09:30:38AM -0400, Laine Stump wrote: > On 8/1/22 7:58 AM, Erik Skultety wrote: > > > > Instead of calling an external program and then grepping its output which > > technically could change in the future, wouldn't it be better if we read > > /lib/modules/`uname -r`/modules.alias and filtered whatever line had the > > vfio-pci' substring and compared the module name with the user-provided > > device > > driver? > > Again, although I was hesistant about calling an external command, and asked > if there was something simpler, Alex still suggested modinfo, so I'll let > him answer that. Alex? > > (Also, although the format of the output of "uname -r" is pretty much > written in stone, you're still running an external command :-)) You wouldn't actually call 'uname -r', you'd invoke uname(2) function and use the 'release' field in 'struct utsname'. I'd favour reading modules.alias directly over invoking modinfo for sure, though I'd be even more in favour of the kernel just exposing the sysfs attribute and in the meanwhile just hardcoding the only 2 driver names that exist so far. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] util: basic support for vendor-specific vfio drivers
On Thu, Aug 04, 2022 at 01:51:20PM -0300, Jason Gunthorpe wrote: > On Mon, Aug 01, 2022 at 09:49:28AM -0600, Alex Williamson wrote: > > > > > > > Fortunately these new vendor/device-specific drivers can be easily > > > > > > identified as being "vfio-pci + extra stuff" - all that's needed is > > > > > > to > > > > > > look at the output of the "modinfo $driver_name" command to see if > > > > > > "vfio_pci" is in the alias list for the driver. > > We are moving in a direction on the kernel side to expose a sysfs > under the PCI device that definitively says it is VFIO enabled, eg > something like > > /sys/devices/pci:00/:00:1f.6/vfio/ > > Which is how every other subsystem in the kernel works. When this > lands libvirt can simply stat the vfio directory and confirm that the > device handle it is looking at is vfio enabled, for all things that > vfio support. > > My thinking had been to do the above work a bit later, but if libvirt > needs it right now then lets do it right away so we don't have to > worry about this hacky modprobe stuff down the road? I wouldn't go so far as to say libvirt "needs" it, as obviously we can make it work using module.alias information. I would say that exposing this in sysfs though makes it simpler and faster, because the check then essentially turns into a single stat() call. So from that POV libvirt would be happy to see that improvement. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH] util: basic support for vendor-specific vfio drivers
On Thu, Aug 04, 2022 at 03:11:07PM -0400, Laine Stump wrote: > On 8/4/22 2:36 PM, Jason Gunthorpe wrote: > > On Thu, Aug 04, 2022 at 12:18:26PM -0600, Alex Williamson wrote: > > > On Thu, 4 Aug 2022 13:51:20 -0300 > > > Jason Gunthorpe wrote: > > > > > > > On Mon, Aug 01, 2022 at 09:49:28AM -0600, Alex Williamson wrote: > > > > > > > > > > > > > Fortunately these new vendor/device-specific drivers can be > > > > > > > > > easily > > > > > > > > > identified as being "vfio-pci + extra stuff" - all that's > > > > > > > > > needed is to > > > > > > > > > look at the output of the "modinfo $driver_name" command to > > > > > > > > > see if > > > > > > > > > "vfio_pci" is in the alias list for the driver. > > > > > > > > We are moving in a direction on the kernel side to expose a sysfs > > > > under the PCI device that definitively says it is VFIO enabled, eg > > > > something like > > > > > > > > /sys/devices/pci:00/:00:1f.6/vfio/ > > > > > > > > Which is how every other subsystem in the kernel works. When this > > > > lands libvirt can simply stat the vfio directory and confirm that the > > > > device handle it is looking at is vfio enabled, for all things that > > > > vfio support. > > > > > > > > My thinking had been to do the above work a bit later, but if libvirt > > > > needs it right now then lets do it right away so we don't have to > > > > worry about this hacky modprobe stuff down the road? > > > > > > That seems like a pretty long gap, there are vfio-pci variant drivers > > > since v5.18 and this hasn't even been proposed for v6.0 (aka v5.20) > > > midway through the merge window. We therefore have at least 3 kernels > > > exposing devices in a way that libvirt can't make use of simply due to > > > a driver matching test. > > > > That is reasonable, but I'd say those three kernels only have two > > drivers and they both have vfio as a substring in their name - so the > > simple thing of just substring searching 'vfio' would get us over that > > gap. > > Looking at the aliases for exactly "vfio_pci" isn't that much more > complicated, and "feels" a lot more reliable than just doing a substring > search for "vfio" in the driver's name. (It would be, uh, "not smart" > to name a driver "vfio" if it wasn't actually a vfio variant > driver (or the opposite), but I could imagine it happening; :-/) If it is just 2 drivers so far then we don't need to even do a substring. We should do a precise full string match for just those couple of drivers that exist. We don't need to care about out of tree drivers IMHO. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH 80/80] qemuDomainDetermineDiskChain: Remove 'report_broken' argument
On Tue, Jul 26, 2022 at 04:37:58PM +0200, Peter Krempa wrote: > All callers pass 'true'. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_domain.c | 36 +++- > src/qemu/qemu_domain.h | 3 +-- > src/qemu/qemu_driver.c | 2 +- > src/qemu/qemu_hotplug.c | 4 ++-- > src/qemu/qemu_process.c | 2 +- > 5 files changed, 20 insertions(+), 27 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 79/80] qemu: Assume and retire QEMU_CAPS_BLOCKDEV_BACKUP
On Tue, Jul 26, 2022 at 04:37:57PM +0200, Peter Krempa wrote: > The blockdev-backup QMP command was introduced in qemu-2.3. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_backup.c| 6 -- > src/qemu/qemu_capabilities.c | 6 ++ > src/qemu/qemu_capabilities.h | 2 +- > tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 - > tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.1.0.x86_64.xml | 1 - > 29 files changed, 3 insertions(+), 37 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 78/80] qemu: Assume support and retire QEMU_CAPS_BLOCK_WRITE_THRESHOLD
On Tue, Jul 26, 2022 at 04:37:56PM +0200, Peter Krempa wrote: > The event was introduced in qemu-2.3 > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_capabilities.c | 3 +-- > src/qemu/qemu_capabilities.h | 2 +- > src/qemu/qemu_driver.c| 6 -- > tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 - > tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.1.0.x86_64.xml | 1 - > 29 files changed, 2 insertions(+), 35 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 77/80] qemu: capabilities: Retire QEMU_CAPS_QUERY_NAMED_BLOCK_NODES
On Tue, Jul 26, 2022 at 04:37:55PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_capabilities.c | 3 +-- > src/qemu/qemu_capabilities.h | 2 +- > tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 - > tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.1.0.x86_64.xml | 1 - > 28 files changed, 2 insertions(+), 29 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 76/80] qemu: Setup disk throttling for SD cards via monitor
On Tue, Jul 26, 2022 at 04:37:54PM +0200, Peter Krempa wrote: > Set it same way we set throttling for other disks in > qemuProcessSetupDiskThrottling. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_command.c | 42 - > src/qemu/qemu_process.c | 20 +++- > 2 files changed, 11 insertions(+), 51 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 75/80] qemu: Retire QEMU_CAPS_BLOCKDEV
On Tue, Jul 26, 2022 at 04:37:53PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_capabilities.c | 13 + > src/qemu/qemu_capabilities.h | 2 +- > src/qemu/qemu_process.c | 10 -- > tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 - > tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 - > tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.aarch64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml | 1 - > tests/qemucapabilitiesdata/caps_7.1.0.x86_64.xml | 1 - > tests/qemuhotplugtest.c | 1 - > tests/testutilsqemu.c | 3 --- > 31 files changed, 6 insertions(+), 49 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 74/80] qemuDomainDetermineDiskChain: Assume QEMU_CAPS_BLOCKDEV
On Tue, Jul 26, 2022 at 04:37:52PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_domain.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 73/80] qemuDomainValidateStorageSource: Remove 'maskBlockdev' argument
On Tue, Jul 26, 2022 at 04:37:51PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_domain.c | 10 -- > src/qemu/qemu_domain.h | 3 +-- > src/qemu/qemu_validate.c | 6 ++ > tests/qemublocktest.c| 4 ++-- > 4 files changed, 9 insertions(+), 14 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 72/80] qemuDomainValidateStorageSource: Remove QEMU_CAPS_BLOCKDEV validation
On Tue, Jul 26, 2022 at 04:37:50PM +0200, Peter Krempa wrote:
> While we assume that -blockdev is supported the validator had also some
> corner cases for -drive. Since we use '-drive' exclusively for the
> extremely rarely used SD cards it makes no sense to have the validation.
>
> Signed-off-by: Peter Krempa
> ---
> src/qemu/qemu_domain.c | 60 +++---
> 1 file changed, 3 insertions(+), 57 deletions(-)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 8997041b34..0839744660 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
[...]
> @@ -4961,11 +4922,9 @@ qemuDomainValidateStorageSource(virStorageSource *src,
> return -1;
> }
>
> -/* TFTP protocol was not supported for some time, lock it out at least
> with
> - * -blockdev */
> +/* TFTP protocol was not supported */
I would change the comment to 'TFTP protocol is not supported since QEMU
2.8.0'
> if (actualType == VIR_STORAGE_TYPE_NETWORK &&
> -src->protocol == VIR_STORAGE_NET_PROTOCOL_TFTP &&
> -blockdev) {
> +src->protocol == VIR_STORAGE_NET_PROTOCOL_TFTP) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> _("'tftp' protocol is not supported with this QEMU
> binary"));
> return -1;
Reviewed-by: Pavel Hrdina
signature.asc
Description: PGP signature
Re: [PATCH 71/80] qemuDomainDiskGetBackendAlias: Assume QEMU_CAPS_BLOCKDEV is supported
On Tue, Jul 26, 2022 at 04:37:49PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_command.c | 2 +- > src/qemu/qemu_domain.c | 11 --- > src/qemu/qemu_domain.h | 4 +--- > src/qemu/qemu_hotplug.c | 2 +- > 4 files changed, 7 insertions(+), 12 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 70/80] qemuDomainDiskBlockJobIsSupported: Assume QEMU_CAPS_BLOCKDEV is supported
On Tue, Jul 26, 2022 at 04:37:48PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_backup.c | 2 +- > src/qemu/qemu_checkpoint.c | 2 +- > src/qemu/qemu_domain.c | 10 +++--- > src/qemu/qemu_domain.h | 3 +-- > src/qemu/qemu_driver.c | 6 +++--- > src/qemu/qemu_snapshot.c | 13 + > 6 files changed, 14 insertions(+), 22 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 69/80] qemuDomainSecretStorageSourcePrepare: Remove cabapbility check when preparing cookies
On Tue, Jul 26, 2022 at 04:37:47PM +0200, Peter Krempa wrote: > The capability is checked when we validate the source in the first > place. Also it won't make sense any more. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_domain.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 68/80] qemu: domain: Assume QEMU_CAPS_BLOCKDEV for the domain private code
On Tue, Jul 26, 2022 at 04:37:46PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_domain.c| 20 --- > .../blockjob-mirror-in.xml| 1 + > .../migration-in-params-in.xml| 1 + > .../migration-out-nbd-out.xml | 1 + > .../migration-out-nbd-tls-out.xml | 1 + > .../migration-out-params-in.xml | 1 + > tests/qemustatusxml2xmldata/upgrade-out.xml | 1 + > .../qemustatusxml2xmldata/vcpus-multi-in.xml | 1 + > 8 files changed, 15 insertions(+), 12 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 67/80] qemu: command: Remove unused qemuGetDriveSourceString
On Tue, Jul 26, 2022 at 04:37:45PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_command.c | 208 > src/qemu/qemu_command.h | 4 - > 2 files changed, 212 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 66/80] qemu: command: Generate -drive for SD cards via JSON props
On Tue, Jul 26, 2022 at 04:37:44PM +0200, Peter Krempa wrote: > Since we know we have a modern qemu at hand which can interpret the > dotted syntax, we can format the -drive needed for SD cards via the > common infrastructure we have for all blockdev stuff. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_command.c | 121 +++- > 1 file changed, 20 insertions(+), 101 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 65/80] qemu: command: Delegate qemuBuildDriveStr to SD cards only
On Tue, Jul 26, 2022 at 04:37:43PM +0200, Peter Krempa wrote: > Remove the generic frontend-less -drive code from qemuBuildDriveStr by > assuming that we support only blockdev-enabled qemus. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_command.c | 15 ++- > 1 file changed, 2 insertions(+), 13 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 64/80] qemu: monitor: Remove unused qemuMonitorAddDrive/qemuMonitorDriveDel
On Tue, Jul 26, 2022 at 04:37:42PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_monitor.c | 33 --- > src/qemu/qemu_monitor.h | 6 --- > src/qemu/qemu_monitor_text.c | 82 > src/qemu/qemu_monitor_text.h | 6 --- > 4 files changed, 127 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 63/80] qemu: block: Remove support for legacy disk hotplug/unplug
On Tue, Jul 26, 2022 at 04:37:41PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_block.c | 14 -- > src/qemu/qemu_block.h | 2 -- > src/qemu/qemu_command.c | 3 +-- > 3 files changed, 1 insertion(+), 18 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 62/80] qemu: Remove 'driveAlias' argument of qemuBlockStorageSourceDetachPrepare
On Tue, Jul 26, 2022 at 04:37:40PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_block.c| 33 + > src/qemu/qemu_block.h| 3 +-- > src/qemu/qemu_blockjob.c | 4 ++-- > src/qemu/qemu_hotplug.c | 2 +- > 4 files changed, 17 insertions(+), 25 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 61/80] qemu: block: Remove unused qemuBlockStorageSourceChainDetachPrepareLegacy
On Tue, Jul 26, 2022 at 04:37:39PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_block.c | 26 -- > src/qemu/qemu_block.h | 3 --- > 2 files changed, 29 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 60/80] qemu: hotplug: Remove pre-blockdev code paths
On Tue, Jul 26, 2022 at 04:37:38PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_hotplug.c | 20 +++- > 1 file changed, 3 insertions(+), 17 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 59/80] qemuDomainRemoveDiskDevice: Remove special casing for disks on 'sd' bus
On Tue, Jul 26, 2022 at 04:37:37PM +0200, Peter Krempa wrote: > SD card disks can't be detached, so it makes no sense to special case > them in the unplug code. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_hotplug.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 58/80] qemuhotplugtest: Switch to -blockdev mode
On Tue, Jul 26, 2022 at 04:37:36PM +0200, Peter Krempa wrote: > Enable blockdev mode and convert the expected commands to the modern > equivalents in preparation for removing the old-style hotplug code > paths. > > Signed-off-by: Peter Krempa > --- > tests/qemuhotplugtest.c | 75 --- > .../qemuhotplug-base-ccw-live+ccw-virtio.xml | 2 +- > ...with-2-ccw-virtio+ccw-virtio-1-reverse.xml | 4 +- > ...otplug-base-ccw-live-with-2-ccw-virtio.xml | 2 +- > ...-with-ccw-virtio+ccw-virtio-2-explicit.xml | 2 +- > ...-ccw-live-with-ccw-virtio+ccw-virtio-2.xml | 2 +- > .../qemuhotplug-base-live+cdrom-scsi.xml | 2 +- > .../qemuhotplug-base-live+cdrom-usb.xml | 2 +- > ...uhotplug-base-live+disk-scsi-multipath.xml | 2 +- > ...+disk-scsi-wwn+disk-scsi-duplicate-wwn.xml | 2 +- > .../qemuhotplug-base-live+disk-scsi.xml | 2 +- > .../qemuhotplug-base-live+disk-usb.xml| 2 +- > .../qemuhotplug-base-live+disk-virtio.xml | 2 +- > ...thout-scsi-controller-live+disk-scsi-2.xml | 2 +- > 14 files changed, 62 insertions(+), 41 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 57/80] qemu: monitor: Remove unused qemuMonitor(Eject|Change)Media
On Tue, Jul 26, 2022 at 04:37:35PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_monitor.c | 27 - > src/qemu/qemu_monitor.h | 9 -- > src/qemu/qemu_monitor_json.c | 57 > src/qemu/qemu_monitor_json.h | 10 --- > tests/qemumonitorjsontest.c | 4 --- > 5 files changed, 107 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 56/80] qemu: hotplug: Remove pre-blockdev code path from qemuDomainChangeEjectableMedia
On Tue, Jul 26, 2022 at 04:37:34PM +0200, Peter Krempa wrote: > All media are changed in blockdev-instantiated cdroms now, remove the > old code. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_hotplug.c | 88 + > 1 file changed, 1 insertion(+), 87 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 55/80] qemu: driver: Remove remaining QEMU_CAPS_BLOCKDEV capability checks
On Tue, Jul 26, 2022 at 04:37:33PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 54/80] qemu: monitor: Remove unused qemuMonitorBlockStatsUpdateCapacity
On Tue, Jul 26, 2022 at 04:37:32PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_monitor.c | 11 --- > src/qemu/qemu_monitor.h | 4 --- > src/qemu/qemu_monitor_json.c | 59 > src/qemu/qemu_monitor_json.h | 3 -- > 4 files changed, 77 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 53/80] qemuDomainBlocksStatsGather: Remove pre-blockdev code paths
On Tue, Jul 26, 2022 at 04:37:31PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 31 --- > 1 file changed, 12 insertions(+), 19 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 52/80] qemuDomainBlockResize: Always refuse resize of empty/readonly disks
On Tue, Jul 26, 2022 at 04:37:30PM +0200, Peter Krempa wrote: > The operation makes no sense regardless of the way how we specify disks. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 51/80] qemu: Remove pre-blockdev PFLASH setup
On Tue, Jul 26, 2022 at 04:37:29PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_command.c | 60 +++-- > src/qemu/qemu_domain.c | 5 +--- > 2 files changed, 10 insertions(+), 55 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 50/80] qemu: command: Remove pre-blockdev floppy setup
On Tue, Jul 26, 2022 at 04:37:28PM +0200, Peter Krempa wrote: > With new qemu versions we setup floppies via -device. > > Some legacy output tests were not modernized yet so the expected output > needs to be adjusted. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_command.c | 50 +++-- > 1 file changed, 3 insertions(+), 47 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 49/80] qemu: monitor: Remove unused qemuMonitorDrivePivot
On Tue, Jul 26, 2022 at 04:37:27PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_monitor.c | 13 - > src/qemu/qemu_monitor.h | 3 --- > src/qemu/qemu_monitor_json.c | 23 --- > src/qemu/qemu_monitor_json.h | 5 - > tests/qemumonitorjsontest.c | 2 -- > 5 files changed, 46 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 48/80] qemu: driver: Remove pre-blockdev code paths from qemuDomainBlockPivot
On Tue, Jul 26, 2022 at 04:37:26PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 50 +++--- > 1 file changed, 22 insertions(+), 28 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 47/80] qemu: monitor: Remove unused qemuMonitorDiskNameLookup
On Tue, Jul 26, 2022 at 04:37:25PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_monitor.c | 14 --- > src/qemu/qemu_monitor.h | 5 --- > src/qemu/qemu_monitor_json.c | 77 > src/qemu/qemu_monitor_json.h | 8 > 4 files changed, 104 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 46/80] qemu: monitor: Remove unused arguments of qemuMonitorBlockStream
On Tue, Jul 26, 2022 at 04:37:24PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 2 -- > src/qemu/qemu_monitor.c | 15 +++ > src/qemu/qemu_monitor.h | 2 -- > src/qemu/qemu_monitor_json.c | 12 ++-- > src/qemu/qemu_monitor_json.h | 2 -- > tests/qemumonitorjsontest.c | 2 +- > 6 files changed, 6 insertions(+), 29 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 45/80] qemu: driver: Remove pre-blockdev code paths from qemuDomainBlockPullCommon
On Tue, Jul 26, 2022 at 04:37:23PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 41 ++--- > 1 file changed, 14 insertions(+), 27 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 44/80] qemu: monitor: Remove unused arguments of qemuMonitorBlockCommit
On Tue, Jul 26, 2022 at 04:37:22PM +0200, Peter Krempa wrote: > The 'persistjob' is always true and 'top' and 'base' are always NULL. > Adjust the functions to drop the arguments. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 3 --- > src/qemu/qemu_monitor.c | 15 +-- > src/qemu/qemu_monitor.h | 3 --- > src/qemu/qemu_monitor_json.c | 14 ++ > src/qemu/qemu_monitor_json.h | 3 --- > tests/qemumonitorjsontest.c | 2 +- > 6 files changed, 8 insertions(+), 32 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 43/80] qemu: driver: Remove pre-blockdev code paths from qemuDomainBlockCommit
On Tue, Jul 26, 2022 at 04:37:21PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 60 +- > 1 file changed, 13 insertions(+), 47 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 42/80] qemu: monitor: Remove unused qemuMonitorDriveMirror
On Tue, Jul 26, 2022 at 04:37:20PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_monitor.c | 21 -- > src/qemu/qemu_monitor.h | 10 - > src/qemu/qemu_monitor_json.c | 41 > src/qemu/qemu_monitor_json.h | 11 -- > tests/qemumonitorjsontest.c | 2 -- > 5 files changed, 85 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 41/80] qemu: driver: Remove pre-blockdev code paths from qemuDomainBlockCopyCommon
On Tue, Jul 26, 2022 at 04:37:19PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_driver.c | 171 - > 1 file changed, 66 insertions(+), 105 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 40/80] qemu: monitor: Remove unused qemuMonitorQueryNamedBlockNodes and clean up
On Tue, Jul 26, 2022 at 04:37:18PM +0200, Peter Krempa wrote: > The top level API is unused so it can be removed but internally the JSON > version is called by other monitor commands which extract information > from the reply. > > Thus qemuMonitorJSONQueryNamedBlockNodes is unexported and moved > appropriately. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_monitor.c | 9 --- > src/qemu/qemu_monitor.h | 2 -- > src/qemu/qemu_monitor_json.c | 52 +--- > src/qemu/qemu_monitor_json.h | 5 > 4 files changed, 30 insertions(+), 38 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 39/80] qemu: block: Remove unused qemuBlockGetNodeData
On Tue, Jul 26, 2022 at 04:37:17PM +0200, Peter Krempa wrote: > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_block.c | 40 > src/qemu/qemu_block.h | 3 --- > 2 files changed, 43 deletions(-) Reviewed-by: Pavel Hrdina signature.asc Description: PGP signature
Re: [PATCH 38/80] qemuDomainGetStatsBlock: Remove pre-blockdev code paths
On Tue, Jul 26, 2022 at 04:37:16PM +0200, Peter Krempa wrote:
> This function and it's callees were a bit more entangled so remove the
> pre-blockdev code separately.
>
> Signed-off-by: Peter Krempa
> ---
> src/qemu/qemu_driver.c | 80 +++---
> 1 file changed, 12 insertions(+), 68 deletions(-)
>
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index e7b0acd46f..811b4a610c 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
[...]
> @@ -18403,20 +18367,15 @@
> qemuDomainGetStatsBlockExportHeader(virDomainDiskDef *disk,
> static int
> qemuDomainGetStatsBlockExportDisk(virDomainDiskDef *disk,
>GHashTable *stats,
> - GHashTable *nodestats,
>virTypedParamList *params,
>size_t *recordnr,
>bool visitBacking,
>virQEMUDriver *driver,
>virQEMUDriverConfig *cfg,
> - virDomainObj *dom,
> - bool blockdev)
> + virDomainObj *dom)
>
> {
> virStorageSource *n;
> -const char *frontendalias;
> -const char *backendalias;
> -const char *backendstoragealias;
>
> /*
> * This helps to keep logs clean from error messages on getting stats
> @@ -18452,9 +18411,10 @@ qemuDomainGetStatsBlockExportDisk(virDomainDiskDef
> *disk,
>
> for (n = disk->src; virStorageSourceIsBacking(n); n = n->backingStore) {
> g_autofree char *alias = NULL;
> +const char *frontendalias;
> +const char *backendalias;
> +const char *backendstoragealias;
This code movement seems to be unrelated.
> -/* for 'sd' disks we won't be displaying stats for the backing chain
> - * as we don't update the stats correctly */
> if (QEMU_DOMAIN_DISK_PRIVATE(disk)->qomName) {
> frontendalias = QEMU_DOMAIN_DISK_PRIVATE(disk)->qomName;
> backendalias = n->nodeformat;
> @@ -18465,7 +18425,8 @@ qemuDomainGetStatsBlockExportDisk(virDomainDiskDef
> *disk,
> !(alias = qemuDomainStorageAlias(disk->info.alias, n->id)))
> return -1;
>
> -qemuDomainGetStatsOneBlockRefreshNamed(n, alias, stats,
> nodestats);
> +/* for 'sd' disks we won't be displaying stats for the backing
> chain
> + * as we don't update the stats correctly */
Same for the comment movement.
> frontendalias = alias;
> backendalias = alias;
Reviewed-by: Pavel Hrdina
signature.asc
Description: PGP signature
