Pierrick Bouvier [Mon, 13 Jan 2025 12:35:34 +0000 (12:35 +0000)]
target/arm: change default pauth algorithm to impdef
Pointer authentication on aarch64 is pretty expensive (up to 50% of
execution time) when running a virtual machine with tcg and -cpu max
(which enables pauth=on).
The advice is always: use pauth-impdef=on.
Our documentation even mentions it "by default" in
docs/system/introduction.rst.
Thus, we change the default to use impdef by default. This does not
affect kvm or hvf acceleration, since pauth algorithm used is the one
from host cpu.
This change is retro compatible, in terms of cli, with previous
versions, as the semantic of using -cpu max,pauth-impdef=on, and -cpu
max,pauth-qarma3=on is preserved.
The new option introduced in previous patch and matching old default is
-cpu max,pauth-qarma5=on.
It is retro compatible with migration as well, by defining a backcompat
property, that will use qarma5 by default for virt machine <= 9.2.
Tested by saving and restoring a vm from qemu 9.2.0 into qemu-master
(10.0) for cpus neoverse-n2 and max.
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241219183211.3493974-3-pierrick.bouvier@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Mon, 13 Jan 2025 12:35:34 +0000 (12:35 +0000)]
tests/tcg/aarch64: force qarma5 for pauth-3 test
The pauth-3 test explicitly tests that a computation of the
pointer-authentication produces the expected result. This means that
it must be run with the QARMA5 algorithm.
Explicitly set the pauth algorithm when running this test, so that it
doesn't break when we change the default algorithm the 'max' CPU
uses.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Mon, 13 Jan 2025 12:35:34 +0000 (12:35 +0000)]
target/arm: Move minor arithmetic helpers out of helper.c
helper.c includes some small TCG helper functions used for mostly
arithmetic instructions. These are TCG only and there's no need for
them to be in the large and unwieldy helper.c. Move them out to
their own source file in the tcg/ subdirectory, together with the
op_addsub.h multiply-included template header that they use.
Since we are moving op_addsub.h, we take the opportunity to
give it a name which matches our convention for files which
are not true header files but which are #included from other
C files: op_addsub.c.inc.
(Ironically, this means that helper.c no longer contains
any TCG helper function definitions at all.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250110131211.2546314-1-peter.maydell@linaro.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Philippe Mathieu-Daudé [Mon, 13 Jan 2025 12:35:33 +0000 (12:35 +0000)]
tests/qtest/boot-serial-test: Initialize PL011 Control register
The tests using the PL011 UART of the virt and raspi machines
weren't properly enabling the UART and its transmitter previous
to sending characters. Follow the PL011 manual initialization
recommendation by setting the proper bits of the control register.
Update the ASM code prefixing:
*UART_CTRL = UART_ENABLE | TX_ENABLE;
to:
while (true) {
*UART_DATA = 'T';
}
Note, since commit 51b61dd4d56 ("hw/char/pl011: Warn when using
disabled transmitter") incomplete PL011 initialization can be
logged using the '-d guest_errors' command line option.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Mon, 13 Jan 2025 12:35:33 +0000 (12:35 +0000)]
tests/qtest/boot-serial-test: Reorder pair of instructions in PL011 test
In the next commit we are going to use a different value
for the $w1 register, maintaining the same $x2 value. In
order to keep the next commit trivial to review, set $x2
before $w1.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé [Mon, 13 Jan 2025 12:35:33 +0000 (12:35 +0000)]
tests/qtest/boot-serial-test: Reduce for() loop in PL011 tests
Since registers are not modified, we don't need
to refill their values. Directly jump to the previous
store instruction to keep filling the TXDAT register.
The equivalent C code remains:
while (true) {
*UART_DATA = 'T';
}
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tigran Sogomonian [Mon, 13 Jan 2025 12:35:32 +0000 (12:35 +0000)]
hw/misc: cast rpm to uint64_t
The value of an arithmetic expression
'rpm * NPCM7XX_MFT_PULSE_PER_REVOLUTION' is a subject
to overflow because its operands are not cast to
a larger data type before performing arithmetic. Thus, need
to cast rpm to uint64_t.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Tigran Sogomonian <tsogomonian@astralinux.ru> Reviewed-by: Patrick Leis <venture@google.com> Reviewed-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20241226130311.1349-1-tsogomonian@astralinux.ru Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Anastasia Belova [Mon, 13 Jan 2025 12:35:32 +0000 (12:35 +0000)]
hw/arm_sysctl: fix extracting 31th bit of val
1 << 31 is casted to uint64_t while bitwise and with val.
So this value may become 0xffffffff80000000 but only
31th "start" bit is required.
This is not possible in practice because the MemoryRegionOps
uses the default max access size of 4 bytes and so none
of the upper bytes of val will be set, but the bitfield
extract API is clearer anyway.
Use the bitfield extract() API instead.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Message-id: 20241220125429.7552-1-abelova@astralinux.ru Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: add clarification to commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Stefan Hajnoczi [Fri, 10 Jan 2025 18:39:19 +0000 (13:39 -0500)]
Merge tag 'migration-20250110-pull-request' of https://gitlab.com/farosas/qemu into staging
Migration pull request
- compression:
Shameer's fix for CONFIG_UADK build
Yuan Liu fixes for zero-page, QPL, qatzip
- multifd sync cleanups, prereq. for VFIO and postcopy work
- fixes for 9.2 regressions:
multifd with pre-9.0 -> post-9.1 migrations (#2720)
s390x migration (#2704)
- fix for assertions during paused migrations; rework of
late-block-activate logic (#2395, #686)
- fixes for compressed arrays creation and parsing, mostly affecting
s390x
# -----BEGIN PGP SIGNATURE-----
#
# iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmeBDgkQHGZhcm9zYXNA
# c3VzZS5kZQAKCRDHmNx0G+wxnSlUEACl31wY+77JxWnBva/eDDwnJ9HiCrqsoqaZ
# YIJJXNlk4lYJWNdZRt6p27exzWrQwm+kWKPECeCakgCMlfhnKCvejGq7iV/fJY4o
# D8hjE3t1htQ8mfblY1+bqzg3Rml59KwXxiqAwvlljbNWdkXruv026dq9vgJMzFhi
# ia043fOO1tYULIoawgmwmLEHnztht0v+ZTZ1v5KQbrH655tpxls/8kHc6v5PXEpA
# 3PSmCrCQh1dPtkYRjuJ9yHyfU+/T8tYwIjrU6VR1wQW7MBNkjtqNudaqAFiuyuqn
# P8gh4rAQrMhA9y+aq6xSoJP8XGkuOHxLQtlNutlmtbcQyZ7JqgLmK9ZLdoPf21sK
# //erV63NoyaciYB9Nk3NXflwroc6zyvo8A584kGNPwBznZOJLESP4SPvVm/nlE29
# vbyq8AWHRjFiqqf6P0ttQLAFkusZJzM1Y9UakF51hyVBX70yfqLG20XXZtIq/aZA
# GbBB2Fo0MIlbmWaur3vLsSzn7B8d++Gl9TTGcK/eIXJ1ANCuCxGv9fbXJQlP5F4I
# 3OAoSmAVJ2eqw4v0+2WMiEa8yUA5drNnDSI3VRkG+0K9jRfHKXki466/QQdGrNw7
# 8GuuzLBNai3gEKbavDU0Be73r982KjXeYXj7RuAkQfm0d4H7tiwtg91Cd1dPKfzh
# mhpmOFJDCg==
# =joNM
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 10 Jan 2025 07:09:45 EST
# gpg: using RSA key AA1B48B0A22326A5A4C364CFC798DC741BEC319D
# gpg: issuer "farosas@suse.de"
# gpg: Good signature from "Fabiano Rosas <farosas@suse.de>" [unknown]
# gpg: aka "Fabiano Almeida Rosas <fabiano.rosas@suse.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: AA1B 48B0 A223 26A5 A4C3 64CF C798 DC74 1BEC 319D
* tag 'migration-20250110-pull-request' of https://gitlab.com/farosas/qemu: (25 commits)
multifd: bugfix for incorrect migration data with qatzip compression
multifd: bugfix for incorrect migration data with QPL compression
multifd: bugfix for migration using compression methods
s390x: Fix CSS migration
migration: Fix arrays of pointers in JSON writer
migration: Dump correct JSON format for nullptr replacement
migration: Rename vmstate_info_nullptr
migration: Fix parsing of s390 stream
migration: Remove unused argument in vmsd_desc_field_end
migration: Add more error handling to analyze-migration.py
migration/block: Rewrite disk activation
migration/block: Fix possible race with block_inactive
migration/block: Apply late-block-active behavior to postcopy
migration/block: Make late-block-active the default
qmp/cont: Only activate disks if migration completed
migration: Add helper to get target runstate
migration/multifd: Fix compat with QEMU < 9.0
migration/multifd: Document the reason to sync for save_setup()
migration/multifd: Cleanup src flushes on condition check
migration/multifd: Remove sync processing on postcopy
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'qom-qdev-20250109' of https://github.com/philmd/qemu:
system: Inline machine_containers[] in qemu_create_machine_containers()
qom: remove unused InterfaceInfo::concrete_class field
qom: Remove container_get()
qom: Use object_get_container()
qom: Add object_get_container()
qdev: Use machine_get_container()
qdev: Add machine_get_container()
qdev: Make qdev_get_machine() not use container_get()
qdev: Implement qdev_create_fake_machine() for user emulation
qdev: Remove opts member
hw/pci: Use -1 as the default value for rombar
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Yuan Liu [Wed, 18 Dec 2024 09:14:13 +0000 (17:14 +0800)]
multifd: bugfix for incorrect migration data with qatzip compression
When QPL compression is enabled on the migration channel and the same
dirty page changes from a normal page to a zero page in the iterative
memory copy, the dirty page will not be updated to a zero page again
on the target side, resulting in incorrect memory data on the source
and target sides.
The root cause is that the target side does not record the normal pages
to the receivedmap.
The solution is to add ramblock_recv_bitmap_set_offset in target side
to record the normal pages.
Signed-off-by: Yuan Liu <yuan1.liu@intel.com> Reviewed-by: Jason Zeng <jason.zeng@intel.com> Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20241218091413.140396-4-yuan1.liu@intel.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Yuan Liu [Wed, 18 Dec 2024 09:14:12 +0000 (17:14 +0800)]
multifd: bugfix for incorrect migration data with QPL compression
When QPL compression is enabled on the migration channel and the same
dirty page changes from a normal page to a zero page in the iterative
memory copy, the dirty page will not be updated to a zero page again
on the target side, resulting in incorrect memory data on the source
and target sides.
The root cause is that the target side does not record the normal pages
to the receivedmap.
The solution is to add ramblock_recv_bitmap_set_offset in target side
to record the normal pages.
Signed-off-by: Yuan Liu <yuan1.liu@intel.com> Reviewed-by: Jason Zeng <jason.zeng@intel.com> Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20241218091413.140396-3-yuan1.liu@intel.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Yuan Liu [Wed, 18 Dec 2024 09:14:11 +0000 (17:14 +0800)]
multifd: bugfix for migration using compression methods
When compression is enabled on the migration channel and
the pages processed are all zero pages, these pages will
not be sent and updated on the target side, resulting in
incorrect memory data on the source and target sides.
The root cause is that all compression methods call
multifd_send_prepare_common to determine whether to compress
dirty pages, but multifd_send_prepare_common does not update
the IOV of MultiFDPacket_t when all dirty pages are zero pages.
The solution is to always update the IOV of MultiFDPacket_t
regardless of whether the dirty pages are all zero pages.
Fixes: 303e6f54f9 ("migration/multifd: Implement zero page transmission on the multifd thread.") Cc: qemu-stable@nongnu.org #9.0+ Signed-off-by: Yuan Liu <yuan1.liu@intel.com> Reviewed-by: Jason Zeng <jason.zeng@intel.com> Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20241218091413.140396-2-yuan1.liu@intel.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Fabiano Rosas [Thu, 9 Jan 2025 18:52:48 +0000 (15:52 -0300)]
migration: Fix arrays of pointers in JSON writer
Currently, if an array of pointers contains a NULL pointer, that
pointer will be encoded as '0' in the stream. Since the JSON writer
doesn't define a "pointer" type, that '0' will now be an uint8, which
is different from the original type being pointed to, e.g. struct.
(we're further calling uint8 "nullptr", but that's irrelevant to the
issue)
That mixed-type array shouldn't be compressed, otherwise data is lost
as the code currently makes the whole array have the type of the first
element:
In the above, the valid pointer at position 254 got lost among the
compressed array of nullptr.
While we could disable the array compression when a NULL pointer is
found, the JSON part of the stream still makes part of downtime, so we
should avoid writing unecessary bytes to it.
Keep the array compression in place, but if NULL and non-NULL pointers
are mixed break the array into several type-contiguous pieces :
Now each type-discontiguous region will become a new JSON entry. The
reader should interpret this as a concatenation of values, all part of
the same field.
Parsing the JSON with analyze-script.py now shows the proper data
being pointed to at the places where the pointer is valid and
"nullptr" where there's NULL:
Peter Xu [Thu, 9 Jan 2025 18:52:47 +0000 (15:52 -0300)]
migration: Dump correct JSON format for nullptr replacement
QEMU plays a trick with null pointers inside an array of pointers in a VMSD
field. See 07d4e69147 ("migration/vmstate: fix array of ptr with
nullptrs") for more details on why. The idea makes sense in general, but
it may overlooked the JSON writer where it could write nothing in a
"struct" in the JSON hints section.
We hit some analyze-migration.py issues on s390 recently, showing that some
of the struct field contains nothing, like:
It could be that we hit some null pointers there, and JSON was gone when
they're null pointers.
To fix it, instead of hacking around only at VMStateInfo level, do that
from VMStateField level, so that JSON writer can also be involved. In this
case, JSON writer will replace the pointer array (which used to be a
"struct") to be the real representation of the nullptr field.
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20250109185249.23952-6-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Fabiano Rosas [Thu, 9 Jan 2025 18:52:46 +0000 (15:52 -0300)]
migration: Rename vmstate_info_nullptr
Rename vmstate_info_nullptr from "uint64_t" to "nullptr". This vmstate
actually reads and writes just a byte, so the proper name would be
uint8. However, since this is a marker for a NULL pointer, it's
convenient to have a more explicit name that can be identified by the
consumers of the JSON part of the stream.
Change the name to "nullptr" and add support for it in the
analyze-migration.py script. Arbitrarily use the name of the type as
the value of the field to avoid the script showing 0x30 or '0', which
could be confusing for readers.
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20250109185249.23952-5-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Fabiano Rosas [Thu, 9 Jan 2025 18:52:45 +0000 (15:52 -0300)]
migration: Fix parsing of s390 stream
The parsing for the S390StorageAttributes section is currently leaving
an unconsumed token that is later interpreted by the generic code as
QEMU_VM_EOF, cutting the parsing short.
The migration will issue a STATTR_FLAG_DONE between iterations, which
the script consumes correctly, but there's a final STATTR_FLAG_EOS at
.save_complete that the script is ignoring. Since the EOS flag is a
u64 0x1ULL and the stream is big endian, on little endian hosts a byte
read from it will be 0x0, the same as QEMU_VM_EOF.
Fixes: 81c2c9dd5d ("tests/qtest/migration-test: Fix analyze-migration.py for s390x") Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20250109185249.23952-4-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Fabiano Rosas [Thu, 9 Jan 2025 18:52:43 +0000 (15:52 -0300)]
migration: Add more error handling to analyze-migration.py
The analyze-migration script was seen failing in s390x in misterious
ways. It seems we're reaching the VMSDFieldStruct constructor without
any fields, which would indicate an empty .subsection entry, a
VMSTATE_STRUCT with no fields or a vmsd with no fields. We don't have
any of those, at least not without the unmigratable flag set, so this
should never happen.
Add some debug statements so that we can see what's going on the next
time the issue happens.
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20250109185249.23952-2-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Peter Xu [Fri, 6 Dec 2024 23:08:38 +0000 (18:08 -0500)]
migration/block: Rewrite disk activation
This patch proposes a flag to maintain disk activation status globally. It
mostly rewrites disk activation mgmt for QEMU, including COLO and QMP
command xen_save_devices_state.
Backgrounds
===========
We have two problems on disk activations, one resolved, one not.
Problem 1: disk activation recover (for switchover interruptions)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When migration is either cancelled or failed during switchover, especially
when after the disks are inactivated, QEMU needs to remember re-activate
the disks again before vm starts.
It used to be done separately in two paths: one in qmp_migrate_cancel(),
the other one in the failure path of migration_completion().
It used to be fixed in different commits, all over the places in QEMU. So
these are the relevant changes I saw, I'm not sure if it's complete list:
- In 2016, commit fe904ea824 ("migration: regain control of images when
migration fails to complete")
- In 2017, commit 1d2acc3162 ("migration: re-active images while migration
been canceled after inactive them")
- In 2023, commit 6dab4c93ec ("migration: Attempt disk reactivation in
more failure scenarios")
Now since we have a slightly better picture maybe we can unify the
reactivation in a single path.
One side benefit of doing so is, we can move the disk operation outside QMP
command "migrate_cancel". It's possible that in the future we may want to
make "migrate_cancel" be OOB-compatible, while that requires the command
doesn't need BQL in the first place. This will already do that and make
migrate_cancel command lightweight.
Problem 2: disk invalidation on top of invalidated disks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is an unresolved bug for current QEMU. Link in "Resolves:" at the
end. It turns out besides the src switchover phase (problem 1 above), QEMU
also needs to remember block activation on destination.
Consider two continuous migration in a row, where the VM was always paused.
In that scenario, the disks are not activated even until migration
completed in the 1st round. When the 2nd round starts, if QEMU doesn't
know the status of the disks, it needs to try inactivate the disk again.
Here the issue is the block layer API bdrv_inactivate_all() will crash a
QEMU if invoked on already inactive disks for the 2nd migration. For
detail, see the bug link at the end.
Implementation
==============
This patch proposes to maintain disk activation with a global flag, so we
know:
- If we used to inactivate disks for migration, but migration got
cancelled, or failed, QEMU will know it should reactivate the disks.
- On incoming side, if the disks are never activated but then another
migration is triggered, QEMU should be able to tell that inactivate is
not needed for the 2nd migration.
We used to have disk_inactive, but it only solves the 1st issue, not the
2nd. Also, it's done in completely separate paths so it's extremely hard
to follow either how the flag changes, or the duration that the flag is
valid, and when we will reactivate the disks.
Convert the existing disk_inactive flag into that global flag (also invert
its naming), and maintain the disk activation status for the whole
lifecycle of qemu. That includes the incoming QEMU.
Put both of the error cases of source migration (failure, cancelled)
together into migration_iteration_finish(), which will be invoked for
either of the scenario. So from that part QEMU should behave the same as
before. However with such global maintenance on disk activation status, we
not only cleanup quite a few temporary paths that we try to maintain the
disk activation status (e.g. in postcopy code), meanwhile it fixes the
crash for problem 2 in one shot.
For freshly started QEMU, the flag is initialized to TRUE showing that the
QEMU owns the disks by default.
For incoming migrated QEMU, the flag will be initialized to FALSE once and
for all showing that the dest QEMU doesn't own the disks until switchover.
That is guaranteed by the "once" variable.
Peter Xu [Fri, 6 Dec 2024 23:08:37 +0000 (18:08 -0500)]
migration/block: Fix possible race with block_inactive
Src QEMU sets block_inactive=true very early before the invalidation takes
place. It means if something wrong happened during setting the flag but
before reaching qemu_savevm_state_complete_precopy_non_iterable() where it
did the invalidation work, it'll make block_inactive flag inconsistent.
For example, think about when qemu_savevm_state_complete_precopy_iterable()
can fail: it will have block_inactive set to true even if all block drives
are active.
Fix that by only update the flag after the invalidation is done.
No Fixes for any commit, because it's not an issue if bdrv_activate_all()
is re-entrant upon all-active disks - false positive block_inactive can
bring nothing more than "trying to active the blocks but they're already
active". However let's still do it right to avoid the inconsistent flag
v.s. reality.
Peter Xu [Fri, 6 Dec 2024 23:08:36 +0000 (18:08 -0500)]
migration/block: Apply late-block-active behavior to postcopy
Postcopy never cared about late-block-active. However there's no mention
in the capability that it doesn't apply to postcopy.
Considering that we _assumed_ late activation is always good, do that too
for postcopy unconditionally, just like precopy. After this patch, we
should have unified the behavior across all.
Peter Xu [Fri, 6 Dec 2024 23:08:35 +0000 (18:08 -0500)]
migration/block: Make late-block-active the default
Migration capability 'late-block-active' controls when the block drives
will be activated. If enabled, block drives will only be activated until
VM starts, either src runstate was "live" (RUNNING, or SUSPENDED), or it'll
be postponed until qmp_cont().
Let's do this unconditionally. There's no harm to delay activation of
block drives. Meanwhile there's no ABI breakage if dest does it, because
src QEMU has nothing to do with it, so it's no concern on ABI breakage.
IIUC we could avoid introducing this cap when introducing it before, but
now it's still not too late to just always do it. Cap now prone to
removal, but it'll be for later patches.
Peter Xu [Fri, 6 Dec 2024 23:08:34 +0000 (18:08 -0500)]
qmp/cont: Only activate disks if migration completed
As the comment says, the activation of disks is for the case where
migration has completed, rather than when QEMU is still during
migration (RUN_STATE_INMIGRATE).
Move the code over to reflect what the comment is describing.
Cc: Kevin Wolf <kwolf@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-Id: <20241206230838.1111496-3-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Peter Xu [Fri, 6 Dec 2024 23:08:33 +0000 (18:08 -0500)]
migration: Add helper to get target runstate
In 99% cases, after QEMU migrates to dest host, it tries to detect the
target VM runstate using global_state_get_runstate().
There's one outlier so far which is Xen that won't send global state.
That's the major reason why global_state_received() check was always there
together with global_state_get_runstate().
However it's utterly confusing why global_state_received() has anything to
do with "let's start VM or not".
Provide a helper to explain it, then we have an unified entry for getting
the target dest QEMU runstate after migration.
Fabiano Rosas [Fri, 13 Dec 2024 16:01:19 +0000 (13:01 -0300)]
migration/multifd: Fix compat with QEMU < 9.0
Commit f5f48a7891 ("migration/multifd: Separate SYNC request with
normal jobs") changed the multifd source side to stop sending data
along with the MULTIFD_FLAG_SYNC, effectively introducing the concept
of a SYNC-only packet. Relying on that, commit d7e58f412c
("migration/multifd: Don't send ram data during SYNC") later came
along and skipped reading data from SYNC packets.
The issue arises that QEMUs < 9.0 still send data along with SYNC, but
QEMUs > 9.1 don't gather that data anymore. This leads to various
kinds of migration failures due to desync/missing data.
Stop checking for a SYNC packet on the destination and unconditionally
unfill the packet.
>From now on:
old -> new:
the source sends data + sync, destination reads normally
new -> new:
source sends only sync, destination reads zeros
new -> old:
source sends only sync, destination reads zeros
CC: qemu-stable@nongnu.org Fixes: d7e58f412c ("migration/multifd: Don't send ram data during SYNC")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2720 Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-Id: <20241213160120.23880-2-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Peter Xu [Fri, 6 Dec 2024 22:47:55 +0000 (17:47 -0500)]
migration/multifd: Document the reason to sync for save_setup()
It's not straightforward to see why src QEMU needs to sync multifd during
setup() phase. After all, there's no page queued at that point.
For old QEMUs, there's a solid reason: EOS requires it to work. While it's
clueless on the new QEMUs which do not take EOS message as sync requests.
One will figure that out only when this is conditionally removed. In fact,
the author did try it out. Logically we could still avoid doing this on
new machine types, however that needs a separate compat field and that can
be an overkill in some trivial overhead in setup() phase.
Let's instead document it completely, to avoid someone else tries this
again and do the debug one more time, or anyone confused on why this ever
existed.
Peter Xu [Fri, 6 Dec 2024 22:47:53 +0000 (17:47 -0500)]
migration/multifd: Remove sync processing on postcopy
Multifd never worked with postcopy, at least yet so far.
Remove the sync processing there, because it's confusing, and they should
never appear. Now if RAM_SAVE_FLAG_MULTIFD_FLUSH is observed, we fail hard
instead of trying to invoke multifd code.
RAM_SAVE_FLAG_MULTIFD_FLUSH message should always be correlated to a sync
request on src. Unify such message into one place, and conditionally send
the message only if necessary.
Peter Xu [Fri, 6 Dec 2024 22:47:50 +0000 (17:47 -0500)]
migration/multifd: Allow to sync with sender threads only
Teach multifd_send_sync_main() to sync with threads only.
We already have such requests, which is when mapped-ram is enabled with
multifd. In that case, no SYNC messages will be pushed to the stream when
multifd syncs the sender threads because there's no destination threads
waiting for that. The whole point of the sync is to make sure all threads
finished their jobs.
So fundamentally we have a request to do the sync in different ways:
- Either to sync the threads only,
- Or to sync the threads but also with the destination side.
Mapped-ram did it already because of the use_packet check in the sync
handler of the sender thread. It works.
However it may stop working when e.g. VFIO may start to reuse multifd
channels to push device states. In that case VFIO has similar request on
"thread-only sync" however we can't check a flag because such sync request
can still come from RAM which needs the on-wire notifications.
Paving way for that by allowing the multifd_send_sync_main() to specify
what kind of sync the caller needs. We can use it for mapped-ram already.
Peter Xu [Fri, 6 Dec 2024 22:47:49 +0000 (17:47 -0500)]
migration/multifd: Further remove the SYNC on complete
Commit 637280aeb2 ("migration/multifd: Avoid the final FLUSH in
complete()") stopped sending the RAM_SAVE_FLAG_MULTIFD_FLUSH flag at
ram_save_complete(), because the sync on the destination side is not
needed due to the last iteration of find_dirty_block() having already
done it.
However, that commit overlooked that multifd_ram_flush_and_sync() on the
source side is also not needed at ram_save_complete(), for the same
reason.
Moreover, removing the RAM_SAVE_FLAG_MULTIFD_FLUSH but keeping the
multifd_ram_flush_and_sync() means that currently the recv threads will
hang when receiving the MULTIFD_FLAG_SYNC message, waiting for the
destination sync which only happens when RAM_SAVE_FLAG_MULTIFD_FLUSH is
received.
Luckily, multifd is still all working fine because recv side cleanup
code (mostly multifd_recv_sync_main()) is smart enough to make sure even
if recv threads are stuck at SYNC it'll get kicked out. And since this
is the completion phase of migration, nothing else will be sent after
the SYNCs.
This needs to be fixed because in the future VFIO will have data to push
after ram_save_complete() and we don't want the recv thread to be stuck
in the MULTIFD_FLAG_SYNC message.
Remove the unnecessary (and buggy) invocation of
multifd_ram_flush_and_sync().
For very old binaries (multifd_flush_after_each_section==true), the
flush_and_sync is still needed because each EOS received on destination
will enforce all-channel sync once.
Stable branches do not need this patch, as no real bug I can think of
that will go wrong there.. so not attaching Fixes to be clear on the
backport not needed.
Shameer Kolothum [Tue, 3 Dec 2024 12:49:43 +0000 (12:49 +0000)]
migration/multifd: Fix compile error caused by page_size usage
>From Commit 90fa121c6c07 ("migration/multifd: Inline page_size and
page_count") onwards page_size is not part of MutiFD*Params but uses
an inline constant instead.
However, it missed updating an old usage, causing a compile error.
Philippe Mathieu-Daudé [Thu, 2 Jan 2025 13:53:15 +0000 (14:53 +0100)]
system: Inline machine_containers[] in qemu_create_machine_containers()
Only qemu_create_machine_containers() uses the
machine_containers[] array, restrict the scope
to this single user.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250102211800.79235-9-philmd@linaro.org>
Paolo Bonzini [Tue, 7 Jan 2025 11:13:08 +0000 (12:13 +0100)]
qom: remove unused InterfaceInfo::concrete_class field
The "concrete_class" field of InterfaceClass is only ever written, and as far
as I can tell is not particularly useful when debugging either; remove it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20250107111308.21886-1-pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Peter Xu [Thu, 21 Nov 2024 19:22:02 +0000 (14:22 -0500)]
qom: Remove container_get()
Now there's no user of container_get(), remove it.
Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241121192202.4155849-14-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Xu [Thu, 21 Nov 2024 19:22:01 +0000 (14:22 -0500)]
qom: Use object_get_container()
Use object_get_container() whenever applicable across the tree.
Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241121192202.4155849-13-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Xu [Thu, 21 Nov 2024 19:22:00 +0000 (14:22 -0500)]
qom: Add object_get_container()
Add a helper to fetch a root container (under object_get_root()). Sanity
check on the type of the object.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-ID: <20241121192202.4155849-12-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Xu [Thu, 21 Nov 2024 19:21:59 +0000 (14:21 -0500)]
qdev: Use machine_get_container()
Use machine_get_container() whenever applicable across the tree.
Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241121192202.4155849-11-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Xu [Thu, 21 Nov 2024 19:21:58 +0000 (14:21 -0500)]
qdev: Add machine_get_container()
Add a helper to fetch machine containers. Add some sanity check around.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-ID: <20241121192202.4155849-10-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Xu [Tue, 29 Oct 2024 21:16:04 +0000 (17:16 -0400)]
qdev: Make qdev_get_machine() not use container_get()
Currently, qdev_get_machine() has a slight misuse on container_get(), as
the helper says "get a container" but in reality the goal is to get the
machine object. It is still a "container" but not strictly.
Note that it _may_ get a container (at "/machine") in our current unit test
of test-qdev-global-props.c before all these changes, but it's probably
unexpected and worked by accident.
Switch to an explicit object_resolve_path_component(), with a side benefit
that qdev_get_machine() can happen a lot, and we don't need to split the
string ("/machine") every time. This also paves way for making the helper
container_get() never try to return a non-container at all.
Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241121192202.4155849-9-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Philippe Mathieu-Daudé [Thu, 2 Jan 2025 13:50:19 +0000 (14:50 +0100)]
qdev: Implement qdev_create_fake_machine() for user emulation
When a QDev instance is realized, qdev_get_machine() ends up called.
In the next commit, qdev_get_machine() will require a "machine"
container to be always present. To satisfy this QOM containers design,
Implement qdev_create_fake_machine() which creates a fake "machine"
container for user emulation.
On system emulation, qemu_create_machine() is called from qemu_init().
For user emulation, since the TCG accelerator always calls
tcg_init_machine(), we use it to hook our fake machine creation.
Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250102211800.79235-2-philmd@linaro.org>
Akihiko Odaki [Mon, 12 Feb 2024 10:20:29 +0000 (19:20 +0900)]
hw/pci: Use -1 as the default value for rombar
vfio_pci_size_rom() distinguishes whether rombar is explicitly set to 1
by checking dev->opts, bypassing the QOM property infrastructure.
Use -1 as the default value for rombar to tell if the user explicitly
set it to 1. The property is also converted from unsigned to signed.
-1 is signed so it is safe to give it a new meaning. The values in
[2 ^ 31, 2 ^ 32) become invalid, but nobody should have typed these
values by chance.
Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250104-reuse-v18-13-c349eafd8673@daynix.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Stefan Hajnoczi [Thu, 9 Jan 2025 13:39:31 +0000 (08:39 -0500)]
Merge tag 'pull-xenfv-20250109-1' of https://gitlab.com/dwmw2/qemu into staging
Xen emulation fixes
# -----BEGIN PGP SIGNATURE-----
#
# iQJGBAABCAAwFiEEMUsIrNDeSBEzpfKGm+mA/QrAFUQFAmd/qNYSHGR3bXdAYW1h
# em9uLmNvLnVrAAoJEJvpgP0KwBVEtHsP/1qdpeVDCW1LAdGsOl9vixBXTR5/85G4
# m1KilpAPyxla8WfChRIagIdSAYGP5gN+yzbZ74AGb8HxumqJdl0bj6Gtqms2r8EQ
# 4T7IU1iNONDkncApkHdQW9BdKg4Atq3dY8dEaN1UxzCfRjHC/KS5vHPN3OzGKqJ1
# tAk8wOcDtp7cfW+utw2ssjVR14cfJLQCR7/ehBfeFkC0DSd8p/yTJ31bFnLyPpBn
# vh03MrslqV+h47D0uQxKwx5rtvNQhhIc/eRR/RymY3BSzAqRiyed/hTvsrRy4y/Z
# EXB8ACQ6U2Ikrj//VXimSTx5aQDeGIU8nD6zvNRWZ1rTmTtD3n5dOxL2U9U5DBHb
# TtlYhyochV6zO76mbINyjkSkGdj8ZZgF+5w5IIEhjazfHdWDuMdG0IjcRxl0r2Qz
# 4jaoVjxMUT/MLI4noSVYFF29/aWYxsk/nsYCPOM2X4WuzK4/ragIWbpZZqOIFn4X
# NyEc7xD2z9iL3MZe0Ygsa1eRpi/Gak0ih6W/u6ngON2EGESdF4T+CI+zTp6I4xtp
# jOrAGltp6012pRJibHrKKdpnTYuQCRj3kSFAEP+JhNSBDUhbZ5lJWTnxiW7BkBO4
# BujmX3TMFsdt4jDqNQzht84Tgf4JEAYbGCks9msFcoYdZovKcyG3kgfZyAVfEap2
# kvCgGk7JMz1A
# =5kvA
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 09 Jan 2025 05:45:42 EST
# gpg: using RSA key 314B08ACD0DE481133A5F2869BE980FD0AC01544
# gpg: issuer "dwmw@amazon.co.uk"
# gpg: Good signature from "David Woodhouse <dwmw@amazon.co.uk>" [unknown]
# gpg: aka "David Woodhouse <dwmw@amazon.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 314B 08AC D0DE 4811 33A5 F286 9BE9 80FD 0AC0 1544
* tag 'pull-xenfv-20250109-1' of https://gitlab.com/dwmw2/qemu:
hw/xen: Check if len is 0 before memcpy()
hw/i386/pc: Fix level interrupt sharing for Xen event channel GSI
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Thu, 9 Jan 2025 13:34:01 +0000 (08:34 -0500)]
Merge tag 'pull-loongarch-20250109' of https://gitlab.com/bibo-mao/qemu into staging
loongarch queue
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQQNhkKjomWfgLCz0aQfewwSUazn0QUCZ39pJgAKCRAfewwSUazn
# 0YpMAQCNV9KJJ8f8EaXAw5a87mnmlcP0vRi5gZiyv1ZV9gRqPgEAhzCn/rnzpzd+
# H3B1fRlD1xmaQ8IqRugQ4vfDBd9CyQY=
# =OG4d
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 09 Jan 2025 01:13:58 EST
# gpg: using EDDSA key 0D8642A3A2659F80B0B3D1A41F7B0C1251ACE7D1
# gpg: Good signature from "bibo mao <maobibo@loongson.cn>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 7044 3A00 19C0 E97A 31C7 13C4 8E86 8FB7 A176 9D4C
# Subkey fingerprint: 0D86 42A3 A265 9F80 B0B3 D1A4 1F7B 0C12 51AC E7D1
* tag 'pull-loongarch-20250109' of https://gitlab.com/bibo-mao/qemu:
hw/intc/loongarch_extioi: Add irq routing support from physical id
hw/intc/loongarch_extioi: Remove num-cpu property
hw/intc/loongarch_extioi: Get cpu number from possible_cpu_arch_ids
target/loongarch: Only support 64bit pte width
hw/loongarch/boot: Support Linux raw boot image
hw/core/loader: Use ssize_t for efi zboot unpacker
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
David Woodhouse [Thu, 19 Dec 2024 16:10:30 +0000 (16:10 +0000)]
hw/i386/pc: Fix level interrupt sharing for Xen event channel GSI
The system GSIs are not designed for sharing. One device might assert a
shared interrupt with qemu_set_irq() and another might deassert it, and
the level from the first device is lost.
This could be solved by refactoring the x86 GSI code to use an OrIrq
device, but that still wouldn't be ideal.
The best answer would be to have a 'resample' callback which is invoked
when the interrupt is acked at the interrupt controller, and causes the
devices to re-trigger the interrupt if it should still be pending. This
is the model that VFIO in Linux uses, with a 'resampler' eventfd that
actually unmasks the interrupt on the hardware device and thus triggers
a new interrupt from it if needed.
As things stand, QEMU currently doesn't use that VFIO interface
correctly, and just bashes on the resampler for every MMIO access to the
device "just in case". Which requires unmapping and trapping the MMIO
while an interrupt is pending!
For the Xen callback GSI, QEMU does something similar — a flag is set
which triggers a poll on *every* vmexst to see if the GSI should be
deasserted.
Proper resampler support would solve all of that, but is a task for
later which has already been on the TODO list for a while.
Since the Xen event channel GSI support *already* has hooks into the PC
gsi_handler() code for routing GSIs to PIRQs, we can use that for a
simpler bug fix.
So... remember the externally-driven state of the line (from e.g. PCI
INTx) and set the logical OR of that with the GSI. As a bonus, we now
only need to enable the polling of vcpu_info on vmexit if the Xen
callback GSI is the *only* reason the corresponding line is asserted.
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2731 Fixes: ddf0fd9ae1fd ("hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Bibo Mao [Mon, 6 Jan 2025 07:36:26 +0000 (15:36 +0800)]
hw/intc/loongarch_extioi: Remove num-cpu property
Since cpu number can be acquired from possible_cpu_arch_ids(),
num-cpu property is not necessary. Here remove num-cpu property
for object TYPE_LOONGARCH_EXTIOI_COMMON object.
Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Bibo Mao [Tue, 31 Dec 2024 10:07:18 +0000 (18:07 +0800)]
target/loongarch: Only support 64bit pte width
iFrom LoongArch Reference Manual pte width can be 64bit, 128bit
or more. Instead real hardware only supports 64bit pte width.
For 12bit pte, there is no detail definition for all 128bit
from manual.
Here only 64bit pte width is supported for simplicity, will add
this in later if real hw support it and there is definition for
all the bits from manual.
Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Jiaxun Yang [Thu, 2 Jan 2025 22:47:21 +0000 (22:47 +0000)]
hw/core/loader: Use ssize_t for efi zboot unpacker
Convert to use sszie_t to represent size internally to avoid
large image overflowing the size.
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Stefan Hajnoczi [Wed, 8 Jan 2025 16:38:20 +0000 (11:38 -0500)]
Merge tag 'pull-request-2025-01-08' of https://gitlab.com/thuth/qemu into staging
* Fix compilation problem in s390x tcg tests
* Remove obsolete versioned s390x machine types 2.4 up to 2.8
* Remove deprecated -runas command line option
* Fix the x86_64_hotplug_cpu functional test
* tag 'pull-request-2025-01-08' of https://gitlab.com/thuth/qemu:
tests/functional/test_x86_64_hotplug_cpu: Fix race condition during unplug
docs/about/deprecated: Remove paragraph about initial deprecation in 2.10
Remove the deprecated "-runas" command line option
hw/s390x: Remove the "adapter_routes_max_batch" property from the flic
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.8 machine type
hw/s390x: Remove the cpu_model_allowed flag and related code
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.7 machine type
hw/s390x/css-bridge: Remove the "css_dev_path" property
hw/s390x/ipl: Remove the "iplbext_migration" property
hw/s390x: Remove the "ri_allowed" switch
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.6 machine type
hw/s390x/s390-skeys: Remove the "migration-enabled" property
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine types
tests/tcg/s390x: Use the SLOF libc headers for the multiarch tests
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Thomas Huth [Tue, 7 Jan 2025 11:52:45 +0000 (12:52 +0100)]
tests/functional/test_x86_64_hotplug_cpu: Fix race condition during unplug
When unplugging the CPU, the test tries to check for a successful
unplug by changing to the /sys/devices/system/cpu/cpu1 directory
to see whether that fails. However, the "cd" could be faster than
the unplug operation in the kernel, so there is a race condition
and the test sometimes fails here.
Fix it by trying to change the directory in a loop until the the
CPU has really been unplugged.
While we're at it, also add a "cd .." before unplugging to make
the console output a little bit less confusing (since the path
is echoed in the shell prompt).
Reported-by: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20250107115245.52755-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 3 Jan 2025 14:57:02 +0000 (15:57 +0100)]
docs/about/deprecated: Remove paragraph about initial deprecation in 2.10
When we introduced the deprecation rule of keeping deprecated features
for two more releases, we had to state that we would not remove features
by surprise that had already been marked as deprecated before. Nowadays,
this paragraph is not needed anymore, so we can remove it now.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250103145702.597139-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 3 Jan 2025 15:54:11 +0000 (16:54 +0100)]
Remove the deprecated "-runas" command line option
It has been marked as deprecated two releases ago, so it should
be fine now to remove this command line option.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250103155411.721759-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 3 Jan 2025 14:42:30 +0000 (15:42 +0100)]
hw/s390x: Remove the cpu_model_allowed flag and related code
Now that the last machine type that disabled cpu_model_allowed has
been removed, we can also remove the cpu_model_allowed flag itself
and all the related conditional code.
Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-9-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 3 Jan 2025 14:42:28 +0000 (15:42 +0100)]
hw/s390x/css-bridge: Remove the "css_dev_path" property
Now that the s390-ccw-virtio-2.6 and older machine types have been
removed, the "css_dev_path" property of the css-bridge is also not
used anymore and thus can be removed.
This way we finally get rid of the problem that has been described
in: https://gitlab.com/qemu-project/qemu/-/issues/2213
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-7-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 3 Jan 2025 14:42:26 +0000 (15:42 +0100)]
hw/s390x: Remove the "ri_allowed" switch
Only s390-ccw-virtio-2.6 and older used to set this switch to "off",
for newer machine types it is always enabled. Since we removed the
old machine types now, we can also remove the switch in the code and
assume that it is always enabled now.
Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-5-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 3 Jan 2025 14:42:24 +0000 (15:42 +0100)]
hw/s390x/s390-skeys: Remove the "migration-enabled" property
This property was only set to "off" by the old s390-ccw-virtio-2.4
machine type which has now been removed. So we can now remove the
property and the related code, too.
Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-3-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 3 Jan 2025 14:42:23 +0000 (15:42 +0100)]
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine types
They are older than 6 years, so according to our machine support
policy, they can be removed now.
This removes the requirements for the storage keys "migration-enabled"
property which will be removed in the next patch. It also removes
the code that sets "max_revision" to 0 for some CCW devices, but the
relating code in virtio-ccw.c indicates that 0 could have also been in
use for other machines types < 5.1, so further clean-up for code related
to "max_revision" won't be done yet (see also commit d55f518248f -
"virtio: skip legacy support check on machine types less than 5.1").
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-2-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Ilya Leoshkevich [Mon, 16 Dec 2024 13:37:56 +0000 (14:37 +0100)]
tests/tcg/s390x: Use the SLOF libc headers for the multiarch tests
Compiling the s390x tests on Fedora, which has the s390x cross-compiler
installed, fails with:
In file included from qemu/tests/tcg/s390x/console.c:8:
qemu/tests/tcg/s390x/../../../pc-bios/s390-ccw/sclp.c:11:10: fatal error: string.h: No such file or directory
11 | #include <string.h>
This is because Fedora does not have a cross-libc. Since console.c
already uses the SLOF libc implementation, add the respective headers
to the include path.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241216133819.78583-1-iii@linux.ibm.com> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Stefan Hajnoczi [Mon, 6 Jan 2025 14:39:02 +0000 (09:39 -0500)]
Merge tag 'qga-pull-2025-01-06' of https://github.com/kostyanf14/qemu into staging
qga-pull-2025-01-06
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEwsLBCepDxjwUI+uE711egWG6hOcFAmd7vqMACgkQ711egWG6
# hOffRxAAotgBsE+o8fsZ2tfOKNPekW0hlw/hceDMJRA2UwOSPfw1fXfw59w4Pnfr
# 4xwMC6O8Lu9ohBCBWHUvh3261gJgXQkLASbbzmF2oewfXZyvPXQI8nz78Ol3LBTG
# gL8lwaBci3YuFtc+2/55VdQsWUqtrRMvBW9WSXTEC+0dQJv+VzblXlEF7hQkKppT
# oGiHQL7pEA1UP7bRo4TyaoDnc8a+xz1J+vtEZUZghtreT7I3ELai/PFdo0U99fkf
# HZfjyj2sHCZto+tAokjBcqf2RXDRqUVRsn3GgC1MQbh1LRdfShmhCTbgYYk/1MmD
# 0xwiqAsw814W25299LM3xP2LHPm1jKtkZyCyuSXme9QtN9mC3F0TipR+HMRErAj0
# GQTBOJ0LinZsx5U/+ih4/qPj7RRov+SFzpVxBV3NUkpneVFp5FQgOo4n8l+h57ap
# fmkZ6/hb8itn2oux7S9v/LkcmWE3FqThKO6qMXOhBhQDCKpICz8liYO/tPdB4x1Q
# /HHQ9oon0A2eQw/53AYqz0SoazOqNtadg/hsQ11OHDExUjdp4M6hyxtmrJEQz4Et
# AFvIby98lJZCZ1u65dv/Prb+gW0E8AQ5Ib0jJllAm7tL/GjVyhbRlUl8S9R2uTcZ
# Gsb6e3DMBOny/lR9+2M4rCyCqXM58gTohuqtcXvAe8l2a3h23B4=
# =uk2Q
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 06 Jan 2025 06:29:39 EST
# gpg: using RSA key C2C2C109EA43C63C1423EB84EF5D5E8161BA84E7
# gpg: Good signature from "Kostiantyn Kostiuk (Upstream PR sign) <kkostiuk@redhat.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: C2C2 C109 EA43 C63C 1423 EB84 EF5D 5E81 61BA 84E7
* tag 'qga-pull-2025-01-06' of https://github.com/kostyanf14/qemu:
qemu-ga: Optimize freeze-hook script logic of logging error
qga: implement a 'guest-get-load' command
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Dehan Meng [Wed, 25 Dec 2024 08:37:44 +0000 (16:37 +0800)]
qemu-ga: Optimize freeze-hook script logic of logging error
Make sure the error log of fsfreeze hooks
when freeze/thaw/snapshot could be logged
to system logs if the default logfile of
qga can't be written or other situations
Signed-off-by: Dehan Meng <demeng@redhat.com> Reviewed-by: Yan Vugenfirer <yvugenfi@redhat.com> Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-ID: <20241225083744.277374-1-demeng@redhat.com> Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Windows has no native equivalent API, but it would be possible to
simulate it as illustrated here (BSD-3-Clause):
https://github.com/giampaolo/psutil/pull/1485
This is left as an exercise for future contributors.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-ID: <20241202121927.864335-1-berrange@redhat.com> Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Stefan Hajnoczi [Fri, 3 Jan 2025 14:14:11 +0000 (09:14 -0500)]
Merge tag 'qtest-20250102-pull-request' of https://gitlab.com/farosas/qemu into staging
Qtest pull request
- migration-test: fix UADK build, reinstate postcopy tests and other cleanups
- a couple of memory leak fixes for bios-tables-test and virtio-iommu-test
- drop dead code from fw_cfg-test
# -----BEGIN PGP SIGNATURE-----
#
# iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmd3DSMQHGZhcm9zYXNA
# c3VzZS5kZQAKCRDHmNx0G+wxnUy5EACPnvy3U2jen2Cc5Hke69byCQtMkDTAJHH5
# xlwTLoTEF25AXMjLyee9vM4MoDHl+EUaGd3zmmAu2/P5/zOHWrBh9VbkFKDDvJJS
# XTVSZ0Iv9a0LDGKsv74Pk7LUZCEanr9a0qpfYTFPuwUh9yu7pd4QeYpbEdwzKzX6
# TMpJTYOE5gUTgP6X8Ir6u3po8DChfE9Eb+Z3LhRU7S+Xi3FoUWRFgRzuvXhXLkf3
# SPNEA27XCaqWQjG8SfQ9yhafrEz9OIGq39Q2unSJ8Df8riYurrdhxYrWNZ/6URQi
# /sYoBJZ2IMBzLg4cVOWXXQwdFkmU+0LUYPOANy6MrYRXl1QJtWway3eHOj+ZlkIH
# r2ulAJWAXqIQ3Ki6Dv3TYCg0/snF8arFzmdsaAbn0M8YYQB7XAlcqHus5axEMIVO
# 0VG7rXctRyH2h7DFfKeW/G1aaK5ox+/0aJoVhjmFJSlYZ2DUx+htfsPlIJmwhRRF
# i61VaOw7NsrHsW0fEgTRurQBVVuZ2/nJT8saJwvXpFiJu0X1GQ6lmKQNlWqm5h6C
# JyLc096+vOG0Cqih7p+M3NvKTHNQZQzUPSLJU2UXItPDPv1oAmFrHpVlBQiUD37I
# h/2R6vxZIY5ei2ECFITnl+LaV4MNjGExpeOEi020KSLEz9Y8nk+i5E+4oDUct93z
# wAsWLadmxg==
# =sLkH
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 02 Jan 2025 17:03:15 EST
# gpg: using RSA key AA1B48B0A22326A5A4C364CFC798DC741BEC319D
# gpg: issuer "farosas@suse.de"
# gpg: Good signature from "Fabiano Rosas <farosas@suse.de>" [unknown]
# gpg: aka "Fabiano Almeida Rosas <fabiano.rosas@suse.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: AA1B 48B0 A223 26A5 A4C3 64CF C798 DC74 1BEC 319D
* tag 'qtest-20250102-pull-request' of https://gitlab.com/farosas/qemu:
qtest/fw-cfg: remove compiled out code
tests/qtest/migration: Re-enable postcopy tests
tests/migration: Drop arch_[source|target]
tests/qtest/virtio-iommu-test: Don't pass uninitialized data into qtest_memwrite
tests/qtest/bios-tables-test: Free tables at dump_aml_files
tests/qtest/migration: Initialize buffer in probe_o_direct_support
tests/qtest/migration: Do proper cleanup in the dirty_limit test
tests/qtest/migration: Fix compile errors when CONFIG_UADK is set
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Fabiano Rosas [Wed, 18 Dec 2024 19:22:22 +0000 (16:22 -0300)]
tests/qtest/migration: Re-enable postcopy tests
Postcopy tests have been inadvertently disabled since commit 124a3c58b8 ("tests/qtest/migration: Move ufd_version_check to
utils"). That commit moved the ufd_version_check() function to another
file but failed to make sense of the ifdefs and includes:
The <sys/syscall> include was incorrectly dropped. It is needed to
pull in <asm/unistd.h> for __NR_userfaultfd.
The <sys/ioctl.h> was moved under the wrong ifdef.
Fixes: 124a3c58b8 ("tests/qtest/migration: Move ufd_version_check to utils") Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-Id: <20241218192223.10551-2-farosas@suse.de>
Peter Xu [Mon, 16 Dec 2024 16:14:13 +0000 (11:14 -0500)]
tests/migration: Drop arch_[source|target]
Coverity complained about them. These two variables are never used now
after commit 832c732c5d ("migration-test: Create arch_opts"), and/or commit 34cc54fb35 ("tests/qtest/migration-test: Use custom asm bios for ppc64").
Fabiano Rosas [Mon, 9 Dec 2024 20:44:25 +0000 (17:44 -0300)]
tests/qtest/virtio-iommu-test: Don't pass uninitialized data into qtest_memwrite
Valgrind complains about:
Use of uninitialised value of size 8
&
Conditional jump or move depends on uninitialised value(s)
both at:
at 0x5265931: _itoa_word (_itoa.c:180)
by 0x527EEC7: __vfprintf_internal (vfprintf-internal.c:1687)
by 0x528C8B0: __vsprintf_internal (iovsprintf.c:96)
by 0x526B920: sprintf (sprintf.c:30)
by 0x1296C7: qtest_memwrite (libqtest.c:1273)
by 0x193C04: send_map (virtio-iommu-test.c:125)
by 0x194392: test_attach_detach (virtio-iommu-test.c:214)
by 0x17BDE7: run_one_test (qos-test.c:181)
by 0x4B0699D: test_case_run (gtestutils.c:2900)
by 0x4B0699D: g_test_run_suite_internal (gtestutils.c:2988)
by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005)
by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005)
by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005)
Uninitialised value was created by a stack allocation
at 0x193AFD: send_map (virtio-iommu-test.c:103)
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20241209204427.17763-5-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Fabiano Rosas [Mon, 9 Dec 2024 20:44:23 +0000 (17:44 -0300)]
tests/qtest/migration: Initialize buffer in probe_o_direct_support
Valgrind complains about the probe_o_direct_support() function reading
from an uninitialized buffer. For probing O_DIRECT support we don't
actually need to write to the file, just make sure the pwrite call
doesn't reject the write. Still, write zeroes to the buffer to
suppress the warning.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20241209204427.17763-3-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Stefan Hajnoczi [Thu, 2 Jan 2025 14:35:06 +0000 (09:35 -0500)]
Merge tag 'pull-request-2025-01-02' of https://gitlab.com/thuth/qemu into staging
* Update year in copyright statements
* Convert the VNC test to the functional framework
* Improve and update the ppc64_hv functional test
* Fix broken rx_gdbsim and arm_quanta_gsj functional tests
* tag 'pull-request-2025-01-02' of https://gitlab.com/thuth/qemu:
tests/functional/test_arm_quanta_gsj: Fix broken test
tests/functional/test_rx_gdbsim: Use stable URL for test_linux_sash
tests/functional/test_ppc64_hv: Update to Alpine 3.21.0
tests/functional/test_ppc64_hv: Update repo management
tests/functional/test_ppc64_hv: Simplify console handling
tests/functional: Extract the find_free_ports() function into a helper file
tests/functional/test_vnc: Remove the test_no_vnc test
tests/functional/test_vnc: Do not use a hard-coded VNC port
tests/functional: Convert the vnc test
docs: update copyright date to the year 2025
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Thomas Huth [Thu, 2 Jan 2025 07:30:35 +0000 (08:30 +0100)]
tests/functional/test_arm_quanta_gsj: Fix broken test
ASSET_IMAGE needs to be prefixed with "self." ... this bug
apparently went in unnoticed because the test is not run by
default.
Message-ID: <20250102073403.36328-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Philippe Mathieu-Daudé [Sun, 29 Dec 2024 08:34:19 +0000 (09:34 +0100)]
tests/functional/test_rx_gdbsim: Use stable URL for test_linux_sash
Yoshinori said [*] URL references on OSDN were stable, but they
appear not to be. Mirror the artifacts on GitHub to avoid failures
while testing on CI.
Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Reported-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-ID: <20200630202631.7345-1-f4bug@amsat.org>
[huth: Adapt the patch to the new version in the functional framework]
Message-ID: <20241229083419.180423-1-huth@tuxfamily.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Nicholas Piggin [Fri, 20 Dec 2024 02:46:17 +0000 (12:46 +1000)]
tests/functional/test_ppc64_hv: Update to Alpine 3.21.0
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20241220024617.1968556-5-npiggin@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
`setup-apkrepos` can be used to set repos rather than open-coding URLs.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20241220024617.1968556-4-npiggin@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Since functional tests have character-based console output parsing,
there is no need for strange hacks to work around old line-based.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20241220024617.1968556-3-npiggin@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Wed, 18 Dec 2024 13:14:38 +0000 (14:14 +0100)]
tests/functional: Extract the find_free_ports() function into a helper file
We'll need this functionality in other functional tests, too, so
let's extract it into the qemu_test module.
Also add an __enter__ and __exit__ function that can be used for
using this functionality in a locked context, so that tests that
are running in parallel don't try to compete for the same ports
later.
Also make sure to only use ports in the "Dynamic Ports" range
(see https://www.rfc-editor.org/rfc/rfc6335) and "randomize" the
start of the probed range with the PID of the test process to
further avoid possible clashes with other competing processes.
Message-ID: <20241218131439.255841-5-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Wed, 18 Dec 2024 13:14:36 +0000 (14:14 +0100)]
tests/functional/test_vnc: Remove the test_no_vnc test
This test matches exactly the first three lines of the following
test_no_vnc_change_password test, so there is exactly zero additional
test coverage in here.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20241218131439.255841-3-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Wed, 18 Dec 2024 13:14:37 +0000 (14:14 +0100)]
tests/functional/test_vnc: Do not use a hard-coded VNC port
Two tests here are using the hard-coded VNC port :0 ... if there
is already a QEMU or other program running that is using this
port, the tests will be failing. Fortunately, QEMU can also
auto-detect a free port with the "to=..." parameter, so let's
use that for the tests to avoid the problem.
Message-ID: <20241218131439.255841-4-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Wed, 18 Dec 2024 13:14:35 +0000 (14:14 +0100)]
tests/functional: Convert the vnc test
Nothing thrilling in here, it's just a straight forward conversion.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241218131439.255841-2-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Stefan Hajnoczi [Wed, 1 Jan 2025 20:17:07 +0000 (15:17 -0500)]
Merge tag 'hw-misc-20241231' of https://github.com/philmd/qemu into staging
Misc HW patches queue
- Allow more than 4 legacy IRQs on Generic PCI Express Bridge (Alexander)
- Add MMIO-based Inter-VM shared memory device 'ivshmem-flat' (Gustavo)
- Use UHCI register definitions (Guenter)
- Propagate CPU endianness to microblaze_load_kernel (Philippe)
- Mark x86/TriCore devices as little-endian, OpenRISC/SPARC as big (Philippe)
- Don't set callback_opaque NULL in fw_cfg_modify_bytes_read (Shameer)
- Simplify non-KVM checks on AMD IOMMU XTSup feature (Philippe)
- Trivial cleanups on xilinx_ethlite, vmcoreinfo, qxl (Philippe, Hyman)
- Move USB-HCD-XHCI msi/msix properties from NEC to superclass (Phil)
- Redesign of main thread event handling due to macOS Cocoa (Phil)
- Introduce ParavirtualizedGraphics.Framework support 'apple-gfx' (Phil)
- Pad short Ethernet frames on macOS vmnet (William)
* tag 'hw-misc-20241231' of https://github.com/philmd/qemu: (29 commits)
hw/display/qxl: Do not use C99 // comments
net/vmnet: Pad short Ethernet frames
MAINTAINERS: Add myself as maintainer for apple-gfx, reviewer for HVF
hw/display/apple-gfx: Adds configurable mode list
hw/display/apple-gfx: Adds PCI implementation
hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support
ui & main loop: Redesign of system-specific main thread event handling
hw/usb/hcd-xhci: Unimplemented/guest error logging for port MMIO
hw/usb/hcd-xhci-pci: Move msi/msix properties from NEC to superclass
hw/block/virtio-blk: Replaces request free function with g_free
hw/i386/amd_iommu: Simplify non-KVM checks on XTSup feature
hw/misc/vmcoreinfo: Rename opaque pointer as 'opaque'
hw/misc/vmcoreinfo: Declare QOM type using DEFINE_TYPES macro
fw_cfg: Don't set callback_opaque NULL in fw_cfg_modify_bytes_read()
hw/net/xilinx_ethlite: Rename rxbuf -> port_index
hw/net/xilinx_ethlite: Correct maximum RX buffer size
hw/net/xilinx_ethlite: Update QOM style
hw/net/xilinx_ethlite: Remove unuseful debug logs
hw/net/xilinx_ethlite: Convert some debug logs to trace events
hw/sparc: Mark devices as big-endian
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
William Hooper [Sat, 6 Jan 2024 22:35:46 +0000 (14:35 -0800)]
net/vmnet: Pad short Ethernet frames
At least on macOS 12.7.2, vmnet doesn't pad Ethernet frames, such as the
host's ARP replies, to the minimum size (60 bytes before the frame check
sequence) defined in IEEE Std 802.3-2022, so guests' Ethernet device
drivers may drop them with "frame too short" errors.
This patch calls eth_pad_short_frame() to add padding, as in net/tap.c
and net/slirp.c. Thanks to Bin Meng, Philippe Mathieu-Daudé, and Phil
Dennis-Jordan for reviewing earlier versions.
Signed-off-by: William Hooper <wsh@wshooper.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2058 Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>
Message-ID: <20241102205653.30476-1-wsh@wshooper.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
projects / users / dwmw2 / qemu.git / log