On 7/15/25 2:23 PM, Pierrick Bouvier wrote:
The FEAT_MEC series [1] introduces FEAT_TCR2 and FEAT_SCTLR2.
TF-A needs to be aware of that change to allow accesses to those registers, and
thus must be patched [2] to enable this for QEMU platforms.
Concerned test images need to be updated to allow
Hi Richard,
On 7/18/25 8:58 PM, Pierrick Bouvier wrote:
The FEAT_MEC series [1] introduces FEAT_TCR2 and FEAT_SCTLR2.
TF-A needs to be aware of that change to allow accesses to those registers, and
thus must be patched [2] to enable this for QEMU platforms.
Concerned test images need to be upda
TF-A needs to be patched to enable support for FEAT_TCR2 and
FEAT_SCTLR2. This new image contains updated firmware.
Signed-off-by: Pierrick Bouvier
---
.../test_aarch64_device_passthrough.py| 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/tests/fu
TF-A needs to be patched to enable support for FEAT_TCR2 and
FEAT_SCTLR2. This new image contains updated firmware.
Signed-off-by: Pierrick Bouvier
---
tests/functional/test_aarch64_rme_sbsaref.py | 64 ---
tests/functional/test_aarch64_rme_virt.py| 85 +++-
2 fil
The FEAT_MEC series [1] introduces FEAT_TCR2 and FEAT_SCTLR2.
TF-A needs to be aware of that change to allow accesses to those registers, and
thus must be patched [2] to enable this for QEMU platforms.
Concerned test images need to be updated to allow them to boot.
[1]
https://lore.kernel.org/qe
The temporary egl fb scanout_tex_fb is only needed to facilitate the
blit to the display surface's texture (ssd->ds->texture). Therefore,
destroy it after the blit is submitted. And, also make sure that it
is empty initialized before it is actually used.
Fixes: f851cd65 ("ui/spice: Blit the scanou
On 7/18/25 10:30, Peter Maydell wrote:
For the LD1Q instruction (gather load of quadwords) we use the
LD1_zprz pattern with MO_128 elements. At this element size there is
no signed vs unsigned distinction, and we only set the 'u' bit in the
arg_LD1_zprz struct because we share the code and decod
On 7/18/25 10:30, Peter Maydell wrote:
The FMAXNMQV and FMINNMQV insns use the default NaN as their identity
value for inactive source vector elements. We open-coded this in
sve_helper.c, hoping to avoid a function call. However, this fails
to account for FPCR.AH=1 changing the default NaN value
On 7/18/25 10:30, Peter Maydell wrote:
In the part of the SVE DO_REDUCE macro used by the SVE2p1 FMAXQV,
FMINQV, etc insns, we incorrectly applied the H() macro twice when
calculating an offset to add to the vn pointer. This has no effect
on little-endian hosts but on big-endian hosts the two in
On 7/18/25 10:30, Peter Maydell wrote:
When we implemented the FMAXQV and FMINQV insns we accidentally
inverted the sense of the FPCR.AH test, so we gave the AH=1 behaviour
when FPCR.AH was zero, and vice-versa. (The difference is limited to
hadling of negative zero and NaN inputs.)
Fixes: 1de7
On 7/18/25 10:30, Peter Maydell wrote:
FEAT_SVE_B16B16 adds bfloat16 versions of the FMLA and FMLS insns in
the SVE floating-point multiply-add (indexed) insn group. Implement
these.
Fixes: 7b1613a1020d2942 ("target/arm: Enable FEAT_SME2p1 on -cpu max")
Signed-off-by: Peter Maydell
---
target
On 7/18/25 10:30, Peter Maydell wrote:
FEAT_SVE_B16B16 adds bfloat16 versions of the FMLA and FMLS insns in
the "SVE floating-point multiply-accumulate writing addend" group,
encoded as sz=0b00.
Fixes: 7b1613a1020d2942 ("target/arm: Enable FEAT_SME2p1 on -cpu max")
Signed-off-by: Peter Maydell
-
On 7/18/25 10:30, Peter Maydell wrote:
FEAT_SVE_B16B16 adds bfloat16 versions of the SVE floating point
(predicated) instructions, which are encoded via sz=0b00. Add the
BFMAX and BFMIN insns. These have separate behaviour for AH=1 and
AH=0; we have already implemented the AH=1 helper for the S
On 7/18/25 10:30, Peter Maydell wrote:
FEAT_SVE_B16B16 adds a bfloat16 version of the FMUL insn in the
floating-point multiply (indexed) instruction group. The encoding
is slightly bespoke; in our implementation we use MO_8 to indicate
bfloat16, as with the other B16B16 insns.
Fixes: 7b1613a1020
On 7/18/25 10:30, Peter Maydell wrote:
FEAT_SVE_B16B16 adds bfloat16 versions of the SVE floating point
(predicated) instructions, which are encoded via sz=0b00.
Add BFADD, BFSUB, BFMUL, BFMAXNM, BFMINNM; these are all the insns
in this group which do not change behaviour for AH=1.
We will deal
On 7/18/25 10:30, Peter Maydell wrote:
FEAT_SVE_B16B16 adds bfloat16 versions of the SVE floating point
(unpredicated) instructions, which are encoded via sz==0b00.
Fixes: 7b1613a1020d2942 ("target/arm: Enable FEAT_SME2p1 on -cpu max")
Signed-off-by: Peter Maydell
---
target/arm/tcg/helper.h
On 7/18/25 12:11, Peter Maydell wrote:
On Fri, 18 Jul 2025 at 18:46, Richard Henderson
wrote:
There is no such thing as vector extract.
Fixes: 932522a9ddc1 ("tcg/optimize: Fold and to extract during optimize")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3036
Signed-off-by: Richard
On 7/18/25 21:43, Gerd Hoffmann wrote:
From: Shaoqin Huang
Move the TYPE_* to a new file hw/vfio/types.h because the
TYPE_VFIO_PCI will be used in later patch, but directly include the
hw/vfio/pci.h can cause some compilation error when cross build the
windows version.
The hw/vfio/types.h can
On 7/18/25 10:38 AM, Richard Henderson wrote:
There is no such thing as vector extract.
Fixes: 932522a9ddc1 ("tcg/optimize: Fold and to extract during optimize")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3036
Signed-off-by: Richard Henderson
---
tcg/optimize.c | 2 +-
1 file ch
gs/display-20250718-pull-request
for you to fetch changes up to d5fcf0d960d893b1765e6388cefca9c690839267:
hw/i386: Add the ramfb romfile compatibility (2025-07-18 21:41:57 +0200)
Load ramfb vgabios o
From: Shaoqin Huang
Move the TYPE_* to a new file hw/vfio/types.h because the
TYPE_VFIO_PCI will be used in later patch, but directly include the
hw/vfio/pci.h can cause some compilation error when cross build the
windows version.
The hw/vfio/types.h can be included to mitigate that problem.
Si
From: Shaoqin Huang
ramfb is a sysbus device so it can only used for machine types where it
is explicitly enabled:
# git grep machine_class_allow_dynamic_sysbus_dev.*TYPE_RAMFB_DEVICE
hw/arm/virt.c:machine_class_allow_dynamic_sysbus_dev(mc,
TYPE_RAMFB_DEVICE);
hw/i386
From: Shaoqin Huang
Currently the ramfb device loads the vgabios-ramfb.bin unconditionally,
but only the x86 need the vgabios-ramfb.bin, this can cause that when
use the release package on arm64 it can't find the vgabios-ramfb.bin.
Because only seabios will use the vgabios-ramfb.bin, load the ro
On Fri, 18 Jul 2025 at 18:46, Richard Henderson
wrote:
>
> There is no such thing as vector extract.
>
> Fixes: 932522a9ddc1 ("tcg/optimize: Fold and to extract during optimize")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3036
> Signed-off-by: Richard Henderson
> ---
> tcg/optimiz
Upon examining the current implementation for getting/setting SIMD
and SVE registers via remote GDB, there is a concern about mixed
endian support.
Consider the following snippet from a GDB session in which a SIMD
register's value is set via remote GDB where the QEMU host is little
endian and the
On 7/16/2025 10:43 PM, Duan, Zhenzhong wrote:
-Original Message-
From: Steve Sistare
Subject: [PATCH V2 2/2] vfio/pci: preserve pending interrupts
cpr-transfer may lose a VFIO interrupt because the KVM instance is
destroyed and recreated. If an interrupt arrives in the middle, it is
dr
On 7/18/2025 4:48 AM, Lei Yang wrote:
Hi Steve
I tested your patch which hit a problem under enable/disable nic mq
state(The full test scenario is live migration vm at local under
enable/disable vm nic mq state):
Run command: /qemu-img info /home/images/vm1.qcow2 --output=json
Error info: qemu-i
FEAT_SVE_B16B16 adds bfloat16 versions of the FMLA and FMLS insns in
the "SVE floating-point multiply-accumulate writing addend" group,
encoded as sz=0b00.
Fixes: 7b1613a1020d2942 ("target/arm: Enable FEAT_SME2p1 on -cpu max")
Signed-off-by: Peter Maydell
---
target/arm/tcg/helper-sve.h| 14
FEAT_SVE_B16B16 adds bfloat16 versions of the SVE floating point
(predicated) instructions, which are encoded via sz=0b00.
Add BFADD, BFSUB, BFMUL, BFMAXNM, BFMINNM; these are all the insns
in this group which do not change behaviour for AH=1.
We will deal with BFMAX/BFMIN (which do have different
This patchset fixes some problems with the recently landed SVE2p1
feature. Notably, we missed out several bfloat16 insns entirely...
This patchset adds in the missing insns, and also fixes some
bugs in the FMAXQV etc insns, and an incorrect assertion in LD1Q.
I know this is slightly pushing the bo
There is no such thing as vector extract.
Fixes: 932522a9ddc1 ("tcg/optimize: Fold and to extract during optimize")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3036
Signed-off-by: Richard Henderson
---
tcg/optimize.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
FEAT_SVE_B16B16 adds bfloat16 versions of the FMLA and FMLS insns in
the SVE floating-point multiply-add (indexed) insn group. Implement
these.
Fixes: 7b1613a1020d2942 ("target/arm: Enable FEAT_SME2p1 on -cpu max")
Signed-off-by: Peter Maydell
---
target/arm/tcg/sve.decode | 2 ++
target/
In the part of the SVE DO_REDUCE macro used by the SVE2p1 FMAXQV,
FMINQV, etc insns, we incorrectly applied the H() macro twice when
calculating an offset to add to the vn pointer. This has no effect
on little-endian hosts but on big-endian hosts the two invocations
will cancel each other out and
The FMAXNMQV and FMINNMQV insns use the default NaN as their identity
value for inactive source vector elements. We open-coded this in
sve_helper.c, hoping to avoid a function call. However, this fails
to account for FPCR.AH=1 changing the default NaN value to set the
sign bit. Use a call to floatN
FEAT_SVE_B16B16 adds a bfloat16 version of the FMUL insn in the
floating-point multiply (indexed) instruction group. The encoding
is slightly bespoke; in our implementation we use MO_8 to indicate
bfloat16, as with the other B16B16 insns.
Fixes: 7b1613a1020d2942 ("target/arm: Enable FEAT_SME2p1 on
FEAT_SVE_B16B16 adds bfloat16 versions of the SVE floating point
(predicated) instructions, which are encoded via sz=0b00. Add the
BFMAX and BFMIN insns. These have separate behaviour for AH=1 and
AH=0; we have already implemented the AH=1 helper for the SME2
versions of these insns.
Fixes: 7b16
For the LD1Q instruction (gather load of quadwords) we use the
LD1_zprz pattern with MO_128 elements. At this element size there is
no signed vs unsigned distinction, and we only set the 'u' bit in the
arg_LD1_zprz struct because we share the code and decode struct with
smaller element sizes.
How
When we implemented the FMAXQV and FMINQV insns we accidentally
inverted the sense of the FPCR.AH test, so we gave the AH=1 behaviour
when FPCR.AH was zero, and vice-versa. (The difference is limited to
hadling of negative zero and NaN inputs.)
Fixes: 1de7ecfc12d05 ("target/arm: Implement FADDQV,
FEAT_SVE_B16B16 adds bfloat16 versions of the SVE floating point
(unpredicated) instructions, which are encoded via sz==0b00.
Fixes: 7b1613a1020d2942 ("target/arm: Enable FEAT_SME2p1 on -cpu max")
Signed-off-by: Peter Maydell
---
target/arm/tcg/helper.h| 3 +++
target/arm/tcg/translate-s
The UART clock frequency field of the SPCR table was added in revision 3.
Currently, build_spcr() treats revision 3 tables the same as revision 2 and
only includes this field in revision 4 tables.
Fix build_spcr() to include the clock frequency field in revision 3 tables.
Per the specification, th
Previous patch changed the SPCR ACPI table for AArch64 virt:
@@ -15,2 +15,2 @@
-[008h 0008 001h]Revision : 02
-[009h 0009 001h]Checksum : B1
+[008h 0008 001h]Revision : 03
+[009h 0009 001h]Checksum : 0B
@@ -49 +49 @@
-[
Hi Daniel,
Thank you so much for the review.
On Thu, Jul 17, 2025 at 05:32:14PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 17, 2025 at 06:07:25AM +0530, Arun Menon wrote:
> > This is an incremental step in converting vmstate loading
> > code to report error via Error objects instead of direct
On the ARM virt machine, there is currently no way to programmatically
discover the frequency of the UART reference clock solely through the use of
UEFI/ACPI (without the DTB). The SPCR table can include this information
as of revision 3.
Bump the revision to 3 and add the clock frequency of 24 MH
This series fixes erroneous building of ACPI SPCR tables in
hw/acpi/aml-build.c,
where the UART clock frequency field is omitted in revision 3 tables despite
being present since revision 3 of the specification.
The last three patches update the SPCR table for the AArch64 virt machine to
revision
Signed-off-by: Vadim Chichikalyuk
---
tests/qtest/bios-tables-test-allowed-diff.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..2a30472d57 100644
--- a/tests/qtest/bios-tables-test-a
On Fri, Jul 18, 2025 at 10:52:30AM +0200, Paolo Abeni wrote:
If the driver uses any of the extended features (i.e. 64 or above),
store the extended features range (64-127 bits).
At load time, let legacy features initialize the full features range
and pass it to the set helper; sub-states loading
On 7/15/2025 5:25 PM, Mark Cave-Ayland wrote:
> Use QOM casts to convert between VFIOPCIDevice and PCIDevice instead of
> accessing pdev directly.
>
> Signed-off-by: Mark Cave-Ayland
> ---
> hw/vfio/igd.c | 38 +-
> 1 file changed, 21 insertions(+), 17 deletio
On Fri, Jul 18, 2025 at 10:52:39AM +0200, Paolo Abeni wrote:
When any host or guest GSO over UDP tunnel offload is enabled the
virtio net header includes the additional tunnel-related fields,
update the size accordingly.
Push the GSO over UDP tunnel offloads all the way down to the tap
device ex
TL:DR: GNUTLS is liable to crash QEMU when live migration is run
with TLS enabled and a return path channel is present, if approx
64 GB of data is transferred. This is easily triggered in a 16 GB
VM with 4 CPUs, by running 'stress-ng --vm 4 --vm-bytes 80%' to
prevent convergance until 64 GB of RAM
When TLS 1.3 is negotiated on a TLS session, GNUTLS will perform
automatic rekeying of the session after 16 million records. This
is done for all algorithms except CHACHA20_POLY1305 which does
not require rekeying.
Unfortunately the rekeying breaks GNUTLS' promise that it is safe
to use a gnutls_s
Add a QIO_CHANNEL_FEATURE_CONCURRENT_IO feature flag.
If this is set on a QIOChannelTLS session object, the TLS
session will be marked as requiring thread safety, which
will activate the workaround for GNUTLS bug 1717 if needed.
Signed-off-by: Daniel P. Berrangé
---
include/io/channel.h | 1 +
We want some visibility on stderr when the GNUTLS thread
safety countermeasures are activated, to encourage people
to get the real fix deployed (once it exists). Some trace
points will also help if we see any further wierd crash
scenario we've not anticipated.
Reviewed-by: Daniel P. Berrangé
Sign
When either the postcopy or return path capabilities are
enabled, the migration code will use the primary channel
for bidirectional I/O.
If either of those capabilities are enabled, the migration
code needs to mark the channel as expecting concurrent I/O
in order to activate the thread safety work
On 18/07/2025 15.31, Laurent Vivier wrote:
The passt networking backend uses functions from the GIO library,
such as g_subprocess_launcher_new(), to manage its daemon process.
So, building with passt enabled requires GIO to be available.
If we enable passt and disable gio the build fails during
On Fri, Jul 18, 2025 at 10:52:33AM +0200, Paolo Abeni wrote:
Similar to virtio infra, vhost core maintains the features status
in the full extended format and allows the devices to implement
extended version of the getter/setter.
Note that 'protocol_features' are not extended: they are only
used
On Thu, Jul 17, 2025 at 9:14 PM Cornelia Huck wrote:
>
> On Tue, Jul 15 2025, Daniel P. Berrangé wrote:
>
> > On Tue, Jul 15, 2025 at 09:16:24AM -0700, Andrea Bolognani wrote:
> >> On Tue, Jul 15, 2025 at 05:02:54PM +0100, Daniel P. Berrangé wrote:
> >> > On Tue, Jul 15, 2025 at 05:44:25PM +0200,
On 7/18/25 3:01 PM, Stefano Garzarella wrote:
> On Fri, Jul 18, 2025 at 10:52:36AM +0200, Paolo Abeni wrote:
>> @@ -234,7 +234,8 @@ struct vhost_net *vhost_net_init(VhostNetOptions
>> *options)
>> int r;
>> bool backend_kernel = options->backend_type == VHOST_BACKEND_TYPE_KERNEL;
>> st
On 7/18/25 9:28 AM, Vasant Hegde wrote:
Alejandro, Sairaj,
On 7/17/2025 7:18 PM, Alejandro Jimenez wrote:
On 7/17/25 2:07 AM, Michael S. Tsirkin wrote:
On Thu, Jul 17, 2025 at 11:17:05AM +0530, Sairaj Kodilkar wrote:
On 7/16/2025 6:59 PM, Michael S. Tsirkin wrote:
On Wed, Jul 16, 202
On Fri, Jul 18, 2025 at 03:44:20PM +0200, Paolo Abeni wrote:
On 7/18/25 3:22 PM, Stefano Garzarella wrote:
On Fri, Jul 18, 2025 at 10:52:39AM +0200, Paolo Abeni wrote:
diff --git a/net/tap.c b/net/tap.c
index 23c6c118e7..2dfa843547 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -62,6 +62,8 @@ static
On Fri, Jul 18, 2025 at 03:31:10PM +0200, Laurent Vivier wrote:
> The passt networking backend uses functions from the GIO library,
> such as g_subprocess_launcher_new(), to manage its daemon process.
> So, building with passt enabled requires GIO to be available.
>
> If we enable passt and disabl
On 7/18/25 3:22 PM, Stefano Garzarella wrote:
> On Fri, Jul 18, 2025 at 10:52:39AM +0200, Paolo Abeni wrote:
>> diff --git a/net/tap.c b/net/tap.c
>> index 23c6c118e7..2dfa843547 100644
>> --- a/net/tap.c
>> +++ b/net/tap.c
>> @@ -62,6 +62,8 @@ static const int kernel_feature_bits[] = {
>> VIRT
When using a CXL Type 3 device together with a virtio 9p device in QEMU, the
9p device fails to initialize properly. The kernel reports the following:
virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
9pnet_virtio virtio0: probe with driver 9pnet_virtio failed with
Alejandro, Sairaj,
On 7/17/2025 7:18 PM, Alejandro Jimenez wrote:
>
>
> On 7/17/25 2:07 AM, Michael S. Tsirkin wrote:
>> On Thu, Jul 17, 2025 at 11:17:05AM +0530, Sairaj Kodilkar wrote:
>>>
>>>
>>> On 7/16/2025 6:59 PM, Michael S. Tsirkin wrote:
On Wed, Jul 16, 2025 at 06:26:37PM +0530, Sa
The passt networking backend uses functions from the GIO library,
such as g_subprocess_launcher_new(), to manage its daemon process.
So, building with passt enabled requires GIO to be available.
If we enable passt and disable gio the build fails during linkage with
undefined reference errors:
/
On Fri, Jul 18, 2025 at 10:52:39AM +0200, Paolo Abeni wrote:
When any host or guest GSO over UDP tunnel offload is enabled the
virtio net header includes the additional tunnel-related fields,
update the size accordingly.
Push the GSO over UDP tunnel offloads all the way down to the tap
device ex
Daniel P. Berrangé writes:
> On Fri, Jul 18, 2025 at 07:59:50AM +0200, Markus Armbruster wrote:
>> Markus Armbruster writes:
>>
>> > Adam Williamson writes:
>> >
>> >> In cfcacba an `error_report` was added to this file, but the
>> >> corresponding include of `qemu/error-report.h` was missed.
On Fri, Jul 18, 2025 at 10:52:36AM +0200, Paolo Abeni wrote:
Provide extended version of the features manipulation helpers,
and let the device initialization deal with the full features space,
adjusting the relevant format strings accordingly.
Signed-off-by: Paolo Abeni
---
v2 -> v3:
- use vir
On Fri, Jul 18, 2025 at 10:52:38AM +0200, Paolo Abeni wrote:
Tap devices support GSO over UDP tunnel offload. Probe for such
feature in a similar manner to other offloads.
GSO over UDP tunnel needs to be enabled in addition to a "plain"
offload (TSO or USO).
No need to check separately for the
Add a CLI argument that takes fnmatch(3)-style patterns as value and can
be specified many times. Only tests that match the pattern will be
executed. This argument is passed to unittest.main which takes the same
argument.
Signed-off-by: Manos Pitsidianakis
---
tests/functional/qemu_test/testcase
Add CLI arg to keep scratch files after test execution, equivalent to
setting QEMU_TEST_KEEP_SCRATCH env var.
Suggested-by: Alex Bennée
Signed-off-by: Manos Pitsidianakis
---
tests/functional/qemu_test/testcase.py | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git
Add CLI argument to list tests and exit.
Example output (current dir is build directory under root dir):
$ export PYTHONPATH=../python:../tests/functional
$ export QEMU_TEST_QEMU_BINARY="$(pwd)/qemu-system-aarch64"
$ ./pyvenv/bin/python3 ../tests/functional/test_aarch64_virt.py --list-tests
Pitsidianakis
---
Changes in v2:
- Fixed invalid -k value passing when -k was specified more than once
(thanks Paolo)
- Link to v1:
https://lore.kernel.org/qemu-devel/20250718-functional_tests_args-v1-0-54d4c6207...@linaro.org
---
Manos Pitsidianakis (3):
tests/functional: add --keep
On Fri, Jul 18, 2025 at 12:23:21PM +0200, Paolo Abeni wrote:
On 7/18/25 12:18 PM, Stefano Garzarella wrote:
On Fri, Jul 18, 2025 at 10:52:34AM +0200, Paolo Abeni wrote:
diff --git a/hw/virtio/virtio-qmp.c b/hw/virtio/virtio-qmp.c
index 3b6377cf0d..03c6163cf4 100644
--- a/hw/virtio/virtio-qmp.c
On 7/18/25 12:18 PM, Stefano Garzarella wrote:
> On Fri, Jul 18, 2025 at 10:52:34AM +0200, Paolo Abeni wrote:
>> diff --git a/hw/virtio/virtio-qmp.c b/hw/virtio/virtio-qmp.c
>> index 3b6377cf0d..03c6163cf4 100644
>> --- a/hw/virtio/virtio-qmp.c
>> +++ b/hw/virtio/virtio-qmp.c
>> @@ -325,6 +325,20 @
On Fri, Jul 18, 2025 at 10:52:34AM +0200, Paolo Abeni wrote:
Extend the VirtioDeviceFeatures struct with an additional u64
to track unknown features in the 64-127 bit range and decode
the full virtio features spaces for vhost and virtio devices.
Also add entries for the soon-to-be-supported virt
On Fri, Jul 18, 2025 at 12:37 PM Paolo Bonzini wrote:
>
> On 7/18/25 11:12, Manos Pitsidianakis wrote:
> > Add a CLI argument that takes fnmatch(3)-style patterns as value and can
> > be specified many times. Only tests that match the pattern will be
> > executed. This argument is passed to unitte
On 7/18/25 11:12, Manos Pitsidianakis wrote:
Add a CLI argument that takes fnmatch(3)-style patterns as value and can
be specified many times. Only tests that match the pattern will be
executed. This argument is passed to unittest.main which takes the same
argument.
Signed-off-by: Manos Pitsidia
On Thu, Jul 17, 2025 at 12:34:48PM +0200, Paolo Bonzini wrote:
> Date: Thu, 17 Jul 2025 12:34:48 +0200
> From: Paolo Bonzini
> Subject: [PATCH] target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
> X-Mailer: git-send-email 2.50.1
>
> KVM emulates the ARCH_CAPABILITIES on x86 for both Intel an
On Fri, Jul 18, 2025 at 12:20 PM Daniel P. Berrangé wrote:
>
> On Thu, Jul 17, 2025 at 01:34:13PM +0300, Manos Pitsidianakis wrote:
> > Add argument parsing to functional tests to improve developer experience
> > when running individual tests. All logs are printed to stdout
> > interspersed with T
On Thu, Jul 17, 2025 at 01:34:13PM +0300, Manos Pitsidianakis wrote:
> Add argument parsing to functional tests to improve developer experience
> when running individual tests. All logs are printed to stdout
> interspersed with TAP output.
>
> Example usage, assuming current build directory with q
Add a CLI argument that takes fnmatch(3)-style patterns as value and can
be specified many times. Only tests that match the pattern will be
executed. This argument is passed to unittest.main which takes the same
argument.
Signed-off-by: Manos Pitsidianakis
---
tests/functional/qemu_test/testcase
, 39 insertions(+), 6 deletions(-)
---
base-commit: 3656e761bcdd207b7759cdcd608212d2a6f9c12d
change-id: 20250718-functional_tests_args-12cdb5e56d84
prerequisite-change-id: 20250716-functional_tests_debug_arg-aa0a5f6b9375:v2
prerequisite-patch-id: 4ccc8f39ffb382d31c8e6450c43a5f8d177af044
--
γαῖα πυρί
Add CLI arg to keep scratch files after test execution, equivalent to
setting QEMU_TEST_KEEP_SCRATCH env var.
Suggested-by: Alex Bennée
Signed-off-by: Manos Pitsidianakis
---
tests/functional/qemu_test/testcase.py | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
Add CLI argument to list tests and exit.
Example output (current dir is build directory under root dir):
$ export PYTHONPATH=../python:../tests/functional
$ export QEMU_TEST_QEMU_BINARY="$(pwd)/qemu-system-aarch64"
$ ./pyvenv/bin/python3 ../tests/functional/test_aarch64_virt.py --list-tests
Tap devices support GSO over UDP tunnel offload. Probe for such
feature in a similar manner to other offloads.
GSO over UDP tunnel needs to be enabled in addition to a "plain"
offload (TSO or USO).
No need to check separately for the outer header checksum offload:
the kernel is going to support b
The virtio specifications allows for up to 128 bits for the
device features. Soon we are going to use some of the 'extended'
bits features (bit 64 and above) for the virtio net driver.
Represent the virtio features bitmask with a fixes size array, and
introduce a few helpers to help manipulate the
Leverage the kernel extended features manipulation ioctls(), if
available, and fallback to old ops otherwise. Error out when setting
extended features but kernel support is not available.
Note that extended support for get/set backend features is not needed,
as the only feature that can be changed
If the driver uses any of the extended features (i.e. 64 or above),
store the extended features range (64-127 bits).
At load time, let legacy features initialize the full features range
and pass it to the set helper; sub-states loading will have filled-up
the extended part as needed.
This is one
When any host or guest GSO over UDP tunnel offload is enabled the
virtio net header includes the additional tunnel-related fields,
update the size accordingly.
Push the GSO over UDP tunnel offloads all the way down to the tap
device extending the newly introduced NetFeatures struct, and
eventually
Provide extended version of the features manipulation helpers,
and let the device initialization deal with the full features space,
adjusting the relevant format strings accordingly.
Signed-off-by: Paolo Abeni
---
v2 -> v3:
- use virtio_features_andnot return value instead of virtio_features_em
The virtio specifications allows for up to 128 bits for the
device features. Soon we are going to use some of the 'extended'
bits features for the virtio net driver.
Add support to allow extended features negotiation on a per
devices basis. Devices willing to negotiated extended features
need to i
Extend the VirtioDeviceFeatures struct with an additional u64
to track unknown features in the 64-127 bit range and decode
the full virtio features spaces for vhost and virtio devices.
Also add entries for the soon-to-be-supported virtio net GSO over
UDP features.
Signed-off-by: Paolo Abeni
---
Use the extended types and helpers to manipulate the virtio_net
features.
Note that offloads are still 64bits wide, as per specification,
and extended offloads will be mapped into such range.
Signed-off-by: Paolo Abeni
---
v2 -> v3:
- rebased on top of 2deec9ab7d ("virtio-net: Move
virtio_
Update headers to include the virtio GSO over UDP tunnel features
Signed-off-by: Paolo Abeni
--
Note: while the relevant change are not into Linus's tree yet, they have
been merged in the net-next tree and they should land into the vanilla
tree during the next merge window.
---
include/standard-
The set_offload() argument list is already pretty long and
we are going to introduce soon a bunch of additional offloads.
Replace the offload arguments with a single struct and update
all the relevant call-sites.
No functional changes intended.
Signed-off-by: Paolo Abeni
---
Note: I maintained
Extend the features configuration space to 128 bits, and allow the
common read/write operation to access all of it.
On migration, save the 128 bit version of the features only if the
upper bits are non zero. Relay reset to clear all the feature
space before load.
Signed-off-by: Paolo Abeni
---
v
Similar to virtio infra, vhost core maintains the features status
in the full extended format and allows the devices to implement
extended version of the getter/setter.
Note that 'protocol_features' are not extended: they are only
used by vhost-user, and the latter device is not going to implement
Some virtualized deployments use UDP tunnel pervasively and are impacted
negatively by the lack of GSO support for such kind of traffic in the
virtual NIC driver.
The virtio_net specification recently introduced support for GSO over
UDP tunnel, and the kernel side of the implementation has been me
Hi Steve
I tested your patch which hit a problem under enable/disable nic mq
state(The full test scenario is live migration vm at local under
enable/disable vm nic mq state):
Run command: /qemu-img info /home/images/vm1.qcow2 --output=json
Error info: qemu-img: Could not open '/home/images/vm1.qco
On Fri, Jul 18, 2025 at 07:59:50AM +0200, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> > Adam Williamson writes:
> >
> >> In cfcacba an `error_report` was added to this file, but the
> >> corresponding include of `qemu/error-report.h` was missed. This
> >> only becomes apparent when
1 - 100 of 123 matches
Mail list logo
