From: Hyman Huang
As advised by the GNU TLS, the caller should attempt again
if the gnutls_record_{recv,send} return EAGAIN or EINTR;
check the following link to view the details:
https://www.gnutls.org/manual/html_node/Data-transfer-and-termination.html
virNetClientSetTLSSession failed to handl
From: Hyman Huang
v2:
1. Move the retry logic outside of virNetTLSSession{Read,Write}
2. Try re-polling when handing EAGAIN suggested by Daniel
v1:
1. Encapsulate the retry logic inside virNetTLSSession{Read,Write}
2. Use VIR_DEBUG instead of VIR_WARN to log the retry operation
rfc:
https://pat
From: Hyman Huang
As advised by the GNU TLS, the caller should attempt again
if the gnutls_record_{recv,send} return EAGAIN or EINTR;
check the following link to view the details:
https://www.gnutls.org/manual/html_node/Data-transfer-and-termination.html
virNetClientSetTLSSession failed to handl
From: Hyman Huang
v2:
1. Move the retry logic outside of virNetTLSSession{Read,Write}
2. Try re-polling when handing EAGAIN suggested by Daniel
v1:
1. Encapsulate the retry logic inside virNetTLSSession{Read,Write}
2. Use VIR_DEBUG instead of VIR_WARN to log the retry operation
rfc:
https://pat
On 4/24/25 14:18, Jim Fehlig wrote:
On 4/24/25 04:59, Daniel P. Berrangé wrote:
On Mon, Apr 21, 2025 at 01:38:35PM -0600, Jim Fehlig via Devel wrote:
Hi All,
While investigating an internal bug report, we noticed that a minimal
firmware auto-selection configuration along with SEV* fails to fin
> On May 13, 2025, at 3:10 AM, Daniel P. Berrangé wrote:
>
> On Mon, May 12, 2025 at 07:33:37PM +, Matt Ochs wrote:
>>> On May 12, 2025, at 5:19 AM, Daniel P. Berrangé wrote:
>>> On Fri, May 09, 2025 at 07:29:04PM +, Matt Ochs wrote:
Would it make sense to just use the existin
On Tue, May 13, 2025 at 16:43:52 +0200, Michal Privoznik via Devel wrote:
> From: Michal Privoznik
>
> The whole point of virnetlink.h is that it hides away the build
> time dependency on netlink. It wraps netlink functions in our
> functions which then have a stub implementation in case netlink
From: Michal Privoznik
Currently, virNetlinkBridgeVlanFilterSet() takes @cmd as the
second argument where either RTM_SETLINK or RTM_DELLINK is
expected. Both of these constants come from linux/rtnetlink.h and
thus are undefined when building without netlink. This design
also clashes with the whol
From: Michal Privoznik
The whole point of virnetlink.h is that it hides away the build
time dependency on netlink. It wraps netlink functions in our
functions which then have a stub implementation in case netlink
support was disabled.
Though, netlink is still Linux specific, so keep it in the
'#
From: Michal Privoznik
We still use C89 style of comments. Fix C99 style of comments
used in virNetDevBridgeSetupVlans().
Signed-off-by: Michal Privoznik
Reviewed-by: Peter Krempa
---
src/util/virnetdevbridge.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/util
From: Michal Privoznik
In virnetlink.c there are two sections: the first one when
building WITH_LIBNL support, the other that provides stubs for
functions declared in the corresponding header file when building
without netlink support. But the stub implementation for
virNetlinkBridgeVlanFilterSet
v2 of:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/VYUE7LQB4D5UTEXOEM65ZPJWS2ROZWAW/
diff to v1:
1) Patch 1/5 from the original is dropped, no symbol addition to the
private syms file,
2) The "virnetlink.h" is included more often in patch 3/4,
3) Some fixes around vi
On Mon, May 12, 2025 at 15:37:16 +0200, Michal Privoznik via Devel wrote:
> From: Michal Privoznik
>
> Currently, virNetlinkBridgeVlanFilterSet() takes @cmd as the
> second argument where either RTM_SETLINK or RTM_DELLINK is
> expected. Both of these constants come from linux/rtnetlink.h and
> th
On Mon, May 12, 2025 at 15:37:15 +0200, Michal Privoznik via Devel wrote:
> From: Michal Privoznik
>
> The whole point of virnetlink.h is that it hides away the build
> time dependency on netlink. It wraps netlink functions in our
> functions which then have a stub implementation in case netlink
On Tue, May 13, 2025 at 15:30:20 +0200, Michal Prívozník wrote:
> On 5/13/25 09:53, Peter Krempa wrote:
> > On Mon, May 12, 2025 at 15:37:13 +0200, Michal Privoznik via Devel wrote:
> >> From: Michal Privoznik
> >>
> >> In virnetlink.c there are two sections: the first one when
> >> building WITH_
On 5/13/25 09:53, Peter Krempa wrote:
> On Mon, May 12, 2025 at 15:37:13 +0200, Michal Privoznik via Devel wrote:
>> From: Michal Privoznik
>>
>> In virnetlink.c there are two sections: the first one when
>> building WITH_LIBNL support, the other that provides stubs for
>> functions declared in th
On 5/13/25 09:46, Peter Krempa wrote:
> On Mon, May 12, 2025 at 15:37:11 +0200, Michal Privoznik via Devel wrote:
>> Resolves: https://gitlab.com/libvirt/libvirt/-/issues/770
>>
>> While the original issue report describes scenario where libnl devel
>> package wasn't installed, it's perfectly repro
On 5/13/25 09:49, Peter Krempa wrote:
> On Mon, May 12, 2025 at 15:37:12 +0200, Michal Privoznik via Devel wrote:
>> From: Michal Privoznik
>>
>> The function was introduced in v11.0.0-rc1~23 but corresponding
>> change to the private syms file was missing.
>>
>> Signed-off-by: Michal Privoznik
>
On a Tuesday in 2025, Peter Krempa via Devel wrote:
From: Peter Krempa
Due to a logic bug the error message mentioning mult_queue operation
multi_queue
would be mentioned also when a single queue would be opened on an
externally managed tap device.
Adjust the condition to trigger only when
On Tue, May 13, 2025 at 13:28:58 +0100, Daniel P. Berrangé wrote:
> On Tue, May 13, 2025 at 02:25:51PM +0200, Peter Krempa via Devel wrote:
> > From: Peter Krempa
> >
> > While the queue count itself is not a guest visible property, libvirt
> > uses it to calculate the 'vectors' property of the '
On Tue, May 13, 2025 at 02:25:50PM +0200, Peter Krempa via Devel wrote:
> From: Peter Krempa
>
> Due to a logic bug the error message mentioning mult_queue operation
> would be mentioned also when a single queue would be opened on an
> externally managed tap device.
>
> Adjust the condition to t
On Tue, May 13, 2025 at 02:25:51PM +0200, Peter Krempa via Devel wrote:
> From: Peter Krempa
>
> While the queue count itself is not a guest visible property, libvirt
> uses it to calculate the 'vectors' property of the 'virtio-net' device
> which is ABI.
>
> Since we don't expose control of 've
From: Peter Krempa
While the queue count itself is not a guest visible property, libvirt
uses it to calculate the 'vectors' property of the 'virtio-net' device
which is ABI.
Since we don't expose control of 'vectors' explicitly, consider 'queues'
ABI.
Signed-off-by: Peter Krempa
---
src/conf/
From: Peter Krempa
Due to a logic bug the error message mentioning mult_queue operation
would be mentioned also when a single queue would be opened on an
externally managed tap device.
Adjust the condition to trigger only when multiple queues are in use.
Fixes: f6fb097e11a
Signed-off-by: Peter
Peter Krempa (2):
virNetDevTapCreate: Use error message hinting to multiqueue use only
when opening multiple queues
virDomainNetDefCheckABIStability: Consider virtio 'queues' ABI
src/conf/domain_conf.c | 11 +++
src/util/virnetdevtap.c | 2 +-
2 files changed, 12 insertions(+),
On Thu, 8 May 2025 15:35:23 +0200
Philippe Mathieu-Daudé wrote:
> Since v3:
> - Addressed Thomas and Zhao review comments
> - Rename fw_cfg_init_mem_[no]dma() helpers
> - Remove unused CPU properties
> - Remove {multi,linux}boot.bin
> - Added R-b tags
>
> Since v2:
> - Addressed Mark review com
On Mon, May 12, 2025 at 07:33:37PM +, Matt Ochs wrote:
> > On May 12, 2025, at 5:19 AM, Daniel P. Berrangé wrote:
> > On Fri, May 09, 2025 at 07:29:04PM +, Matt Ochs wrote:
> >>
> >> Would it make sense to just use the existing pcihole64 since [I think]
> >> it more or less represents the
On Mon, May 12, 2025 at 15:37:14 +0200, Michal Privoznik via Devel wrote:
> From: Michal Privoznik
>
> We still use C89 style of comments. Fix C99 style of comments
> used in virNetDevBridgeSetupVlans().
>
> Signed-off-by: Michal Privoznik
> ---
> src/util/virnetdevbridge.c | 6 +++---
> 1 fil
On Mon, May 12, 2025 at 15:37:13 +0200, Michal Privoznik via Devel wrote:
> From: Michal Privoznik
>
> In virnetlink.c there are two sections: the first one when
> building WITH_LIBNL support, the other that provides stubs for
> functions declared in the corresponding header file when building
>
Support for the pseries-2.7 machine type in QEMU was officially removed in
version 9.2 with qemu commit 445d3facffe8 ("ppc/spapr: remove deprecated
machine pseries-2.7"). Instead of removing related tests, they are now pinned
to the latest available capabilities version 7.0.0 to ensure continued
fu
On Mon, May 12, 2025 at 15:37:12 +0200, Michal Privoznik via Devel wrote:
> From: Michal Privoznik
>
> The function was introduced in v11.0.0-rc1~23 but corresponding
> change to the private syms file was missing.
>
> Signed-off-by: Michal Privoznik
> ---
> src/libvirt_private.syms | 1 +
> 1
On Mon, May 12, 2025 at 15:37:11 +0200, Michal Privoznik via Devel wrote:
> Resolves: https://gitlab.com/libvirt/libvirt/-/issues/770
>
> While the original issue report describes scenario where libnl devel
> package wasn't installed, it's perfectly reproducible with
> -Dlibnl=disabled passed to m
This patch adds POWER11 CPU host-model support in libvirt's ppc64
CPU driver. With this addition, guests using CPU mode 'host-model'
can specify POWER11 as the CPU model and have libvirt handle it
correctly.
With this change, libvirt can generate correct QEMU command line using
`-machine ... max-c
Add support for the POWER11 CPU model in libvirt ppc64 CPU map. This
allows libvirt to recognize and handle guests that specify POWER11 as
the target CPU model when running on recent Power systems supporting
this architecture.
The addition includes:
- A new src/cpu_map/ppc64_POWER11.xml definition
Commit 140ff3c5141 ("tests: qemuhotplugtest: Fix arch-specific parts of
'ppc64' test XMLs") hardcoded the CPU model as POWER9 in the test result
XMLs. However, this value actually reflects the host CPU model detected
at build or test time, and can vary depending on the machine where the
tests run.
This patch series introduces the necessary changes to
support the POWER11 CPU and POWER11 host in libvirt.
Additionally, it updates the QEMU capabilities with
the latest QEMU version v10.0.0 to include power11
in the capabilities tests.During testing of v2 patches
found a bug in qemu which sets wro
On 06/05/25 6:02 PM, Daniel P. Berrangé wrote:
AFAIK there has never been any IBM marketing request to the libvirt project
in respect of CPU names. Perhaps that was communicated to IBM contributors
writing patches in private, but from POV of the libvirt community upstream
that is irrelevant. We
37 matches
Mail list logo
