Re: [PATCH v2] util: basic support for VFIO variant drivers

2023-05-31 Thread Alex Williamson
On Wed, 31 May 2023 17:46:50 -0300
Jason Gunthorpe  wrote:

> On Wed, May 31, 2023 at 02:40:01PM -0600, Alex Williamson wrote:
> 
> > Also note that we're saying "vfio" not "vfio-pci".  Only the mdev
> > interface has the device_api attribute to indicate the exported vfio
> > device interface.  The "vfio_pci:" match in modalias indicates a vfio
> > PCI driver, not necessarily a driver that provides a vfio-pci API.
> 
> modalias was designed so you take the /sys/.../modalias file, prepend
> vfio_ then do a standard modalias search on that string. The matching
> module should be loaded and the module name bound to the device as the
> driver name.
> 
> There should be no bus type dependencies in any of this in management
> code.

For example, modalias of a random wifi adapter:

pci:v8086d2723sv8086sd0084bc02sc80i00

The bus name is prepended because the encoding is bus specific.  Yes,
code doesn't really need to interpret that, it simply adds "vfio_" to
the beginning of the string and finds the matching driver with the
fewest number of wildcards in modules.alias.

We are not code, we have a vfio_pci driver, a vfio-pci device API, and
a vfio_pci: modalias prefix, it's easy to get them confused and infer
information that isn't intended.  All I'm trying (poorly) to clarify is
that a vfio_pci: modalias prefix only indicates a vfio driver for a PCI
device.  It does not guarantee the vfio device API exposed to userspace
is vfio-pci.  Therefore management tools should be cautious to make
assumptions about the type of device the VM will see even though we've
got vfio-pci written all over the place.  Thanks,

Alex



Re: [PATCH v2] util: basic support for VFIO variant drivers

2023-05-31 Thread Jason Gunthorpe
On Wed, May 31, 2023 at 02:40:01PM -0600, Alex Williamson wrote:

> Also note that we're saying "vfio" not "vfio-pci".  Only the mdev
> interface has the device_api attribute to indicate the exported vfio
> device interface.  The "vfio_pci:" match in modalias indicates a vfio
> PCI driver, not necessarily a driver that provides a vfio-pci API.  

modalias was designed so you take the /sys/.../modalias file, prepend
vfio_ then do a standard modalias search on that string. The matching
module should be loaded and the module name bound to the device as the
driver name.

There should be no bus type dependencies in any of this in management
code.

Jason



Re: [PATCH v2] util: basic support for VFIO variant drivers

2023-05-31 Thread Alex Williamson
On Wed, 31 May 2023 14:30:52 -0300
Jason Gunthorpe  wrote:

> On Wed, May 31, 2023 at 01:18:44PM -0400, Laine Stump wrote:
> > On 5/31/23 10:31 AM, Jason Gunthorpe wrote:  
> > > On Wed, May 31, 2023 at 03:18:17PM +0100, Joao Martins wrote:  
> > > > Hey Laine,
> > > > 
> > > > On 23/08/2022 15:11, Laine Stump wrote:  
> > > > > ping.
> > > > > 
> > > > > I have a different version of this patch where I do read the 
> > > > > modules.alias file
> > > > > rather than just checking the name of the driver, but that also 
> > > > > requires "double
> > > > > mocking" open() in the unit test, which wasn't working properly, and 
> > > > > I'd rather
> > > > > not spend the time figuring it out if it's not going to be needed. 
> > > > > (Alex prefers
> > > > > that version because it is more correct than just checking the name, 
> > > > > and he's
> > > > > concerned that the new sysfs-based API may take longer than we're 
> > > > > thinking to
> > > > > get into downstream distros, but the version in this patch does 
> > > > > satisfy both
> > > > > Jason and Daniel's suggested implementations). Anyway, I can post the 
> > > > > other
> > > > > patch if anyone is interested.
> > > > >   
> > > > [sorry for the thread necromancy]  
> > 
> > Heh. I had actually dug out this same thread last week and started a mail to
> > ask Jason if the planned sysfs stuff had ever been pushed, but then forgot
> > to hit "send" :-)
> > 
> > Now that there are multiple vfio variant drivers available (for igb, e1000e,
> > and mlx5 that I know of),  
> 
> Oh I haven't seen those intel ones posted yet?
> 
> > Jason, can you point me at the information for this patch in an ELI5 manner
> > for a non-kernel person? (including what upstream kernel it's in, and what
> > it is that I need to look at to determine if a driver is a vfio
> > variant).  
> 
> It is this patch:
> 
> commit 3c28a76124b25882411f005924be73795b6ef078
> Author: Yi Liu 
> Date:   Wed Sep 21 18:44:01 2022 +0800
> 
> vfio: Add struct device to vfio_device
> 
> and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> sysfs path of the parent, indicating the device is bound to a vfio
> driver, e.g.:
> 
> /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
> 
> It is also a preparatory step toward adding cdev for supporting future
> device-oriented uAPI.
> 
> Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
> 
> Suggested-by: Jason Gunthorpe 
> Signed-off-by: Yi Liu 
> Signed-off-by: Kevin Tian 
> Reviewed-by: Jason Gunthorpe 
> Link: 
> https://lore.kernel.org/r/20220921104401.38898-16-kevin.t...@intel.com
> Signed-off-by: Alex Williamson 
> 
> $ git describe --contains 3c28a76124b25882411f005924be73795b6ef078
> v6.1-rc1~42^2~35
> 
> So it is in v6.1-rc1
> 
> libvirt should start thinking about determining the vfioX number for
> the device, we will need that for iommufd enablement eventually
> 
> so, stat for a directory like this:
> 
> /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev
> 
> Confirms vfio
>
> Then scan it to get 'vfioX' which will eventually be the /dev/ node
> libvirt will have to open.
> 
> And the other part is something in the stack should use the modalias
> mechanism to find load and bind the correct variant driver.

I'd forgotten about this as well, so after binding a driver to a device
we can tell if that driver presents a vfio interface by looking for
this sysfs directory.  Prior to binding to a device, we can only know
if a driver provides a vfio interface through modalias.

Also note that we're saying "vfio" not "vfio-pci".  Only the mdev
interface has the device_api attribute to indicate the exported vfio
device interface.  The "vfio_pci:" match in modalias indicates a vfio
PCI driver, not necessarily a driver that provides a vfio-pci API.  We
have no current examples to the contrary, but for instance I wouldn't
recommend validating whether mode='subsystem' type='pci' is appropriate
based on that information.  Thanks,

Alex



Re: [PATCH v6 05/11] docs/deprecated: move QMP events bellow QMP command section

2023-05-31 Thread Eric Blake
In the subject: s/bellow/below/

On Fri, May 26, 2023 at 05:53:55PM +0100, Alex Bennée wrote:
> Also rename the section to make the fact this is part of the
> management protocol even clearer.
> 
> Suggested-by: Markus Armbruster 
> Signed-off-by: Alex Bennée 
> ---
>  docs/about/deprecated.rst | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)

Otherwise,

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



[PULL 02/11] trace-events: remove the remaining vcpu trace events

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

While these are all in helper functions being designated vcpu events
complicates the removal of the dynamic vcpu state code. TCG plugins
allow you to instrument vcpu_[init|exit|idle].

We rename cpu_reset and make it a normal trace point.

Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-3-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-3-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 hw/core/cpu-common.c   |  4 ++--
 trace/control-target.c |  1 -
 trace/control.c|  2 --
 hw/core/trace-events   |  3 +++
 trace-events   | 31 ---
 5 files changed, 5 insertions(+), 36 deletions(-)

diff --git a/hw/core/cpu-common.c b/hw/core/cpu-common.c
index 5ccc3837b6..951477a7fd 100644
--- a/hw/core/cpu-common.c
+++ b/hw/core/cpu-common.c
@@ -32,7 +32,7 @@
 #include "sysemu/tcg.h"
 #include "hw/boards.h"
 #include "hw/qdev-properties.h"
-#include "trace/trace-root.h"
+#include "trace.h"
 #include "qemu/plugin.h"
 
 CPUState *cpu_by_arch_id(int64_t id)
@@ -113,7 +113,7 @@ void cpu_reset(CPUState *cpu)
 {
 device_cold_reset(DEVICE(cpu));
 
-trace_guest_cpu_reset(cpu);
+trace_cpu_reset(cpu->cpu_index);
 }
 
 static void cpu_common_reset_hold(Object *obj)
diff --git a/trace/control-target.c b/trace/control-target.c
index c0c1e2310a..a10752924b 100644
--- a/trace/control-target.c
+++ b/trace/control-target.c
@@ -144,5 +144,4 @@ void trace_init_vcpu(CPUState *vcpu)
 }
 }
 }
-trace_guest_cpu_enter(vcpu);
 }
diff --git a/trace/control.c b/trace/control.c
index 6c77cc6318..d24af91004 100644
--- a/trace/control.c
+++ b/trace/control.c
@@ -277,8 +277,6 @@ void trace_fini_vcpu(CPUState *vcpu)
 TraceEventIter iter;
 TraceEvent *ev;
 
-trace_guest_cpu_exit(vcpu);
-
 trace_event_iter_init_all();
 while ((ev = trace_event_iter_next()) != NULL) {
 if (trace_event_is_vcpu(ev) &&
diff --git a/hw/core/trace-events b/hw/core/trace-events
index 56da55bd71..2cf085ac66 100644
--- a/hw/core/trace-events
+++ b/hw/core/trace-events
@@ -29,3 +29,6 @@ clock_set(const char *clk, uint64_t old, uint64_t new) "'%s', 
%"PRIu64"Hz->%"PRI
 clock_propagate(const char *clk) "'%s'"
 clock_update(const char *clk, const char *src, uint64_t hz, int cb) "'%s', 
src='%s', val=%"PRIu64"Hz cb=%d"
 clock_set_mul_div(const char *clk, uint32_t oldmul, uint32_t mul, uint32_t 
olddiv, uint32_t div) "'%s', mul: %u -> %u, div: %u -> %u"
+
+# cpu-common.c
+cpu_reset(int cpu_index) "%d"
diff --git a/trace-events b/trace-events
index 691c3533e4..dd318ed1af 100644
--- a/trace-events
+++ b/trace-events
@@ -54,34 +54,3 @@ qmp_job_resume(void *job) "job %p"
 qmp_job_complete(void *job) "job %p"
 qmp_job_finalize(void *job) "job %p"
 qmp_job_dismiss(void *job) "job %p"
-
-
-### Guest events, keep at bottom
-
-
-## vCPU
-
-# trace/control-target.c
-
-# Hot-plug a new virtual (guest) CPU
-#
-# Mode: user, softmmu
-# Targets: all
-vcpu guest_cpu_enter(void)
-
-# trace/control.c
-
-# Hot-unplug a virtual (guest) CPU
-#
-# Mode: user, softmmu
-# Targets: all
-vcpu guest_cpu_exit(void)
-
-# hw/core/cpu.c
-
-# Reset the state of a virtual (guest) CPU
-#
-# Mode: user, softmmu
-# Targets: all
-vcpu guest_cpu_reset(void)
-
-- 
2.40.1



[PULL 09/11] tcg: remove the final vestiges of dstate

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

Now we no longer have dynamic state affecting things we can remove the
additional fields in cpu.h and simplify the TB hash calculation.

For the benchmark:

hyperfine -w 2 -m 20 \
  "./arm-softmmu/qemu-system-arm -cpu cortex-a15 \
-machine type=virt,highmem=off \
-display none -m 2048 \
-serial mon:stdio \
-netdev user,id=unet,hostfwd=tcp::-:22 \
-device virtio-net-pci,netdev=unet \
-device virtio-scsi-pci \
-blockdev 
driver=raw,node-name=hd,discard=unmap,file.driver=host_device,file.filename=/dev/zen-disk/debian-bullseye-armhf
 \
-device scsi-hd,drive=hd -smp 4 \
-kernel /home/alex/lsrc/linux.git/builds/arm/arch/arm/boot/zImage \
-append 'console=ttyAMA0 root=/dev/sda2 systemd.unit=benchmark.service' 
\
-snapshot"

It has a marginal effect on runtime, before:

  Time (mean ± σ): 26.279 s ±  2.438 s[User: 41.113 s, System: 1.843 s]
  Range (min … max):   24.420 s … 32.565 s20 runs

after:

  Time (mean ± σ): 24.440 s ±  2.885 s[User: 34.474 s, System: 2.028 s]
  Range (min … max):   21.663 s … 29.937 s20 runs

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1358
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-10-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-9-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 accel/tcg/tb-hash.h   | 6 +++---
 include/exec/exec-all.h   | 3 ---
 include/hw/core/cpu.h | 5 -
 accel/tcg/cpu-exec.c  | 7 +--
 accel/tcg/tb-maint.c  | 5 ++---
 accel/tcg/translate-all.c | 6 --
 6 files changed, 6 insertions(+), 26 deletions(-)

diff --git a/accel/tcg/tb-hash.h b/accel/tcg/tb-hash.h
index 83dc610e4c..1d19c69caa 100644
--- a/accel/tcg/tb-hash.h
+++ b/accel/tcg/tb-hash.h
@@ -61,10 +61,10 @@ static inline unsigned int 
tb_jmp_cache_hash_func(target_ulong pc)
 #endif /* CONFIG_SOFTMMU */
 
 static inline
-uint32_t tb_hash_func(tb_page_addr_t phys_pc, target_ulong pc, uint32_t flags,
-  uint32_t cf_mask, uint32_t trace_vcpu_dstate)
+uint32_t tb_hash_func(tb_page_addr_t phys_pc, target_ulong pc,
+  uint32_t flags, uint32_t cf_mask)
 {
-return qemu_xxhash7(phys_pc, pc, flags, cf_mask, trace_vcpu_dstate);
+return qemu_xxhash6(phys_pc, pc, flags, cf_mask);
 }
 
 #endif
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 4d2b151986..3b1b57f6ad 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -545,9 +545,6 @@ struct TranslationBlock {
 #define CF_CLUSTER_MASK  0xff00 /* Top 8 bits are cluster ID */
 #define CF_CLUSTER_SHIFT 24
 
-/* Per-vCPU dynamic tracing state used to generate this TB */
-uint32_t trace_vcpu_dstate;
-
 /*
  * Above fields used for comparing
  */
diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index 39150cf8f8..383456d1b3 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -266,7 +266,6 @@ typedef void (*run_on_cpu_func)(CPUState *cpu, 
run_on_cpu_data data);
 struct qemu_work_item;
 
 #define CPU_UNSET_NUMA_NODE_ID -1
-#define CPU_TRACE_DSTATE_MAX_EVENTS 32
 
 /**
  * CPUState:
@@ -407,10 +406,6 @@ struct CPUState {
 /* Use by accel-block: CPU is executing an ioctl() */
 QemuLockCnt in_ioctl_lock;
 
-/* Used for events with 'vcpu' and *without* the 'disabled' properties */
-DECLARE_BITMAP(trace_dstate_delayed, CPU_TRACE_DSTATE_MAX_EVENTS);
-DECLARE_BITMAP(trace_dstate, CPU_TRACE_DSTATE_MAX_EVENTS);
-
 DECLARE_BITMAP(plugin_mask, QEMU_PLUGIN_EV_MAX);
 
 #ifdef CONFIG_PLUGIN
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 0e741960da..4a1dce98ff 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -175,7 +175,6 @@ struct tb_desc {
 tb_page_addr_t page_addr0;
 uint32_t flags;
 uint32_t cflags;
-uint32_t trace_vcpu_dstate;
 };
 
 static bool tb_lookup_cmp(const void *p, const void *d)
@@ -187,7 +186,6 @@ static bool tb_lookup_cmp(const void *p, const void *d)
 tb_page_addr0(tb) == desc->page_addr0 &&
 tb->cs_base == desc->cs_base &&
 tb->flags == desc->flags &&
-tb->trace_vcpu_dstate == desc->trace_vcpu_dstate &&
 tb_cflags(tb) == desc->cflags) {
 /* check next page if needed */
 tb_page_addr_t tb_phys_page1 = tb_page_addr1(tb);
@@ -228,7 +226,6 @@ static TranslationBlock *tb_htable_lookup(CPUState *cpu, 
target_ulong pc,
 desc.cs_base = cs_base;
 desc.flags = flags;
 desc.cflags = cflags;
-desc.trace_vcpu_dstate = *cpu->trace_dstate;
 desc.pc = pc;
 phys_pc = get_page_addr_code(desc.env, pc);
 if (phys_pc == -1) {
@@ -236,7 +233,7 @@ static TranslationBlock *tb_htable_lookup(CPUState *cpu, 
target_ulong pc,
 }
 desc.page_addr0 = phys_pc;
 h = tb_hash_func(phys_pc, (cflags & 

[PULL 08/11] trace: remove control-vcpu.h

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

Now we no longer have vcpu controlled trace events we can excise the
code that allows us to query its status.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-9-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-8-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 trace/control-vcpu.h  | 47 ---
 trace/qmp.c   |  2 +-
 scripts/tracetool/format/h.py |  5 +---
 3 files changed, 2 insertions(+), 52 deletions(-)
 delete mode 100644 trace/control-vcpu.h

diff --git a/trace/control-vcpu.h b/trace/control-vcpu.h
deleted file mode 100644
index 800fc5a219..00
--- a/trace/control-vcpu.h
+++ /dev/null
@@ -1,47 +0,0 @@
-/*
- * Interface for configuring and controlling the state of tracing events.
- *
- * Copyright (C) 2011-2016 Lluís Vilanova 
- *
- * This work is licensed under the terms of the GNU GPL, version 2 or later.
- * See the COPYING file in the top-level directory.
- */
-
-#ifndef TRACE__CONTROL_VCPU_H
-#define TRACE__CONTROL_VCPU_H
-
-#include "control.h"
-#include "event-internal.h"
-#include "hw/core/cpu.h"
-
-/**
- * trace_event_get_vcpu_state:
- * @vcpu: Target vCPU.
- * @id: Event identifier name.
- *
- * Get the tracing state of an event (both static and dynamic) for the given
- * vCPU.
- *
- * If the event has the disabled property, the check will have no performance
- * impact.
- */
-#define trace_event_get_vcpu_state(vcpu, id)\
-((id ##_ENABLED) && \
- trace_event_get_vcpu_state_dynamic_by_vcpu_id( \
- vcpu, _ ## id ## _EVENT.vcpu_id))
-
-#include "control-internal.h"
-
-static inline bool
-trace_event_get_vcpu_state_dynamic_by_vcpu_id(CPUState *vcpu,
-  uint32_t vcpu_id)
-{
-/* it's on fast path, avoid consistency checks (asserts) */
-if (unlikely(trace_events_enabled_count)) {
-return test_bit(vcpu_id, vcpu->trace_dstate);
-} else {
-return false;
-}
-}
-
-#endif
diff --git a/trace/qmp.c b/trace/qmp.c
index aa760f1fc4..3e3971c6a8 100644
--- a/trace/qmp.c
+++ b/trace/qmp.c
@@ -10,7 +10,7 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-trace.h"
-#include "control-vcpu.h"
+#include "control.h"
 
 
 static bool check_events(bool ignore_unavailable, bool is_pattern,
diff --git a/scripts/tracetool/format/h.py b/scripts/tracetool/format/h.py
index 285d7b03a9..ea126b07ea 100644
--- a/scripts/tracetool/format/h.py
+++ b/scripts/tracetool/format/h.py
@@ -16,10 +16,7 @@
 
 
 def generate(events, backend, group):
-if group == "root":
-header = "trace/control-vcpu.h"
-else:
-header = "trace/control.h"
+header = "trace/control.h"
 
 out('/* This file is autogenerated by tracetool, do not edit. */',
 '',
-- 
2.40.1



[PULL 05/11] docs/deprecated: move QMP events bellow QMP command section

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

Also rename the section to make the fact this is part of the
management protocol even clearer.

Suggested-by: Markus Armbruster 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-6-alex.ben...@linaro.org
Signed-off-by: Stefan Hajnoczi 
---
 docs/about/deprecated.rst | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index e934e0a13a..7c45a64363 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -218,6 +218,15 @@ instruction per translated block" mode (which can be set 
on the
 command line or via the HMP, but not via QMP). The information remains
 available via the HMP 'info jit' command.
 
+QEMU Machine Protocol (QMP) events
+--
+
+``MEM_UNPLUG_ERROR`` (since 6.2)
+
+
+Use the more generic event ``DEVICE_UNPLUG_GUEST_ERROR`` instead.
+
+
 Human Monitor Protocol (HMP) commands
 -
 
@@ -251,15 +260,6 @@ it. Since all recent x86 hardware from the past >10 years 
is capable of the
 64-bit x86 extensions, a corresponding 64-bit OS should be used instead.
 
 
-QEMU API (QAPI) events
---
-
-``MEM_UNPLUG_ERROR`` (since 6.2)
-
-
-Use the more generic event ``DEVICE_UNPLUG_GUEST_ERROR`` instead.
-
-
 System emulator machines
 
 
-- 
2.40.1



[PULL 07/11] trace: remove code that depends on setting vcpu

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

Now we no longer have any events that are for vcpus we can start
excising the code from the trace control. As the vcpu parameter is
encoded as part of QMP we just stub out the has_vcpu/vcpu parameters
rather than alter the API.

Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-8-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-7-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 trace/control-internal.h |  10 
 trace/control-vcpu.h |  16 --
 trace/control.h  |  48 -
 hw/core/cpu-common.c |   2 -
 stubs/trace-control.c|  13 -
 trace/control-target.c   | 108 ---
 trace/control.c  |  16 --
 trace/qmp.c  |  74 +++
 trace/trace-hmp-cmds.c   |  18 ++-
 9 files changed, 20 insertions(+), 285 deletions(-)

diff --git a/trace/control-internal.h b/trace/control-internal.h
index 0178121720..8d818d359b 100644
--- a/trace/control-internal.h
+++ b/trace/control-internal.h
@@ -25,16 +25,6 @@ static inline uint32_t trace_event_get_id(TraceEvent *ev)
 return ev->id;
 }
 
-static inline uint32_t trace_event_get_vcpu_id(TraceEvent *ev)
-{
-return 0;
-}
-
-static inline bool trace_event_is_vcpu(TraceEvent *ev)
-{
-return false;
-}
-
 static inline const char * trace_event_get_name(TraceEvent *ev)
 {
 assert(ev != NULL);
diff --git a/trace/control-vcpu.h b/trace/control-vcpu.h
index 0f98ebe7b5..800fc5a219 100644
--- a/trace/control-vcpu.h
+++ b/trace/control-vcpu.h
@@ -30,13 +30,6 @@
  trace_event_get_vcpu_state_dynamic_by_vcpu_id( \
  vcpu, _ ## id ## _EVENT.vcpu_id))
 
-/**
- * trace_event_get_vcpu_state_dynamic:
- *
- * Get the dynamic tracing state of an event for the given vCPU.
- */
-static bool trace_event_get_vcpu_state_dynamic(CPUState *vcpu, TraceEvent *ev);
-
 #include "control-internal.h"
 
 static inline bool
@@ -51,13 +44,4 @@ trace_event_get_vcpu_state_dynamic_by_vcpu_id(CPUState *vcpu,
 }
 }
 
-static inline bool trace_event_get_vcpu_state_dynamic(CPUState *vcpu,
-  TraceEvent *ev)
-{
-uint32_t vcpu_id;
-assert(trace_event_is_vcpu(ev));
-vcpu_id = trace_event_get_vcpu_id(ev);
-return trace_event_get_vcpu_state_dynamic_by_vcpu_id(vcpu, vcpu_id);
-}
-
 #endif
diff --git a/trace/control.h b/trace/control.h
index 23b8393b29..dfd209edd8 100644
--- a/trace/control.h
+++ b/trace/control.h
@@ -89,23 +89,6 @@ static bool trace_event_is_pattern(const char *str);
  */
 static uint32_t trace_event_get_id(TraceEvent *ev);
 
-/**
- * trace_event_get_vcpu_id:
- *
- * Get the per-vCPU identifier of an event.
- *
- * Special value #TRACE_VCPU_EVENT_NONE means the event is not vCPU-specific
- * (does not have the "vcpu" property).
- */
-static uint32_t trace_event_get_vcpu_id(TraceEvent *ev);
-
-/**
- * trace_event_is_vcpu:
- *
- * Whether this is a per-vCPU event.
- */
-static bool trace_event_is_vcpu(TraceEvent *ev);
-
 /**
  * trace_event_get_name:
  *
@@ -172,21 +155,6 @@ static bool trace_event_get_state_dynamic(TraceEvent *ev);
  */
 void trace_event_set_state_dynamic(TraceEvent *ev, bool state);
 
-/**
- * trace_event_set_vcpu_state_dynamic:
- *
- * Set the dynamic tracing state of an event for the given vCPU.
- *
- * Pre-condition: trace_event_get_vcpu_state_static(ev) == true
- *
- * Note: Changes for execution-time events with the 'tcg' property will not be
- *   propagated until the next TB is executed (iff executing in TCG mode).
- */
-void trace_event_set_vcpu_state_dynamic(CPUState *vcpu,
-TraceEvent *ev, bool state);
-
-
-
 /**
  * trace_init_backends:
  *
@@ -205,22 +173,6 @@ bool trace_init_backends(void);
  */
 void trace_init_file(void);
 
-/**
- * trace_init_vcpu:
- * @vcpu: Added vCPU.
- *
- * Set initial dynamic event state for a hot-plugged vCPU.
- */
-void trace_init_vcpu(CPUState *vcpu);
-
-/**
- * trace_fini_vcpu:
- * @vcpu: Removed vCPU.
- *
- * Disable dynamic event state for a hot-unplugged vCPU.
- */
-void trace_fini_vcpu(CPUState *vcpu);
-
 /**
  * trace_list_events:
  * @f: Where to send output.
diff --git a/hw/core/cpu-common.c b/hw/core/cpu-common.c
index 951477a7fd..f4e51c8a1b 100644
--- a/hw/core/cpu-common.c
+++ b/hw/core/cpu-common.c
@@ -211,7 +211,6 @@ static void cpu_common_realizefn(DeviceState *dev, Error 
**errp)
 }
 
 /* NOTE: latest generic point where the cpu is fully realized */
-trace_init_vcpu(cpu);
 }
 
 static void cpu_common_unrealizefn(DeviceState *dev)
@@ -219,7 +218,6 @@ static void cpu_common_unrealizefn(DeviceState *dev)
 CPUState *cpu = CPU(dev);
 
 /* NOTE: latest generic point before the cpu is fully unrealized */
-trace_fini_vcpu(cpu);
 cpu_exec_unrealizefn(cpu);
 }
 
diff --git a/stubs/trace-control.c b/stubs/trace-control.c
index 

[PULL 01/11] *-user: remove the guest_user_syscall tracepoints

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

This is pure duplication now. Both bsd-user and linux-user have
builtin strace support and we can also track syscalls via the plugins
system.

Reviewed-by: Warner Losh 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-2-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-2-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 include/user/syscall-trace.h  |  4 
 bsd-user/freebsd/os-syscall.c |  2 --
 trace-events  | 19 ---
 3 files changed, 25 deletions(-)

diff --git a/include/user/syscall-trace.h b/include/user/syscall-trace.h
index 90bda7631c..557f881a79 100644
--- a/include/user/syscall-trace.h
+++ b/include/user/syscall-trace.h
@@ -26,9 +26,6 @@ static inline void record_syscall_start(void *cpu, int num,
 abi_long arg5, abi_long arg6,
 abi_long arg7, abi_long arg8)
 {
-trace_guest_user_syscall(cpu, num,
- arg1, arg2, arg3, arg4,
- arg5, arg6, arg7, arg8);
 qemu_plugin_vcpu_syscall(cpu, num,
  arg1, arg2, arg3, arg4,
  arg5, arg6, arg7, arg8);
@@ -36,7 +33,6 @@ static inline void record_syscall_start(void *cpu, int num,
 
 static inline void record_syscall_return(void *cpu, int num, abi_long ret)
 {
-trace_guest_user_syscall_ret(cpu, num, ret);
 qemu_plugin_vcpu_syscall_ret(cpu, num, ret);
 }
 
diff --git a/bsd-user/freebsd/os-syscall.c b/bsd-user/freebsd/os-syscall.c
index c8f998ecec..b0ae43766f 100644
--- a/bsd-user/freebsd/os-syscall.c
+++ b/bsd-user/freebsd/os-syscall.c
@@ -531,7 +531,6 @@ abi_long do_freebsd_syscall(void *cpu_env, int num, 
abi_long arg1,
 CPUState *cpu = env_cpu(cpu_env);
 abi_long ret;
 
-trace_guest_user_syscall(cpu, num, arg1, arg2, arg3, arg4, arg5, arg6, 
arg7, arg8);
 if (do_strace) {
 print_freebsd_syscall(num, arg1, arg2, arg3, arg4, arg5, arg6);
 }
@@ -541,7 +540,6 @@ abi_long do_freebsd_syscall(void *cpu_env, int num, 
abi_long arg1,
 if (do_strace) {
 print_freebsd_syscall_ret(num, ret);
 }
-trace_guest_user_syscall_ret(cpu, num, ret);
 
 return ret;
 }
diff --git a/trace-events b/trace-events
index b6b84b175e..691c3533e4 100644
--- a/trace-events
+++ b/trace-events
@@ -85,22 +85,3 @@ vcpu guest_cpu_exit(void)
 # Targets: all
 vcpu guest_cpu_reset(void)
 
-# include/user/syscall-trace.h
-
-# @num: System call number.
-# @arg*: System call argument value.
-#
-# Start executing a guest system call in syscall emulation mode.
-#
-# Mode: user
-# Targets: TCG(all)
-vcpu guest_user_syscall(uint64_t num, uint64_t arg1, uint64_t arg2, uint64_t 
arg3, uint64_t arg4, uint64_t arg5, uint64_t arg6, uint64_t arg7, uint64_t 
arg8) "num=0x%016"PRIx64" arg1=0x%016"PRIx64" arg2=0x%016"PRIx64" 
arg3=0x%016"PRIx64" arg4=0x%016"PRIx64" arg5=0x%016"PRIx64" arg6=0x%016"PRIx64" 
arg7=0x%016"PRIx64" arg8=0x%016"PRIx64
-
-# @num: System call number.
-# @ret: System call result value.
-#
-# Finish executing a guest system call in syscall emulation mode.
-#
-# Mode: user
-# Targets: TCG(all)
-vcpu guest_user_syscall_ret(uint64_t num, uint64_t ret) "num=0x%016"PRIx64" 
ret=0x%016"PRIx64
-- 
2.40.1



[PULL 11/11] accel/tcg: include cs_base in our hash calculations

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

We weren't using cs_base in the hash calculations before. Since the
arm front end moved a chunk of flags in a378206a20 (target/arm: Move
mode specific TB flags to tb->cs_base) they comprise of an important
part of the execution state.

Widen the tb_hash_func to include cs_base and expand to qemu_xxhash8()
to accommodate it.

My initial benchmark shows very little difference in the
runtime.

Before:

armhf

➜  hyperfine -w 2 -m 20 "./arm-softmmu/qemu-system-arm -cpu cortex-a15 -machine 
type=virt,highmem=off -display none -m 2048 -serial mon:stdio -netdev 
user,id=unet,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=unet -device 
virtio-scsi-pci -blockdev 
driver=raw,node-name=hd,discard=unmap,file.driver=host_device,file.filename=/dev/zen-disk/debian-bullseye-armhf
 -device scsi-hd,drive=hd -smp 4 -kernel 
/home/alex/lsrc/linux.git/builds/arm/arch/arm/boot/zImage -append 
'console=ttyAMA0 root=/dev/sda2 systemd.unit=benchmark.service' -snapshot"
Benchmark 1: ./arm-softmmu/qemu-system-arm -cpu cortex-a15 -machine 
type=virt,highmem=off -display none -m 2048 -serial mon:stdio -netdev 
user,id=unet,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=unet -device 
virtio-scsi-pci -blockdev 
driver=raw,node-name=hd,discard=unmap,file.driver=host_device,file.filename=/dev/zen-disk/debian-bullseye-armhf
 -device scsi-hd,drive=hd -smp 4 -kernel 
/home/alex/lsrc/linux.git/builds/arm/arch/arm/boot/zImage -append 
'console=ttyAMA0 root=/dev/sda2 systemd.unit=benchmark.service' -snapshot
  Time (mean ± σ): 24.627 s ±  2.708 s[User: 34.309 s, System: 1.797 s]
  Range (min … max):   22.345 s … 29.864 s20 runs

arm64

➜  hyperfine -w 2 -n 20 "./qemu-system-aarch64 -cpu max,pauth-impdef=on 
-machine type=virt,virtualization=on,gic-version=3 -display none -serial 
mon:stdio -netdev user,id=unet,hostfwd=tcp::-:22,hostfwd=tcp::1234-:1234 
-device virtio-net-pci,netdev=unet -device virtio-scsi-pci -blockdev 
driver=raw,node-name=hd,discard=unmap,file.driver=host_device,file.filename=/dev/zen-disk/debian-bullseye-arm64
 -device scsi-hd,drive=hd -smp 4 -kernel 
~/lsrc/linux.git/builds/arm64/arch/arm64/boot/Image.gz -append 'console=ttyAMA0 
root=/dev/sda2 systemd.unit=benchmark-pigz.service' -snapshot"
Benchmark 1: 20
  Time (mean ± σ): 62.559 s ±  2.917 s[User: 189.115 s, System: 4.089 s]
  Range (min … max):   59.997 s … 70.153 s10 runs

After:

armhf

Benchmark 1: ./arm-softmmu/qemu-system-arm -cpu cortex-a15 -machine 
type=virt,highmem=off -display none -m 2048 -serial mon:stdio -netdev 
user,id=unet,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=unet -device 
virtio-scsi-pci -blockdev 
driver=raw,node-name=hd,discard=unmap,file.driver=host_device,file.filename=/dev/zen-disk/debian-bullseye-armhf
 -device scsi-hd,drive=hd -smp 4 -kernel 
/home/alex/lsrc/linux.git/builds/arm/arch/arm/boot/zImage -append 
'console=ttyAMA0 root=/dev/sda2 systemd.unit=benchmark.service' -snapshot
  Time (mean ± σ): 24.223 s ±  2.151 s[User: 34.284 s, System: 1.906 s]
  Range (min … max):   22.000 s … 28.476 s20 runs

arm64

hyperfine -w 2 -n 20 "./qemu-system-aarch64 -cpu max,pauth-impdef=on -machine 
type=virt,virtualization=on,gic-version=3 -display none -serial mon:stdio 
-netdev user,id=unet,hostfwd=tcp::-:22,hostfwd=tcp::1234-:1234 -device 
virtio-net-pci,netdev=unet -device virtio-scsi-pci -blockdev 
driver=raw,node-name=hd,discard=unmap,file.driver=host_device,file.filename=/dev/zen-disk/debian-bullseye-arm64
 -device scsi-hd,drive=hd -smp 4 -kernel 
~/lsrc/linux.git/builds/arm64/arch/arm64/boot/Image.gz -append 'console=ttyAMA0 
root=/dev/sda2 systemd.unit=benchmark-pigz.service' -snapshot"
Benchmark 1: 20
  Time (mean ± σ): 62.769 s ±  1.978 s[User: 188.431 s, System: 5.269 s]
  Range (min … max):   60.285 s … 66.868 s10 runs

Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Message-id: 20230526165401.574474-12-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-11-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 accel/tcg/tb-hash.h   |  4 ++--
 include/qemu/xxhash.h | 23 +--
 accel/tcg/cpu-exec.c  |  2 +-
 accel/tcg/tb-maint.c  |  4 ++--
 util/qsp.c|  2 +-
 5 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/accel/tcg/tb-hash.h b/accel/tcg/tb-hash.h
index 1d19c69caa..2ba2193731 100644
--- a/accel/tcg/tb-hash.h
+++ b/accel/tcg/tb-hash.h
@@ -62,9 +62,9 @@ static inline unsigned int 
tb_jmp_cache_hash_func(target_ulong pc)
 
 static inline
 uint32_t tb_hash_func(tb_page_addr_t phys_pc, target_ulong pc,
-  uint32_t flags, uint32_t cf_mask)
+  uint32_t flags, uint64_t flags2, uint32_t cf_mask)
 {
-return qemu_xxhash6(phys_pc, pc, flags, cf_mask);
+return qemu_xxhash8(phys_pc, pc, flags2, flags, cf_mask);
 }
 
 #endif
diff --git a/include/qemu/xxhash.h b/include/qemu/xxhash.h
index c2dcccadbf..0259bbef18 100644
--- 

[PULL 10/11] hw/9pfs: use qemu_xxhash4

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

No need to pass zeros as we have helpers that do that for us.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Christian Schoenebeck 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-11-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-10-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 hw/9pfs/9p.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 9621ec1341..991645adca 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -738,15 +738,14 @@ static VariLenAffix affixForIndex(uint64_t index)
 return invertAffix(); /* convert prefix to suffix */
 }
 
-/* creative abuse of tb_hash_func7, which is based on xxhash */
 static uint32_t qpp_hash(QppEntry e)
 {
-return qemu_xxhash7(e.ino_prefix, e.dev, 0, 0, 0);
+return qemu_xxhash4(e.ino_prefix, e.dev);
 }
 
 static uint32_t qpf_hash(QpfEntry e)
 {
-return qemu_xxhash7(e.ino, e.dev, 0, 0, 0);
+return qemu_xxhash4(e.ino, e.dev);
 }
 
 static bool qpd_cmp_func(const void *obj, const void *userp)
-- 
2.40.1



[PULL 06/11] qapi: make the vcpu parameters deprecated for 8.1

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

I don't think I can remove the parameters directly but certainly mark
them as deprecated.

Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-7-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-6-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 docs/about/deprecated.rst |  7 +++
 qapi/trace.json   | 40 +--
 2 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7c45a64363..0743459862 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -226,6 +226,13 @@ QEMU Machine Protocol (QMP) events
 
 Use the more generic event ``DEVICE_UNPLUG_GUEST_ERROR`` instead.
 
+``vcpu`` trace events (since 8.1)
+'
+
+The ability to instrument QEMU helper functions with vCPU-aware trace
+points was removed in 7.0. However QMP still exposed the vcpu
+parameter. This argument has now been deprecated and the remaining
+remaining trace points that used it are selected just by name.
 
 Human Monitor Protocol (HMP) commands
 -
diff --git a/qapi/trace.json b/qapi/trace.json
index 6bf0af0946..39b752fc88 100644
--- a/qapi/trace.json
+++ b/qapi/trace.json
@@ -37,13 +37,14 @@
 #
 # @vcpu: Whether this is a per-vCPU event (since 2.7).
 #
-# An event is per-vCPU if it has the "vcpu" property in the
-# "trace-events" files.
+# Features:
+# @deprecated: Member @vcpu is deprecated, and always ignored.
 #
 # Since: 2.2
 ##
 { 'struct': 'TraceEventInfo',
-  'data': {'name': 'str', 'state': 'TraceEventState', 'vcpu': 'bool'} }
+  'data': {'name': 'str', 'state': 'TraceEventState',
+   'vcpu': { 'type': 'bool', 'features': ['deprecated'] } } }
 
 ##
 # @trace-event-get-state:
@@ -52,19 +53,15 @@
 #
 # @name: Event name pattern (case-sensitive glob).
 #
-# @vcpu: The vCPU to query (any by default; since 2.7).
+# @vcpu: The vCPU to query (since 2.7).
+#
+# Features:
+# @deprecated: Member @vcpu is deprecated, and always ignored.
 #
 # Returns: a list of @TraceEventInfo for the matching events
 #
-# An event is returned if:
-#
-# - its name matches the @name pattern, and
-# - if @vcpu is given, the event has the "vcpu" property.
-#
-# Therefore, if @vcpu is given, the operation will only match per-vCPU
-# events, returning their state on the specified vCPU. Special case:
-# if @name is an exact match, @vcpu is given and the event does not
-# have the "vcpu" property, an error is returned.
+# An event is returned if its name matches the @name pattern
+# (There are no longer any per-vCPU events).
 #
 # Since: 2.2
 #
@@ -75,7 +72,8 @@
 # <- { "return": [ { "name": "qemu_memalign", "state": "disabled", "vcpu": 
false } ] }
 ##
 { 'command': 'trace-event-get-state',
-  'data': {'name': 'str', '*vcpu': 'int'},
+  'data': {'name': 'str',
+   '*vcpu': {'type': 'int', 'features': ['deprecated'] } },
   'returns': ['TraceEventInfo'] }
 
 ##
@@ -91,15 +89,11 @@
 #
 # @vcpu: The vCPU to act upon (all by default; since 2.7).
 #
-# An event's state is modified if:
+# Features:
+# @deprecated: Member @vcpu is deprecated, and always ignored.
 #
-# - its name matches the @name pattern, and
-# - if @vcpu is given, the event has the "vcpu" property.
-#
-# Therefore, if @vcpu is given, the operation will only match per-vCPU
-# events, setting their state on the specified vCPU. Special case: if
-# @name is an exact match, @vcpu is given and the event does not have
-# the "vcpu" property, an error is returned.
+# An event is enabled if its name matches the @name pattern
+# (There are no longer any per-vCPU events).
 #
 # Since: 2.2
 #
@@ -111,4 +105,4 @@
 ##
 { 'command': 'trace-event-set-state',
   'data': {'name': 'str', 'enable': 'bool', '*ignore-unavailable': 'bool',
-   '*vcpu': 'int'} }
+   '*vcpu': {'type': 'int', 'features': ['deprecated'] } } }
-- 
2.40.1



[PULL 04/11] scripts/qapi: document the tool that generated the file

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

This makes it a little easier for developers to find where things
where being generated.

Reviewed-by: Richard Henderson 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Markus Armbruster 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-5-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-5-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 scripts/qapi/gen.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/scripts/qapi/gen.py b/scripts/qapi/gen.py
index 8f8f784f4a..70bc576a10 100644
--- a/scripts/qapi/gen.py
+++ b/scripts/qapi/gen.py
@@ -13,6 +13,7 @@
 
 from contextlib import contextmanager
 import os
+import sys
 import re
 from typing import (
 Dict,
@@ -162,7 +163,7 @@ def __init__(self, fname: str, blurb: str, pydoc: str):
 
 def _top(self) -> str:
 return mcgen('''
-/* AUTOMATICALLY GENERATED, DO NOT MODIFY */
+/* AUTOMATICALLY GENERATED by %(tool)s DO NOT MODIFY */
 
 /*
 %(blurb)s
@@ -174,6 +175,7 @@ def _top(self) -> str:
  */
 
 ''',
+ tool=os.path.basename(sys.argv[0]),
  blurb=self._blurb, copyright=self._copyright)
 
 def _bottom(self) -> str:
@@ -195,7 +197,10 @@ def _bottom(self) -> str:
 
 class QAPIGenTrace(QAPIGen):
 def _top(self) -> str:
-return super()._top() + '# AUTOMATICALLY GENERATED, DO NOT MODIFY\n\n'
+return (super()._top()
++ '# AUTOMATICALLY GENERATED by '
++ os.path.basename(sys.argv[0])
++ ', DO NOT MODIFY\n\n')
 
 
 @contextmanager
-- 
2.40.1



[PULL 03/11] trace: remove vcpu_id from the TraceEvent structure

2023-05-31 Thread Stefan Hajnoczi
From: Alex Bennée 

This does involve temporarily stubbing out some helper functions
before we excise the rest of the code.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-id: 20230526165401.574474-4-alex.ben...@linaro.org
Message-Id: <20230524133952.3971948-4-alex.ben...@linaro.org>
Signed-off-by: Stefan Hajnoczi 
---
 trace/control-internal.h  |  4 ++--
 trace/event-internal.h|  2 --
 trace/control.c   | 10 --
 scripts/tracetool/format/c.py |  6 --
 scripts/tracetool/format/h.py | 11 +--
 5 files changed, 3 insertions(+), 30 deletions(-)

diff --git a/trace/control-internal.h b/trace/control-internal.h
index 8b2b50a7cf..0178121720 100644
--- a/trace/control-internal.h
+++ b/trace/control-internal.h
@@ -27,12 +27,12 @@ static inline uint32_t trace_event_get_id(TraceEvent *ev)
 
 static inline uint32_t trace_event_get_vcpu_id(TraceEvent *ev)
 {
-return ev->vcpu_id;
+return 0;
 }
 
 static inline bool trace_event_is_vcpu(TraceEvent *ev)
 {
-return ev->vcpu_id != TRACE_VCPU_EVENT_NONE;
+return false;
 }
 
 static inline const char * trace_event_get_name(TraceEvent *ev)
diff --git a/trace/event-internal.h b/trace/event-internal.h
index f63500b37e..0c24e01b52 100644
--- a/trace/event-internal.h
+++ b/trace/event-internal.h
@@ -19,7 +19,6 @@
 /**
  * TraceEvent:
  * @id: Unique event identifier.
- * @vcpu_id: Unique per-vCPU event identifier.
  * @name: Event name.
  * @sstate: Static tracing state.
  * @dstate: Dynamic tracing state
@@ -33,7 +32,6 @@
  */
 typedef struct TraceEvent {
 uint32_t id;
-uint32_t vcpu_id;
 const char * name;
 const bool sstate;
 uint16_t *dstate;
diff --git a/trace/control.c b/trace/control.c
index d24af91004..5dfb609954 100644
--- a/trace/control.c
+++ b/trace/control.c
@@ -68,16 +68,6 @@ void trace_event_register_group(TraceEvent **events)
 size_t i;
 for (i = 0; events[i] != NULL; i++) {
 events[i]->id = next_id++;
-if (events[i]->vcpu_id == TRACE_VCPU_EVENT_NONE) {
-continue;
-}
-
-if (likely(next_vcpu_id < CPU_TRACE_DSTATE_MAX_EVENTS)) {
-events[i]->vcpu_id = next_vcpu_id++;
-} else {
-warn_report("too many vcpu trace events; dropping '%s'",
-events[i]->name);
-}
 }
 event_groups = g_renew(TraceEventGroup, event_groups, nevent_groups + 1);
 event_groups[nevent_groups].events = events;
diff --git a/scripts/tracetool/format/c.py b/scripts/tracetool/format/c.py
index c390c1844a..69edf0d588 100644
--- a/scripts/tracetool/format/c.py
+++ b/scripts/tracetool/format/c.py
@@ -32,19 +32,13 @@ def generate(events, backend, group):
 out('uint16_t %s;' % e.api(e.QEMU_DSTATE))
 
 for e in events:
-if "vcpu" in e.properties:
-vcpu_id = 0
-else:
-vcpu_id = "TRACE_VCPU_EVENT_NONE"
 out('TraceEvent %(event)s = {',
 '.id = 0,',
-'.vcpu_id = %(vcpu_id)s,',
 '.name = \"%(name)s\",',
 '.sstate = %(sstate)s,',
 '.dstate = &%(dstate)s ',
 '};',
 event = e.api(e.QEMU_EVENT),
-vcpu_id = vcpu_id,
 name = e.name,
 sstate = "TRACE_%s_ENABLED" % e.name.upper(),
 dstate = e.api(e.QEMU_DSTATE))
diff --git a/scripts/tracetool/format/h.py b/scripts/tracetool/format/h.py
index e94f0be7da..285d7b03a9 100644
--- a/scripts/tracetool/format/h.py
+++ b/scripts/tracetool/format/h.py
@@ -74,16 +74,7 @@ def generate(events, backend, group):
 
 out('}')
 
-# tracer wrapper with checks (per-vCPU tracing)
-if "vcpu" in e.properties:
-trace_cpu = next(iter(e.args))[1]
-cond = "trace_event_get_vcpu_state(%(cpu)s,"\
-   " TRACE_%(id)s)"\
-   % dict(
-   cpu=trace_cpu,
-   id=e.name.upper())
-else:
-cond = "true"
+cond = "true"
 
 out('',
 'static inline void %(api)s(%(args)s)',
-- 
2.40.1



[PULL 00/11] Tracing patches

2023-05-31 Thread Stefan Hajnoczi
The following changes since commit 51bdb0b57a2d9e84d6915fbae7b5d76c8820cf3c:

  Merge tag 'pull-tcg-20230530' of https://gitlab.com/rth7680/qemu into staging 
(2023-05-30 13:25:18 -0700)

are available in the Git repository at:

  https://gitlab.com/stefanha/qemu.git tags/tracing-pull-request

for you to fetch changes up to 2e7eda52e5ea2f066b37ecd9fdb5983851eabbbf:

  accel/tcg: include cs_base in our hash calculations (2023-05-31 13:21:53 
-0400)


Pull request



Alex Bennée (11):
  *-user: remove the guest_user_syscall tracepoints
  trace-events: remove the remaining vcpu trace events
  trace: remove vcpu_id from the TraceEvent structure
  scripts/qapi: document the tool that generated the file
  docs/deprecated: move QMP events bellow QMP command section
  qapi: make the vcpu parameters deprecated for 8.1
  trace: remove code that depends on setting vcpu
  trace: remove control-vcpu.h
  tcg: remove the final vestiges of dstate
  hw/9pfs: use qemu_xxhash4
  accel/tcg: include cs_base in our hash calculations

 docs/about/deprecated.rst |  25 +---
 qapi/trace.json   |  40 ++---
 accel/tcg/tb-hash.h   |   6 +-
 include/exec/exec-all.h   |   3 -
 include/hw/core/cpu.h |   5 --
 include/qemu/xxhash.h |  23 +--
 include/user/syscall-trace.h  |   4 --
 trace/control-internal.h  |  10 
 trace/control-vcpu.h  |  63 
 trace/control.h   |  48 ---
 trace/event-internal.h|   2 -
 accel/tcg/cpu-exec.c  |   7 +--
 accel/tcg/tb-maint.c  |   5 +-
 accel/tcg/translate-all.c |   6 --
 bsd-user/freebsd/os-syscall.c |   2 -
 hw/9pfs/9p.c  |   5 +-
 hw/core/cpu-common.c  |   6 +-
 stubs/trace-control.c |  13 
 trace/control-target.c| 109 +++---
 trace/control.c   |  28 -
 trace/qmp.c   |  76 +++-
 trace/trace-hmp-cmds.c|  18 +-
 util/qsp.c|   2 +-
 hw/core/trace-events  |   3 +
 scripts/qapi/gen.py   |   9 ++-
 scripts/tracetool/format/c.py |   6 --
 scripts/tracetool/format/h.py |  16 +
 trace-events  |  50 
 28 files changed, 94 insertions(+), 496 deletions(-)
 delete mode 100644 trace/control-vcpu.h

-- 
2.40.1



[libvirt PATCHv3 for 9.4.0] conf: node_device: use separate variables for parsing integers

2023-05-31 Thread Ján Tomko
In virNodeDeviceGetSCSIHostCaps, there is a pattern of reusing
a tmp value and stealing the pointer.

But in two case it is not stolen. Use separate variables for them
to avoid mixing autofree with manual free() calls.

This fixes the memory leak of the "max_npiv_vports" string.
(The other gets freed anyway because it was the last use of "tmp"
 in the function")

Fixes: 8a0cb5f73ade3900546718eabe70cb064c6bd22c
Signed-off-by: Ján Tomko 
---
v3: fix "declaration after statement" warning
 src/conf/node_device_conf.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index fcee9c027c..172223225f 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -2857,29 +2857,32 @@ virNodeDeviceGetSCSIHostCaps(virNodeDevCapSCSIHost 
*scsi_host)
 }
 
 if (virVHBAIsVportCapable(NULL, scsi_host->host)) {
+g_autofree char *max_vports = NULL;
+g_autofree char *vports = NULL;
+
 scsi_host->flags |= VIR_NODE_DEV_CAP_FLAG_HBA_VPORT_OPS;
 
-if (!(tmp = virVHBAGetConfig(NULL, scsi_host->host,
+if (!(max_vports = virVHBAGetConfig(NULL, scsi_host->host,
  "max_npiv_vports"))) {
 VIR_WARN("Failed to read max_npiv_vports for host%d",
  scsi_host->host);
 goto cleanup;
 }
 
-if (virStrToLong_i(tmp, NULL, 10, _host->max_vports) < 0) {
-VIR_WARN("Failed to parse value of max_npiv_vports '%s'", tmp);
+if (virStrToLong_i(max_vports, NULL, 10, _host->max_vports) < 0) {
+VIR_WARN("Failed to parse value of max_npiv_vports '%s'", 
max_vports);
 goto cleanup;
 }
 
-if (!(tmp = virVHBAGetConfig(NULL, scsi_host->host,
+if (!(vports = virVHBAGetConfig(NULL, scsi_host->host,
   "npiv_vports_inuse"))) {
 VIR_WARN("Failed to read npiv_vports_inuse for host%d",
  scsi_host->host);
 goto cleanup;
 }
 
-if (virStrToLong_i(tmp, NULL, 10, _host->vports) < 0) {
-VIR_WARN("Failed to parse value of npiv_vports_inuse '%s'", tmp);
+if (virStrToLong_i(vports, NULL, 10, _host->vports) < 0) {
+VIR_WARN("Failed to parse value of npiv_vports_inuse '%s'", 
vports);
 goto cleanup;
 }
 }
-- 
2.40.1



Re: [PATCH v2] util: basic support for VFIO variant drivers

2023-05-31 Thread Jason Gunthorpe
On Wed, May 31, 2023 at 01:18:44PM -0400, Laine Stump wrote:
> On 5/31/23 10:31 AM, Jason Gunthorpe wrote:
> > On Wed, May 31, 2023 at 03:18:17PM +0100, Joao Martins wrote:
> > > Hey Laine,
> > > 
> > > On 23/08/2022 15:11, Laine Stump wrote:
> > > > ping.
> > > > 
> > > > I have a different version of this patch where I do read the 
> > > > modules.alias file
> > > > rather than just checking the name of the driver, but that also 
> > > > requires "double
> > > > mocking" open() in the unit test, which wasn't working properly, and 
> > > > I'd rather
> > > > not spend the time figuring it out if it's not going to be needed. 
> > > > (Alex prefers
> > > > that version because it is more correct than just checking the name, 
> > > > and he's
> > > > concerned that the new sysfs-based API may take longer than we're 
> > > > thinking to
> > > > get into downstream distros, but the version in this patch does satisfy 
> > > > both
> > > > Jason and Daniel's suggested implementations). Anyway, I can post the 
> > > > other
> > > > patch if anyone is interested.
> > > > 
> > > [sorry for the thread necromancy]
> 
> Heh. I had actually dug out this same thread last week and started a mail to
> ask Jason if the planned sysfs stuff had ever been pushed, but then forgot
> to hit "send" :-)
> 
> Now that there are multiple vfio variant drivers available (for igb, e1000e,
> and mlx5 that I know of),

Oh I haven't seen those intel ones posted yet?

> Jason, can you point me at the information for this patch in an ELI5 manner
> for a non-kernel person? (including what upstream kernel it's in, and what
> it is that I need to look at to determine if a driver is a vfio
> variant).

It is this patch:

commit 3c28a76124b25882411f005924be73795b6ef078
Author: Yi Liu 
Date:   Wed Sep 21 18:44:01 2022 +0800

vfio: Add struct device to vfio_device

and replace kref. With it a 'vfio-dev/vfioX' node is created under the
sysfs path of the parent, indicating the device is bound to a vfio
driver, e.g.:

/sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0

It is also a preparatory step toward adding cdev for supporting future
device-oriented uAPI.

Add Documentation/ABI/testing/sysfs-devices-vfio-dev.

Suggested-by: Jason Gunthorpe 
Signed-off-by: Yi Liu 
Signed-off-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Link: https://lore.kernel.org/r/20220921104401.38898-16-kevin.t...@intel.com
Signed-off-by: Alex Williamson 

$ git describe --contains 3c28a76124b25882411f005924be73795b6ef078
v6.1-rc1~42^2~35

So it is in v6.1-rc1

libvirt should start thinking about determining the vfioX number for
the device, we will need that for iommufd enablement eventually

so, stat for a directory like this:

/sys/devices/pci\:6f/\:6f\:01.0/vfio-dev

Confirms vfio

Then scan it to get 'vfioX' which will eventually be the /dev/ node
libvirt will have to open.

And the other part is something in the stack should use the modalias
mechanism to find load and bind the correct variant driver.

Jason



Re: [PATCH v6 00/11] tracing: remove dynamic vcpu state

2023-05-31 Thread Stefan Hajnoczi
On Fri, May 26, 2023 at 05:53:50PM +0100, Alex Bennée wrote:
> Hi Stefan,
> 
> The references dynamic vcpu tracing support was removed when the
> original TCG trace points where removed. However there was still a
> legacy of dynamic trace state to track this in cpu.h and extra hash
> variables to track TBs. While the removed vcpu tracepoints are not in
> generated code (or helpers) they still bring in a bunch of machinery
> to manage the state so I've pulled them out. We keep and rename one
> (cpu_reset) to a static trace points which dump vcpu->index as it is
> useful to f4bug.
> 
> v6 new patch to shuffle deprecated, added rth's rb, qapi doc cleanups
> 
> Please queue into your tree.
> 
> Alex Bennée (11):
>   *-user: remove the guest_user_syscall tracepoints
>   trace-events: remove the remaining vcpu trace events
>   trace: remove vcpu_id from the TraceEvent structure
>   scripts/qapi: document the tool that generated the file
>   docs/deprecated: move QMP events bellow QMP command section
>   qapi: make the vcpu parameters deprecated for 8.1
>   trace: remove code that depends on setting vcpu
>   trace: remove control-vcpu.h
>   tcg: remove the final vestiges of dstate
>   hw/9pfs: use qemu_xxhash4
>   accel/tcg: include cs_base in our hash calculations
> 
>  docs/about/deprecated.rst |  25 +---
>  qapi/trace.json   |  40 ++---
>  accel/tcg/tb-hash.h   |   6 +-
>  include/exec/exec-all.h   |   3 -
>  include/hw/core/cpu.h |   5 --
>  include/qemu/xxhash.h |  23 +--
>  include/user/syscall-trace.h  |   4 --
>  trace/control-internal.h  |  10 
>  trace/control-vcpu.h  |  63 
>  trace/control.h   |  48 ---
>  trace/event-internal.h|   2 -
>  accel/tcg/cpu-exec.c  |   7 +--
>  accel/tcg/tb-maint.c  |   5 +-
>  accel/tcg/translate-all.c |   6 --
>  bsd-user/freebsd/os-syscall.c |   2 -
>  hw/9pfs/9p.c  |   5 +-
>  hw/core/cpu-common.c  |   6 +-
>  stubs/trace-control.c |  13 
>  trace/control-target.c| 109 +++---
>  trace/control.c   |  28 -
>  trace/qmp.c   |  76 +++-
>  trace/trace-hmp-cmds.c|  18 +-
>  util/qsp.c|   2 +-
>  hw/core/trace-events  |   3 +
>  scripts/qapi/gen.py   |   9 ++-
>  scripts/tracetool/format/c.py |   6 --
>  scripts/tracetool/format/h.py |  16 +
>  trace-events  |  50 
>  28 files changed, 94 insertions(+), 496 deletions(-)
>  delete mode 100644 trace/control-vcpu.h
> 
> -- 
> 2.39.2
> 

Thanks, applied to my tracing tree:
https://gitlab.com/stefanha/qemu/commits/tracing

Stefan


signature.asc
Description: PGP signature


Re: [PATCH for 9.4.0] include: Fix 'Since' for new VIR_MIGRATE_PARAM_COMPRESSION_* macros

2023-05-31 Thread Andrea Bolognani
On Wed, May 31, 2023 at 11:02:21AM +0200, Michal Privoznik wrote:
> In v9.3.0-98-g150ae3e62b two new macros were introduced:
> VIR_MIGRATE_PARAM_COMPRESSION_ZLIB_LEVEL and
> VIR_MIGRATE_PARAM_COMPRESSION_ZSTD_LEVEL. But both list 9.1.0 as
> the version they were introduced in (this is because the patch
> was sent in that release time frame). Change the version to the
> current release.
>
> Signed-off-by: Michal Privoznik 
> ---
>  include/libvirt/libvirt-domain.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Andrea Bolognani 

and pushed.

-- 
Andrea Bolognani / Red Hat / Virtualization



Re: [libvirt PATCH] ci: refresh with latest lcitool manifest

2023-05-31 Thread Andrea Bolognani
On Wed, May 31, 2023 at 11:37:01AM +0200, Erik Skultety wrote:
> Adds Alpine 3.17 and 3.18 targets.

I only see Alpine 3.17 being added, and Alpine 3.15 being removed. If
that was the intention, then the commit message needs to express that
more clearly...

-- 
Andrea Bolognani / Red Hat / Virtualization



Re: [PATCH v6 05/11] docs/deprecated: move QMP events bellow QMP command section

2023-05-31 Thread Stefan Hajnoczi
On Fri, May 26, 2023 at 05:53:55PM +0100, Alex Bennée wrote:
> Also rename the section to make the fact this is part of the
> management protocol even clearer.
> 
> Suggested-by: Markus Armbruster 
> Signed-off-by: Alex Bennée 
> ---
>  docs/about/deprecated.rst | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [PATCH v2] util: basic support for VFIO variant drivers

2023-05-31 Thread Laine Stump

On 5/31/23 10:31 AM, Jason Gunthorpe wrote:

On Wed, May 31, 2023 at 03:18:17PM +0100, Joao Martins wrote:

Hey Laine,

On 23/08/2022 15:11, Laine Stump wrote:

ping.

I have a different version of this patch where I do read the modules.alias file
rather than just checking the name of the driver, but that also requires "double
mocking" open() in the unit test, which wasn't working properly, and I'd rather
not spend the time figuring it out if it's not going to be needed. (Alex prefers
that version because it is more correct than just checking the name, and he's
concerned that the new sysfs-based API may take longer than we're thinking to
get into downstream distros, but the version in this patch does satisfy both
Jason and Daniel's suggested implementations). Anyway, I can post the other
patch if anyone is interested.


[sorry for the thread necromancy]


Heh. I had actually dug out this same thread last week and started a 
mail to ask Jason if the planned sysfs stuff had ever been pushed, but 
then forgot to hit "send" :-)


Now that there are multiple vfio variant drivers available (for igb, 
e1000e, and mlx5 that I know of), it's getting more important to have 
them usable with libvirt, so I'm hoping to update this patch to use 
sysfs to determine if the driver is a vfio variant




I was wondering if you're planning on respinning this work, or rather the
modalias approach alternative you mention? Or perhaps we are waiting for the
cdev sysfs? Though, there's still a significant amount of kernel versions to
cover that won't have the sysfs entry sadly :(


The cdev sysfs has been merged to the kernel now


Jason, can you point me at the information for this patch in an ELI5 
manner for a non-kernel person? (including what upstream kernel it's in, 
and what it is that I need to look at to determine if a driver is a vfio 
variant). Thanks!




Re: [PATCH v4] vfio/pci: Propagate ACPI notifications to user-space via eventfd

2023-05-31 Thread Grzegorz Jaszczyk
czw., 25 maj 2023 o 22:41 Alex Williamson 
napisał(a):
>
> On Mon, 22 May 2023 16:58:11 +
> Grzegorz Jaszczyk  wrote:
>
> > To allow pass-through devices receiving ACPI notifications, permit to
> > register ACPI notify handler (via VFIO_DEVICE_SET_IRQS) for a given
> > device. The handler role is to receive and propagate such ACPI
> > notifications to the user-space through the user provided eventfd. This
> > allows VMM to receive and propagate them further to the VM, where the
> > actual driver for pass-through device resides and can react to device
> > specific notifications accordingly.
> >
> > The eventfd usage ensures VMM and device isolation: it allows to use a
> > dedicated channel associated with the device for such events, such that
> > the VMM has direct access.
> >
> > Since the eventfd counter is used as ACPI notification value
> > placeholder, the eventfd signaling needs to be serialized in order to
> > not end up with notification values being coalesced. Therefore ACPI
> > notification values are buffered and signalized one by one, when the
> > previous notification value has been consumed.
> >
> > Signed-off-by: Grzegorz Jaszczyk 
> > ---
> > Changelog v3..v4
> > Address Alex Williamson feedback:
> > - Instead of introducing new ioctl used for eventfd registration, take
> >   advantage of VFIO_DEVICE_SET_IRQS which already supports virtual IRQs
> >   for things like error notification and device release requests.
> > - Introduced mechanism preventing creation of large queues.
> > Other:
> > - Move the implementation into the newly introduced VFIO_ACPI_NOTIFY
> >   helper module. It is actually not bound to VFIO_PCI but VFIO_PCI
> >   enables it whenever ACPI support is enabled. This change is introduced
> >   since ACPI notifications are not limited to PCI devices, making it PCI
> >   independent will allow to re-use it also for other VFIO_* like
> >   supports: e.g. VFIO_PLATFORM in the future if needed. Moving it out of
> >   drivers/vfio/pci/ was also suggested offline.
>
> We don't require a separate module for such re-use, see for instance
> vfio's virqfd code, which was previously a helper module like this but
> the argument for e2d55709398e ("vfio: Fold vfio_virqfd.ko into
> vfio.ko") was that the code size doesn't warrant a separate module and
> we can still optionally include it as part of vfio.ko via Kconfig.

Ok

>
> > - s/notify_val_next/node
> > - v3: 
> > https://patchwork.kernel.org/project/kvm/patch/20230502132700.654528-1-jaszc...@google.com/
> >
> > Changelog v2..v3:
> > - Fix compilation warnings when building with "W=1"
> >
> > Changelog v1..v2:
> > - The v2 implementation is actually completely different then v1:
> >   instead of using acpi netlink events for propagating ACPI
> >   notifications to the user space take advantage of eventfd, which can
> >   provide better VMM and device isolation: it allows to use a dedicated
> >   channel associated with the device for such events, such that the VMM
> >   has direct access.
> > - Using eventfd counter as notification value placeholder was suggested
> >   in v1 and requires additional serialization logic introduced in v2.
> > - Since the vfio-pci supports non-ACPI platforms address !CONFIG_ACPI
> >   case.
> > - v1 discussion: 
> > https://patchwork.kernel.org/project/kvm/patch/20230307220553.631069-1-...@semihalf.com/
> > ---
> > ---
> >  drivers/vfio/Kconfig  |   5 +
> >  drivers/vfio/Makefile |   1 +
> >  drivers/vfio/pci/Kconfig  |   1 +
> >  drivers/vfio/pci/vfio_pci_core.c  |   9 ++
> >  drivers/vfio/pci/vfio_pci_intrs.c |  73 ++
> >  drivers/vfio/vfio_acpi_notify.c   | 219 ++
> >  include/linux/vfio_acpi_notify.h  |  40 ++
> >  include/linux/vfio_pci_core.h |   1 +
> >  include/uapi/linux/vfio.h |   1 +
> >  9 files changed, 350 insertions(+)
> >  create mode 100644 drivers/vfio/vfio_acpi_notify.c
> >  create mode 100644 include/linux/vfio_acpi_notify.h
> >
> > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> > index 89e06c981e43..7822b0d8e7b1 100644
> > --- a/drivers/vfio/Kconfig
> > +++ b/drivers/vfio/Kconfig
> > @@ -12,6 +12,11 @@ menuconfig VFIO
> > If you don't know what to do here, say N.
> >
> >  if VFIO
> > +config VFIO_ACPI_NOTIFY
> > + tristate
> > + depends on ACPI
> > + default n
> > +
> >  config VFIO_CONTAINER
> >   bool "Support for the VFIO container /dev/vfio/vfio"
> >   select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
> > diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> > index 70e7dcb302ef..129c121b503d 100644
> > --- a/drivers/vfio/Makefile
> > +++ b/drivers/vfio/Makefile
> > @@ -14,3 +14,4 @@ obj-$(CONFIG_VFIO_PCI) += pci/
> >  obj-$(CONFIG_VFIO_PLATFORM) += platform/
> >  obj-$(CONFIG_VFIO_MDEV) += mdev/
> >  obj-$(CONFIG_VFIO_FSL_MC) += fsl-mc/
> > +obj-$(CONFIG_VFIO_ACPI_NOTIFY) += vfio_acpi_notify.o
>
> Given complaints by Linus about 

Re: [PATCH v2] util: basic support for VFIO variant drivers

2023-05-31 Thread Joao Martins
On 31/05/2023 15:31, Jason Gunthorpe wrote:
> On Wed, May 31, 2023 at 03:18:17PM +0100, Joao Martins wrote:
>> Hey Laine,
>>
>> On 23/08/2022 15:11, Laine Stump wrote:
>>> ping.
>>>
>>> I have a different version of this patch where I do read the modules.alias 
>>> file
>>> rather than just checking the name of the driver, but that also requires 
>>> "double
>>> mocking" open() in the unit test, which wasn't working properly, and I'd 
>>> rather
>>> not spend the time figuring it out if it's not going to be needed. (Alex 
>>> prefers
>>> that version because it is more correct than just checking the name, and 
>>> he's
>>> concerned that the new sysfs-based API may take longer than we're thinking 
>>> to
>>> get into downstream distros, but the version in this patch does satisfy both
>>> Jason and Daniel's suggested implementations). Anyway, I can post the other
>>> patch if anyone is interested.
>>>
>> [sorry for the thread necromancy]
>>
>> I was wondering if you're planning on respinning this work, or rather the
>> modalias approach alternative you mention? Or perhaps we are waiting for the
>> cdev sysfs? Though, there's still a significant amount of kernel versions to
>> cover that won't have the sysfs entry sadly :(
> 
> The cdev sysfs has been merged to the kernel now

Ugh, I got confused with something else enterily. Yes, it's there since commit
3c28a76124b258 ("vfio: Add struct device to vfio_device"), v6.1 essentially;



[PATCH 2/4] docs: page.xsl: Drop passhrough of

2023-05-31 Thread Peter Krempa
No generated headers have inline javascript.

Signed-off-by: Peter Krempa 
---
 docs/page.xsl | 1 -
 1 file changed, 1 deletion(-)

diff --git a/docs/page.xsl b/docs/page.xsl
index c92ceffec7..e3112fc9f8 100644
--- a/docs/page.xsl
+++ b/docs/page.xsl
@@ -56,7 +56,6 @@
 
   https://gitlab.com/libvirt/libvirt-go-xml-module.git"/>
 
-

 

[PATCH 0/4] docs: Move 'golang' metadata headers into rST files and further XSL cleanups

2023-05-31 Thread Peter Krempa
Pipeline:
https://gitlab.com/pipo.sk/libvirt/-/jobs/4385932520

Impacted HTML files from pipeline:
https://pipo.sk.gitlab.io/-/libvirt/-/jobs/4385932520/artifacts/website/libvirt-go.html
https://pipo.sk.gitlab.io/-/libvirt/-/jobs/4385932520/artifacts/website/libvirt-go-xml.html
https://pipo.sk.gitlab.io/-/libvirt/-/jobs/4385932520/artifacts/website/go/libvirtxml.html
https://pipo.sk.gitlab.io/-/libvirt/-/jobs/4385932520/artifacts/website/go/libvirt.html

Peter Krempa (4):
  docs: newapi: Remove unused 'docomponents' template
  docs: page.xsl: Drop passhrough of 

[PATCH 3/4] docs: go: Add 'go-import' metadata via rST

2023-05-31 Thread Peter Krempa
The '.. meta::' rST directive allows adding header metadata. Move the
specific metadata from page.xsl into the individual files and pass them
trhough into the header from page.xsl.

Signed-off-by: Peter Krempa 
---
 docs/go/libvirt.rst |  3 +++
 docs/go/libvirtxml.rst  |  3 +++
 docs/libvirt-go-xml.rst |  3 +++
 docs/libvirt-go.rst |  3 +++
 docs/page.xsl   | 13 ++---
 5 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/docs/go/libvirt.rst b/docs/go/libvirt.rst
index 6a1344ad3e..09eaa66714 100644
--- a/docs/go/libvirt.rst
+++ b/docs/go/libvirt.rst
@@ -1,3 +1,6 @@
+.. meta::
+   :go-import: libvirt.org/go/libvirt git 
https://gitlab.com/libvirt/libvirt-go-module.git
+
 =
 Libvirt Go Language API (with Go modules)
 =
diff --git a/docs/go/libvirtxml.rst b/docs/go/libvirtxml.rst
index 5407d609f2..315499da1a 100644
--- a/docs/go/libvirtxml.rst
+++ b/docs/go/libvirtxml.rst
@@ -1,3 +1,6 @@
+.. meta::
+   :go-import: libvirt.org/go/libvirtxml git 
https://gitlab.com/libvirt/libvirt-go-xml-module.git
+
 
 Libvirt Go XML parsing API (with Go modules)
 
diff --git a/docs/libvirt-go-xml.rst b/docs/libvirt-go-xml.rst
index d2a488d99d..822dc73638 100644
--- a/docs/libvirt-go-xml.rst
+++ b/docs/libvirt-go-xml.rst
@@ -1,3 +1,6 @@
+.. meta::
+   :go-import: libvirt.org/libvirt-go-xml git 
https://gitlab.com/libvirt/libvirt-go-xml.git
+
 ===
 Obsolete libvirt Go XML parsing API (no Go modules)
 ===
diff --git a/docs/libvirt-go.rst b/docs/libvirt-go.rst
index 85ee3191b5..60ec9fbbb2 100644
--- a/docs/libvirt-go.rst
+++ b/docs/libvirt-go.rst
@@ -1,3 +1,6 @@
+.. meta::
+   :go-import: libvirt.org/libvirt-go git 
https://gitlab.com/libvirt/libvirt-go.git
+
 
 Obsolete libvirt Go Language API (no Go modules)
 
diff --git a/docs/page.xsl b/docs/page.xsl
index e3112fc9f8..27607e4d92 100644
--- a/docs/page.xsl
+++ b/docs/page.xsl
@@ -44,17 +44,8 @@
 
 libvirt: 
 
-
-  https://gitlab.com/libvirt/libvirt-go.git"/>
-
-
-  https://gitlab.com/libvirt/libvirt-go-xml.git"/>
-
-
-  https://gitlab.com/libvirt/libvirt-go-module.git"/>
-
-
-  https://gitlab.com/libvirt/libvirt-go-xml-module.git"/>
+
+
 

 

[PATCH 4/4] docs: Use '--exit-status=' option for 'rst2html5'

2023-05-31 Thread Peter Krempa
Ensure that also 'non-halting' messages stop the build process.

Signed-off-by: Peter Krempa 
---
 docs/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/meson.build b/docs/meson.build
index 2f0ecb2272..201fd4c984 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -210,7 +210,7 @@ endif
 docs_rst2html5_gen = generator(
   rst2html5_prog,
   output: '@basen...@.html.in',
-  arguments: [ '--stylesheet=', '--strict', '@INPUT@' ],
+  arguments: [ '--exit-status=1', '--stylesheet=', '--strict', '@INPUT@' ],
   capture: true,
 )

-- 
2.40.1



Re: [PATCH v2] util: basic support for VFIO variant drivers

2023-05-31 Thread Joao Martins
Hey Laine,

On 23/08/2022 15:11, Laine Stump wrote:
> ping.
> 
> I have a different version of this patch where I do read the modules.alias 
> file
> rather than just checking the name of the driver, but that also requires 
> "double
> mocking" open() in the unit test, which wasn't working properly, and I'd 
> rather
> not spend the time figuring it out if it's not going to be needed. (Alex 
> prefers
> that version because it is more correct than just checking the name, and he's
> concerned that the new sysfs-based API may take longer than we're thinking to
> get into downstream distros, but the version in this patch does satisfy both
> Jason and Daniel's suggested implementations). Anyway, I can post the other
> patch if anyone is interested.
> 
[sorry for the thread necromancy]

I was wondering if you're planning on respinning this work, or rather the
modalias approach alternative you mention? Or perhaps we are waiting for the
cdev sysfs? Though, there's still a significant amount of kernel versions to
cover that won't have the sysfs entry sadly :(

> On 8/11/22 1:00 AM, Laine Stump wrote:
>> Before a PCI device can be assigned to a guest with VFIO, that device
>> must be bound to the vfio-pci driver rather than to the device's
>> normal driver. The vfio-pci driver provides APIs that permit QEMU to
>> perform all the necessary operations to make the device accessible to
>> the guest.
>>
>> There has been kernel work recently to support vendor/device-specific
>> VFIO variant drivers that provide the basic vfio-pci driver functionality
>> while adding support for device-specific operations (for example these
>> device-specific drivers are planned to support live migration of
>> certain devices). All that will be needed to make this functionality
>> available will be to bind the new vendor-specific driver to the device
>> (rather than the generic vfio-pci driver, which will continue to work
>> just without the extra functionality).
>>
>> But until now libvirt has required that all PCI devices being assigned
>> to a guest with VFIO specifically have the "vfio-pci" driver bound to
>> the device. So even if the user manually binds a shiny new
>> vendor-specific vfio variant driver to the device (and puts
>> "managed='no'" in the config to prevent libvirt from changing the
>> binding), libvirt will just fail during startup of the guest (or
>> during hotplug) because the driver bound to the device isn't exactly
>> "vfio-pci".
>>
>> This patch loosens that restriction a bit - rather than requiring that
>> the device be bound to "vfio-pci", it also checks if the drivername
>> contains the string "vfio" at all, and in this case allows the
>> operation to continue. If the driver is in fact a VFIO variant, then
>> the assignment will succeed, but if it is not a VFIO variant then QEMU
>> will fail (and report the error back to libvirt).
>>
>> In the near future (possibly by kernel 6.0) there will be a
>> formal method of identifying a VFIO variant driver by looking in
>> sysfs; in the meantime the inexact, but simple, method in this patch
>> will allow users of the few existing VFIO variant drivers (and
>> developers of new VFIO variant drivers) to use their new drivers
>> without needing to remove libvirt from their setup - they can simply
>> pre-bind the device to the new driver, then use "managed='no'" in
>> their libvirt config.
>>
>> NB: this patch does *not* handle automatically determining the proper
>> vendor-specific driver and binding to it in the case of
>> "managed='yes'". This will be implemented later when there is a widely
>> available driver / device combo we can use for testing.
>>
>> Signed-off-by: Laine Stump 
>> ---
>> V1 here: 
>> https://listman.redhat.com/archives/libvir-list/2022-August/233327.html
>>
>> Change in V2:
>>
>> V1 used the output of modinfo to look for "vfio_pci" as an alias for a
>> driver to see if it was a VFIO variant driver.
>>
>> As a result of discussion of V1, V2 is much simpler - it just assumes
>> that any driver with "vfio" in the name is a VFIO variant. This is
>> okay because 1) QEMU will still catch it and libvirt will properly log
>> the error if the driver isn't actually a VFIO variant, and 2) it's a
>> temporary situation, just to enable use of VFIO variant drivers with
>> libvirt until a standard method of detecting this is added to sysfs
>> (which, according to the discussion of V1, is coming in the near
>> future).
>>
>> (NB: I did implement checking of /lib/modules/`uname -r`/modules.alias
>> as suggested by Erik, but it turned out that this caused the unit
>> tests to call uname(3) and open the modules.alias file on the test
>> host - for a proper unit test I would have also needed to mock these
>> two functions, and it seemed like too much complexity for a temporary
>> workaround. I've implemented Jason's suggestion here (accept any
>> driver with "vfio" in the name), which is similar to danpb's
>> suggestion (accept specifically the two drivers that are 

[PATCH 1/4] docs: newapi: Remove unused 'docomponents' template

2023-05-31 Thread Peter Krempa
Never used since introduction in b38893c3eaa56617a3ef313c45e505da6e50

Signed-off-by: Peter Krempa 
---
 docs/newapi.xsl | 18 --
 1 file changed, 18 deletions(-)

diff --git a/docs/newapi.xsl b/docs/newapi.xsl
index cafe49f61f..19a440bb09 100644
--- a/docs/newapi.xsl
+++ b/docs/newapi.xsl
@@ -733,24 +733,6 @@
 
   

-  
-
-  
-
-
-  
-
-
-  
-
-
-  
-
-
-  
-
-  
-
   
 
 Module  from 

-- 
2.40.1



Re: [PATCH v2] util: basic support for VFIO variant drivers

2023-05-31 Thread Jason Gunthorpe
On Wed, May 31, 2023 at 03:18:17PM +0100, Joao Martins wrote:
> Hey Laine,
> 
> On 23/08/2022 15:11, Laine Stump wrote:
> > ping.
> > 
> > I have a different version of this patch where I do read the modules.alias 
> > file
> > rather than just checking the name of the driver, but that also requires 
> > "double
> > mocking" open() in the unit test, which wasn't working properly, and I'd 
> > rather
> > not spend the time figuring it out if it's not going to be needed. (Alex 
> > prefers
> > that version because it is more correct than just checking the name, and 
> > he's
> > concerned that the new sysfs-based API may take longer than we're thinking 
> > to
> > get into downstream distros, but the version in this patch does satisfy both
> > Jason and Daniel's suggested implementations). Anyway, I can post the other
> > patch if anyone is interested.
> > 
> [sorry for the thread necromancy]
> 
> I was wondering if you're planning on respinning this work, or rather the
> modalias approach alternative you mention? Or perhaps we are waiting for the
> cdev sysfs? Though, there's still a significant amount of kernel versions to
> cover that won't have the sysfs entry sadly :(

The cdev sysfs has been merged to the kernel now

Jason



Re: [PATCH python] virDomainMigrate3Params: Add missing params

2023-05-31 Thread Michal Prívozník
On 5/31/23 09:17, Han Han wrote:
> Add these missing migrate params:
> - VIR_MIGRATE_PARAM_DISKS_URI, since libvirt v6.8.0(49186372db)
> - VIR_MIGRATE_PARAM_TLS_DESTINATION, since libvirt v6.0.0(1b8af37213e)
> - VIR_MIGRATE_PARAM_COMPRESSION_ZLIB_LEVEL and 
> VIR_MIGRATE_PARAM_COMPRESSION_ZSTD_LEVEL,
> since libvirt v9.4.0(150ae3e62b9)
> 
> Signed-off-by: Han Han 
> ---
>  libvirt-override.c | 12 
>  1 file changed, 12 insertions(+)
> 

Thanks, I've created a MR:

https://gitlab.com/libvirt/libvirt-python/-/merge_requests/115

Michal



[libvirt PATCH] ci: refresh with latest lcitool manifest

2023-05-31 Thread Erik Skultety
Adds Alpine 3.17 and 3.18 targets.

Signed-off-by: Erik Skultety 
---
 ci/buildenv/{alpine-315.sh => alpine-317.sh} |  1 +
 .../{alpine-315.Dockerfile => alpine-317.Dockerfile} |  3 ++-
 ci/gitlab/builds.yml | 12 ++--
 ci/gitlab/container-templates.yml|  2 +-
 ci/gitlab/containers.yml |  4 ++--
 ci/manifest.yml  |  2 +-
 6 files changed, 13 insertions(+), 11 deletions(-)
 rename ci/buildenv/{alpine-315.sh => alpine-317.sh} (99%)
 rename ci/containers/{alpine-315.Dockerfile => alpine-317.Dockerfile} (97%)

diff --git a/ci/buildenv/alpine-315.sh b/ci/buildenv/alpine-317.sh
similarity index 99%
rename from ci/buildenv/alpine-315.sh
rename to ci/buildenv/alpine-317.sh
index 975914a7c2..e3f36ff8c6 100644
--- a/ci/buildenv/alpine-315.sh
+++ b/ci/buildenv/alpine-317.sh
@@ -60,6 +60,7 @@ function install_buildenv() {
 python3 \
 qemu-img \
 readline-dev \
+rpcgen \
 samurai \
 sed \
 util-linux-dev \
diff --git a/ci/containers/alpine-315.Dockerfile 
b/ci/containers/alpine-317.Dockerfile
similarity index 97%
rename from ci/containers/alpine-315.Dockerfile
rename to ci/containers/alpine-317.Dockerfile
index bad7e87c2b..162ae5671b 100644
--- a/ci/containers/alpine-315.Dockerfile
+++ b/ci/containers/alpine-317.Dockerfile
@@ -4,7 +4,7 @@
 #
 # https://gitlab.com/libvirt/libvirt-ci
 
-FROM docker.io/library/alpine:3.15
+FROM docker.io/library/alpine:3.17
 
 RUN apk update && \
 apk upgrade && \
@@ -61,6 +61,7 @@ RUN apk update && \
 python3 \
 qemu-img \
 readline-dev \
+rpcgen \
 samurai \
 sed \
 util-linux-dev \
diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml
index 96f8d3fb43..8910a19c79 100644
--- a/ci/gitlab/builds.yml
+++ b/ci/gitlab/builds.yml
@@ -51,22 +51,22 @@ x86_64-almalinux-8-clang-local-env:
 RPM: skip
 
 
-x86_64-alpine-315-prebuilt-env:
+x86_64-alpine-317-prebuilt-env:
   extends: .native_build_job_prebuilt_env
   needs:
-- job: x86_64-alpine-315-container
+- job: x86_64-alpine-317-container
   optional: true
   allow_failure: false
   variables:
-NAME: alpine-315
+NAME: alpine-317
 
-x86_64-alpine-315-local-env:
+x86_64-alpine-317-local-env:
   extends: .native_build_job_local_env
   needs: []
   allow_failure: false
   variables:
-IMAGE: docker.io/library/alpine:3.15
-NAME: alpine-315
+IMAGE: docker.io/library/alpine:3.17
+NAME: alpine-317
 
 
 x86_64-alpine-edge-prebuilt-env:
diff --git a/ci/gitlab/container-templates.yml 
b/ci/gitlab/container-templates.yml
index edb4aba676..adc8a1a312 100644
--- a/ci/gitlab/container-templates.yml
+++ b/ci/gitlab/container-templates.yml
@@ -14,7 +14,7 @@
 # Note: never publish from merge requests since they have non-committed code
 #
 .container_job:
-  image: docker:stable
+  image: docker:latest
   stage: containers
   interruptible: false
   needs: []
diff --git a/ci/gitlab/containers.yml b/ci/gitlab/containers.yml
index 3be84a2106..671483813e 100644
--- a/ci/gitlab/containers.yml
+++ b/ci/gitlab/containers.yml
@@ -14,11 +14,11 @@ x86_64-almalinux-8-container:
 NAME: almalinux-8
 
 
-x86_64-alpine-315-container:
+x86_64-alpine-317-container:
   extends: .container_job
   allow_failure: false
   variables:
-NAME: alpine-315
+NAME: alpine-317
 
 
 x86_64-alpine-edge-container:
diff --git a/ci/manifest.yml b/ci/manifest.yml
index 85d699bfae..4504068a64 100644
--- a/ci/manifest.yml
+++ b/ci/manifest.yml
@@ -19,7 +19,7 @@ targets:
   RPM: skip
   CC: clang
 
-  alpine-315: x86_64
+  alpine-317: x86_64
 
   alpine-edge:
 jobs:
-- 
2.40.1



[PATCH for 9.4.0] include: Fix 'Since' for new VIR_MIGRATE_PARAM_COMPRESSION_* macros

2023-05-31 Thread Michal Privoznik
In v9.3.0-98-g150ae3e62b two new macros were introduced:
VIR_MIGRATE_PARAM_COMPRESSION_ZLIB_LEVEL and
VIR_MIGRATE_PARAM_COMPRESSION_ZSTD_LEVEL. But both list 9.1.0 as
the version they were introduced in (this is because the patch
was sent in that release time frame). Change the version to the
current release.

Signed-off-by: Michal Privoznik 
---
 include/libvirt/libvirt-domain.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index 20467849a4..a1902546bb 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -1329,7 +1329,7 @@ typedef enum {
  * VIR_TYPED_PARAM_INT. Accepted values are in range 0-9. 0 is no compression,
  * 1 is maximum speed and 9 is maximum compression.
  *
- * Since: 9.1.0
+ * Since: 9.4.0
  */
 # define VIR_MIGRATE_PARAM_COMPRESSION_ZLIB_LEVEL  "compression.zlib.level"
 
@@ -1340,7 +1340,7 @@ typedef enum {
  * VIR_TYPED_PARAM_INT. Accepted values are in range 0-20. 0 is no compression,
  * 1 is maximum speed and 20 is maximum compression.
  *
- * Since: 9.1.0
+ * Since: 9.4.0
  */
 # define VIR_MIGRATE_PARAM_COMPRESSION_ZSTD_LEVEL  "compression.zstd.level"
 
-- 
2.39.3



[PATCH python] virDomainMigrate3Params: Add missing params

2023-05-31 Thread Han Han
Add these missing migrate params:
- VIR_MIGRATE_PARAM_DISKS_URI, since libvirt v6.8.0(49186372db)
- VIR_MIGRATE_PARAM_TLS_DESTINATION, since libvirt v6.0.0(1b8af37213e)
- VIR_MIGRATE_PARAM_COMPRESSION_ZLIB_LEVEL and 
VIR_MIGRATE_PARAM_COMPRESSION_ZSTD_LEVEL,
since libvirt v9.4.0(150ae3e62b9)

Signed-off-by: Han Han 
---
 libvirt-override.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/libvirt-override.c b/libvirt-override.c
index 0c198cb..8a86174 100644
--- a/libvirt-override.c
+++ b/libvirt-override.c
@@ -8154,6 +8154,18 @@ static virPyTypedParamsHint virPyDomainMigrate3Params[] 
= {
 # ifdef VIR_MIGRATE_PARAM_PARALLEL_CONNECTIONS
 { VIR_MIGRATE_PARAM_PARALLEL_CONNECTIONS, VIR_TYPED_PARAM_INT },
 # endif
+# ifdef VIR_MIGRATE_PARAM_DISKS_URI
+{ VIR_MIGRATE_PARAM_DISKS_URI, VIR_TYPED_PARAM_STRING },
+#endif
+#ifdef VIR_MIGRATE_PARAM_TLS_DESTINATION
+{ VIR_MIGRATE_PARAM_TLS_DESTINATION, VIR_TYPED_PARAM_STRING },
+#endif
+#ifdef VIR_MIGRATE_PARAM_COMPRESSION_ZLIB_LEVEL
+{ VIR_MIGRATE_PARAM_COMPRESSION_ZLIB_LEVEL, VIR_TYPED_PARAM_INT },
+#endif
+#ifdef VIR_MIGRATE_PARAM_COMPRESSION_ZSTD_LEVEL
+{ VIR_MIGRATE_PARAM_COMPRESSION_ZSTD_LEVEL, VIR_TYPED_PARAM_INT },
+#endif
 };
 
 
-- 
2.40.1



[libvirt PATCHv2] conf: node_device: use separate variables for parsing integers

2023-05-31 Thread Ján Tomko
In virNodeDeviceGetSCSIHostCaps, there is a pattern of reusing
a tmp value and stealing the pointer.

But in two case it is not stolen. Use separate variables for them
to avoid mixing autofree with manual free() calls.

Fixes: 8a0cb5f73ade3900546718eabe70cb064c6bd22c
Signed-off-by: Ján Tomko 
---
v2: also replace the variable name in the error message and fix one more case

 src/conf/node_device_conf.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index fcee9c027c..48a47f0f86 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -2858,28 +2858,30 @@ virNodeDeviceGetSCSIHostCaps(virNodeDevCapSCSIHost 
*scsi_host)
 
 if (virVHBAIsVportCapable(NULL, scsi_host->host)) {
 scsi_host->flags |= VIR_NODE_DEV_CAP_FLAG_HBA_VPORT_OPS;
+g_autofree char *max_vports = NULL;
+g_autofree char *vports = NULL;
 
-if (!(tmp = virVHBAGetConfig(NULL, scsi_host->host,
+if (!(max_vports = virVHBAGetConfig(NULL, scsi_host->host,
  "max_npiv_vports"))) {
 VIR_WARN("Failed to read max_npiv_vports for host%d",
  scsi_host->host);
 goto cleanup;
 }
 
-if (virStrToLong_i(tmp, NULL, 10, _host->max_vports) < 0) {
-VIR_WARN("Failed to parse value of max_npiv_vports '%s'", tmp);
+if (virStrToLong_i(max_vports, NULL, 10, _host->max_vports) < 0) {
+VIR_WARN("Failed to parse value of max_npiv_vports '%s'", 
max_vports);
 goto cleanup;
 }
 
-if (!(tmp = virVHBAGetConfig(NULL, scsi_host->host,
+if (!(vports = virVHBAGetConfig(NULL, scsi_host->host,
   "npiv_vports_inuse"))) {
 VIR_WARN("Failed to read npiv_vports_inuse for host%d",
  scsi_host->host);
 goto cleanup;
 }
 
-if (virStrToLong_i(tmp, NULL, 10, _host->vports) < 0) {
-VIR_WARN("Failed to parse value of npiv_vports_inuse '%s'", tmp);
+if (virStrToLong_i(vports, NULL, 10, _host->vports) < 0) {
+VIR_WARN("Failed to parse value of npiv_vports_inuse '%s'", 
vports);
 goto cleanup;
 }
 }
-- 
2.40.1