RE: join running core dump job

2024-03-04 Thread Thanos Makatos
> -Original Message- > From: Thanos Makatos > Sent: Monday, March 4, 2024 5:24 PM > To: devel@lists.libvirt.org > Subject: join running core dump job > > Is there a way to programmatically wait for a previously initiated > virDomainCoreDumpWithFormat() where the process that started it

Re: [PATCH 1/5] qemu.conf changes to support multiple memory backend directories

2024-03-04 Thread Michael Galaxy
Hi Martin, Answers inline. Thanks for helping with the review and all the tips! On 3/1/24 04:00, Martin Kletzander wrote: On Mon, Jan 29, 2024 at 04:43:53PM -0500, mgal...@akamai.com wrote: From: Michael Galaxy In our case, we almost always have two NUMA nodes, so in that example, we

[PATCH 2/2] storage: fix testcases on changing the default qcow2 compat to 1.1

2024-03-04 Thread Abhiram Tilak
After changing the default qcow2 image to 1.1 from 0.10. Some of the testcases in `storagevolxml2` here need fixing. This patch changes the expected compat version in each of these files that call qemu-img. As per qemu's Qcow docs the qemu-img command gives a 1.1 compatible version image. These

[PATCH 1/2] storage: change assigning qcow2 compat to 1.1 from 0.10 automatically

2024-03-04 Thread Abhiram Tilak
In the file `storage/storage_util.c` currently `compat` varible is begin assigned to 0.10 by default. This patch changes this default value to 1.1. This is done in efforts to upgrade the default qcow2 image version to 1.1. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/602 Signed-off-by:

[PATCH 0/2] storage: Upgrade default qcow2 verion to 1.1

2024-03-04 Thread Abhiram Tilak
Right now the default qcow2 version if not specified explicitly, defaults to 0.10. Certain features like live snapshots, cluster size specification require 1.1 to work. This patch series aims at upgrading the qcow2 default image version, and use compatibility version 1.1 unless specified. This

Re: [PATCH] hw/core/machine-smp: Remove deprecated "parameter=0" SMP configurations

2024-03-04 Thread Prasad Pandit
Hello Zhao, On Mon, 4 Mar 2024 at 12:19, Zhao Liu wrote: > > unsigned maxcpus = config->has_maxcpus ? config->maxcpus : 0; > > This indicates the default maxcpus is initialized as 0 if user doesn't > specifies it. * 'has_maxcpus' should be set only if maxcpus > 0. If maxcpus == 0, then setting

Re: [PATCH] ci: refresh with lcitool manifest

2024-03-04 Thread Andrea Bolognani
On Mon, Mar 04, 2024 at 04:34:35PM +, Daniel P. Berrangé wrote: > Picks up the switch from FreeBSD 13.2 to 13.3 > > Signed-off-by: Daniel P. Berrangé > --- > ci/gitlab/builds.yml | 2 +- > ci/lcitool/targets/freebsd-13.yml | 2 -- > 2 files changed, 1 insertion(+), 3

join running core dump job

2024-03-04 Thread Thanos Makatos
Is there a way to programmatically wait for a previously initiated virDomainCoreDumpWithFormat() where the process that started it died? I'm looking at the API and don't seem to find anything relevant. I suppose I could poll via virDomainGetJobStats(), but, ideally, I'd like a function that

Re: [PATCH v3 01/12] cpu_map: update script to handle versioned CPUs

2024-03-04 Thread Jim Fehlig
On 3/1/24 10:13, Daniel P. Berrangé wrote: On Fri, Mar 01, 2024 at 10:36:12AM -0600, Jonathon Jongsma wrote: On 3/1/24 10:13 AM, Daniel P. Berrangé wrote: On Tue, Feb 20, 2024 at 05:08:02PM -0700, Jim Fehlig wrote: On 12/15/23 15:11, Jonathon Jongsma wrote: Previously, the script only

[PATCH] qemu: Optimize CPU check='partial' for usable CPUs

2024-03-04 Thread Jiri Denemark
Ideally check='partial' would check exactly the features QEMU would want to enable when asked for a specific CPU model (and features). But there is no way we could ask QEMU how a specific CPU would look like. So we use our definition from CPU map, which may slightly differ as QEMU adds or removes

[PATCH] cpu: x86: Check for invalid CPU data from hypervisor

2024-03-04 Thread Jiri Denemark
Recently a kernel bug caused QEMU to report a CPU feature as enabled while listing it in the "unavailable-features" list of features that were requested, but could not be enabled. The feature was actually enabled, but we marked it as disabled when starting a domain. Later when the domain is

[PATCH] ci: refresh with lcitool manifest

2024-03-04 Thread Daniel P . Berrangé
Picks up the switch from FreeBSD 13.2 to 13.3 Signed-off-by: Daniel P. Berrangé --- ci/gitlab/builds.yml | 2 +- ci/lcitool/targets/freebsd-13.yml | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) delete mode 100644 ci/lcitool/targets/freebsd-13.yml diff --git

Re: [PATCH] hw/core/machine-smp: Remove deprecated "parameter=0" SMP configurations

2024-03-04 Thread Zhao Liu
Hi Prasad, On Mon, Mar 04, 2024 at 11:23:58AM +0530, Prasad Pandit wrote: > Date: Mon, 4 Mar 2024 11:23:58 +0530 > From: Prasad Pandit > Subject: Re: [PATCH] hw/core/machine-smp: Remove deprecated "parameter=0" > SMP configurations > > On Mon, 4 Mar 2024 at 10:02, Zhao Liu wrote: > > diff

Re: [PATCH] hw/core/machine-smp: Remove deprecated "parameter=0" SMP configurations

2024-03-04 Thread Prasad Pandit
On Mon, 4 Mar 2024 at 10:02, Zhao Liu wrote: > diff --git a/hw/core/machine-smp.c b/hw/core/machine-smp.c > index 25019c91ee36..96533886b14e 100644 > --- a/hw/core/machine-smp.c > +++ b/hw/core/machine-smp.c > @@ -105,8 +105,9 @@ void machine_parse_smp_config(MachineState *ms, >

[PATCH] hw/core/machine-smp: Remove deprecated "parameter=0" SMP configurations

2024-03-04 Thread Zhao Liu
From: Zhao Liu The "parameter=0" SMP configurations have been marked as deprecated since v6.2. For these cases, -smp currently returns the warning and adjusts the zeroed parameters to 1 by default. Remove the above compatibility logic in v9.0, and return error directly if any -smp parameter is