* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
monitor: don't wake up qmp_dispatcher_co coroutine upon cleanup
rust: centralize config in workspace root
hw/char/serial: Remove unused prog_if compat property
target/i386: do not block singlestep for STI
target/i386: do not trigger IRQ shadow for LSS
target/i386/hvf: fix a compilation error
target/i386/emulate: remove rflags leftovers
rust/hpet: Support migration
rust/timer: Define NANOSECONDS_PER_SECOND binding as u64
rust/vmstate_test: Test varray with num field wrapped in BqlCell
rust: assertions: Support index field wrapped in BqlCell
vmstate: support varray for vmstate_clock!
rust/vmstate: Add support for field_exists checks
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 5 May 2025 15:26:40 +0000 (11:26 -0400)]
Merge tag 'migration-20250502-pull-request' of https://gitlab.com/peterx/qemu into staging
Migration pull request
- Prasad's few pre-requisite patches from multifd+postcopy enablement series
- Markus's fix on a latent bug for tls_authz setup
- Zhijian's latest RDMA series (includes the rdma soft-RoCE unit test)
- Jack's RDMA migration patch to re-enable ipv6
- Thomas's vmstate static checker update on rename field in acpi/ghes
- Peter's postcopy preempt optimization for locality hint
* tag 'migration-20250502-pull-request' of https://gitlab.com/peterx/qemu:
scripts/vmstate-static-checker.py: Allow new name for ghes_addr_le field
migration/rdma: Remove qemu_rdma_broken_ipv6_kernel
migration/postcopy: Spatial locality page hint for preempt mode
tests/qtest/migration: consolidate set capabilities
migration/ram: Implement save_postcopy_prepare()
migration: Add save_postcopy_prepare() savevm handler
migration: refactor channel discovery mechanism
migration/multifd: move macros to multifd header
migration: Fix latent bug in migrate_params_test_apply()
migration: Add qtest for migration over RDMA
migration: Unfold control_save_page()
migration/rdma: Remove redundant migration_in_postcopy checks
migration: disable RDMA + postcopy-ram
migration: check RDMA and capabilities are compatible on both sides
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 5 May 2025 15:26:28 +0000 (11:26 -0400)]
Merge tag 'pull-request-2025-04-30' of https://gitlab.com/thuth/qemu into staging
* Extend s390x diagnose call 308 subcode 10 to return more information
* Make valgrind support configurable
* Drop support for Python 3.8
* Some other misc cosmetic changes
* tag 'pull-request-2025-04-30' of https://gitlab.com/thuth/qemu:
docs/devel/build-environment: enhance MSYS2 instructions
hw/rtc/mc146818rtc: Drop pre-v3 migration stream support
meson.build: Put the D-Bus summary into the UI section
tests/functional/test_ppc64_pseries: Skip test_ppc64_linux_smt_boot if necessary
Drop support for Python 3.8
meson/configure: add 'valgrind' option & --{en, dis}able-valgrind flag
target/s390x: Return UVC cmd code, RC and RRC value when DIAG 308 Subcode 10 fails to enter secure mode
target/s390x: Introduce function when exiting PV
target/s390x: Introduce constant when checking if PV header couldn't be decrypted
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
monitor: don't wake up qmp_dispatcher_co coroutine upon cleanup
Since the commit 3e6bed61 ("monitor: cleanup detection of qmp_dispatcher_co
shutting down"), coroutine pointer qmp_dispatcher_co is set to NULL upon
cleanup. If a QMP command is sent after monitor_cleanup() (e.g. after
shutdown), this may lead to SEGFAULT on aio_co_wake(NULL).
As mentioned in the comment inside monitor_cleanup(), the intention is to
allow incoming requests while shutting down, but simply leave them
without any response. Let's do exactly that, and if qmp_dispatcher_co
coroutine pointer has already been set to NULL, let's simply skip the
aio_co_wake() part.
This property was added to preserve previous value when this was fixed
in version 2.1 but the last machine using it was already removed when
adding diva-gsp leaving this property unused and unnecessary.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Helge Deller <deller@gmx.de> Link: https://lore.kernel.org/r/20250502095524.DE1F355D264@zero.eik.bme.hu Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Mon, 15 Jul 2024 08:35:06 +0000 (10:35 +0200)]
target/i386: do not block singlestep for STI
STI will trigger a singlestep exception even if it has inhibit-IRQ
behavior. Do not suppress single-step for all IRQ-inhibiting
instructions, instead special case MOV SS and POP SS.
Cc: qemu-stable@nongnu.org Fixes: f0f0136abba ("target/i386: no single-step exception after MOV or POP SS", 2024-05-25) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Magnus Kulke [Tue, 29 Apr 2025 09:33:19 +0000 (11:33 +0200)]
target/i386/emulate: remove rflags leftovers
Fixes: c901905ea670 ("target/i386/emulate: remove flags_mask")
In c901905ea670 rflags have been removed from `x86_decode`, but there
were some leftovers.
Zhao Liu [Mon, 14 Apr 2025 14:49:42 +0000 (22:49 +0800)]
rust/hpet: Support migration
Based on commit 1433e38cc8 ("hpet: do not overwrite properties on
post_load"), add the basic migration support to Rust HPET.
The current migration implementation introduces multiple unsafe
callbacks. Before the vmstate builder, one possible cleanup approach is
to wrap callbacks in the vmstate binding using a method similar to the
vmstate_exist_fn macro.
However, this approach would also create a lot of repetitive code (since
vmstate has so many callbacks: pre_load, post_load, pre_save, post_save,
needed and dev_unplug_pending). Although it would be cleaner, it would
somewhat deviate from the path of the vmstate builder.
Therefore, firstly focus on completing the functionality of HPET, and
those current unsafe callbacks can at least clearly indicate the needed
functionality of vmstate. The next step is to consider refactoring
vmstate to move towards the vmstate builder direction.
Additionally, update rust.rst about Rust HPET can support migration.
Paolo Bonzini [Fri, 2 May 2025 08:56:06 +0000 (10:56 +0200)]
rust: assertions: Support index field wrapped in BqlCell
Currently, if the `num` field of a varray is not a numeric type, such as
being placed in a wrapper, the array variant of assert_field_type will
fail the check.
HPET currently wraps num_timers in BqlCell<>. Although BqlCell<> is not
necessary from strictly speaking, it makes sense for vmstate to respect
BqlCell.
The failure of assert_field_type is because it cannot convert BqlCell<T>
into usize for use as the index. Use a constant 0 instead for the index,
by avoiding $(...)? and extracting the common parts of
assert_field_type! into an internal case.
Commit message based on a patch by Zhao Liu <zhao1.liu@intel.com>.
Zhao Liu [Mon, 14 Apr 2025 14:49:35 +0000 (22:49 +0800)]
rust/vmstate: Add support for field_exists checks
Unfortunately, at present it's not possible to have a const
"with_exist_check" method to append test_fn after vmstate_struct (due
to error on "constant functions cannot evaluate destructors" for `F`).
Before the vmstate builder, the only way to support "test_fn" is to
extend vmstate_struct macro to add the such new optional member (and
fortunately, Rust can still parse the current expansion!).
Abstract the previous callback implementation of vmstate_validate into
a separate macro, and moves it before vmstate_struct for vmstate_struct
to call.
Note that there's no need to add any extra flag for a new test_fn added
in the VMStateField.
Thomas Huth [Tue, 29 Apr 2025 15:21:39 +0000 (17:21 +0200)]
scripts/vmstate-static-checker.py: Allow new name for ghes_addr_le field
ghes_addr_le has been renamed to hw_error_le in commit 652f6d86cbb
("acpi/ghes: better name the offset of the hardware error firmware").
Adjust the checker script to allow that changed field name.
I hit following error which testing migration in pure RoCE env:
"-incoming rdma:[::]:8089: RDMA ERROR: You only have RoCE / iWARP devices in your
systems and your management software has specified '[::]', but IPv6 over RoCE /
iWARP is not supported in Linux.#012'."
In our setup, we use rdma bind on ipv6 on target host, while connect from source
with ipv4, remove the qemu_rdma_broken_ipv6_kernel, migration just work
fine.
Checking the git history, the function was added since introducing of
rdma migration, which is more than 10 years ago. linux-rdma has
improved support on RoCE/iWARP for ipv6 over past years. There are a few fixes
back in 2016 seems related to the issue, eg: aeb76df46d11 ("IB/core: Set routable RoCE gid type for ipv4/ipv6 networks")
other fixes back in 2018, eg: 052eac6eeb56 RDMA/cma: Update RoCE multicast routines to use net namespace 8d20a1f0ecd5 RDMA/cma: Fix rdma_cm raw IB path setting for RoCE 9327c7afdce3 RDMA/cma: Provide a function to set RoCE path record L2 parameters 5c181bda77f4 RDMA/cma: Set default GID type as RoCE when resolving RoCE route 3c7f67d1880d IB/cma: Fix default RoCE type setting be1d325a3358 IB/core: Set RoCEv2 MGID according to spec 63a5f483af0e IB/cma: Set default gid type to RoCEv2
So remove the outdated function and it's usage.
Cc: Peter Xu <peterx@redhat.com> Cc: Li Zhijian <lizhijian@fujitsu.com> Cc: Yu Zhang <yu.zhang@ionos.com> Cc: Fabiano Rosas <farosas@suse.de> Cc: qemu-devel@nongnu.org Cc: linux-rdma@vger.kernel.org Cc: michael@flatgalaxy.com Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Tested-by: Li zhijian <lizhijian@fujitsu.com> Reviewed-by: Michael Galaxy <mrgalaxy@nvidia.com> Link: https://lore.kernel.org/r/20250402051306.6509-1-jinpu.wang@ionos.com
[peterx: some cosmetic changes] Signed-off-by: Peter Xu <peterx@redhat.com>
Peter Xu [Thu, 24 Apr 2025 22:07:05 +0000 (18:07 -0400)]
migration/postcopy: Spatial locality page hint for preempt mode
The preempt mode postcopy has been introduced for a while. From latency
POV, it should always win the vanilla postcopy.
However there's one thing missing when preempt mode is enabled right now,
which is the spatial locality hint when there're page requests from the
destination side.
In vanilla postcopy, as long as a page request was unqueued, it will update
the PSS of the precopy background stream, so that after a page request the
background thread will move the pages after whatever was requested. It's
pretty much a natural behavior when there's only one channel anyway, and
one scanner to send the pages.
Preempt mode didn't follow that, because preempt mode has its own channel
and its own PSS (which doesn't linearly scan the guest memory, but
dedicated to resolve page requested from destination). So the page request
process and the background migration process are completely separate.
This patch adds the hint explicitly for preempt mode. With that, whenever
the preempt mode receives a page request on the source, it will service the
remote page fault in the return path, then it'll provide a hint to the
background thread so that we'll start sending the pages right after the
requested ones in the background, assuming the follow up pages have a
higher chance to be accessed later.
NOTE: since the background migration thread and return path thread run
completely concurrently, it doesn't always mean the hint will be applied
every single time. For example, it's possible that the return path thread
receives multiple page requests in a row without the background thread
getting the chance to consume one. In such case, the preempt thread only
provide the hint if the previous hint has been consumed. After all,
there's no point queuing hints when we only have one linear scanner.
This could measureably improve the simple sequential memory access pattern
during postcopy (when preempt is on). For random accesses, I can measure a
slight increase of remote page fault latency from ~500us -> ~600us, that
could be a trade-off to have such hint mechanism, and after all that's
still greatly improved comparing to vanilla postcopy on random (~10ms).
The patch is verified by our QE team in a video streaming test case, to
reduce the pause of the video from ~1min to a few seconds when switching
over to postcopy with preempt mode.
tests/qtest/migration: consolidate set capabilities
Migration capabilities are set in multiple '.start_hook'
functions for various tests. Instead, consolidate setting
capabilities in 'migrate_start_set_capabilities()' function
which is called from the 'migrate_start()' function.
While simplifying the capabilities setting, it helps
to declutter the qtest sources.
Add a savevm handler for a module to opt-in sending extra sections right
before postcopy starts, and before VM is stopped.
RAM will start to use this new savevm handler in the next patch to do flush
and sync for multifd pages.
Note that we choose to do it before VM stopped because the current only
potential user is not sensitive to VM status, so doing it before VM is
stopped is preferred to enlarge any postcopy downtime.
It is still a bit unfortunate that we need to introduce such a new savevm
handler just for the only use case, however it's so far the cleanest.
The various logical migration channels don't have a
standardized way of advertising themselves and their
connections may be seen out of order by the migration
destination. When a new connection arrives, the incoming
migration currently make use of heuristics to determine
which channel it belongs to.
The next few patches will need to change how the multifd
and postcopy capabilities interact and that affects the
channel discovery heuristic.
Refactor the channel discovery heuristic to make it less
opaque and simplify the subsequent patches.
Li Zhijian [Tue, 11 Mar 2025 02:42:21 +0000 (10:42 +0800)]
migration: Add qtest for migration over RDMA
This qtest requires there is a RDMA(RoCE) link in the host.
In order to make the test work smoothly, introduce a
scripts/rdma-migration-helper.sh to detect existing RoCE link before
running the test.
Test will be skipped if there is no available RoCE link.
# Start of rdma tests
# Running /x86_64/migration/precopy/rdma/plain
ok 1 /x86_64/migration/precopy/rdma/plain # SKIP No rdma link available
# To enable the test:
# Run 'scripts/rdma-migration-helper.sh setup' with root to setup a new rdma/rxe link and rerun the test
# Optional: run 'scripts/rdma-migration-helper.sh clean' to revert the 'setup'
# End of rdma tests
Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: Stefan Hajnoczi <stefanha@gmail.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Message-ID: <20250311024221.363421-1-lizhijian@fujitsu.com>
[add 'head -1' to script, reformat test message] Signed-off-by: Fabiano Rosas <farosas@suse.de>
Li Zhijian [Wed, 5 Mar 2025 06:28:24 +0000 (14:28 +0800)]
migration: Unfold control_save_page()
control_save_page() is for RDMA only, unfold it to make the code more
clear.
In addition:
- Similar to other branches style in ram_save_target_page(), involve RDMA
only if the condition 'migrate_rdma()' is true.
- Further simplify the code by removing the RAM_SAVE_CONTROL_NOT_SUPP.
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Message-ID: <20250305062825.772629-6-lizhijian@fujitsu.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Li Zhijian [Wed, 5 Mar 2025 06:28:21 +0000 (14:28 +0800)]
migration: check RDMA and capabilities are compatible on both sides
Depending on the order of starting RDMA and setting capability,
they can be categorized into the following scenarios:
Source:
S1: [set capabilities] -> [Start RDMA outgoing]
Destination:
D1: [set capabilities] -> [Start RDMA incoming]
D2: [Start RDMA incoming] -> [set capabilities]
Previously, compatibility between RDMA and capabilities was verified only
in scenario D1, potentially causing migration failures in other situations.
For scenarios S1 and D1, we can seamlessly incorporate
migration_transport_compatible() to address compatibility between
channels and capabilities vs transport.
For scenario D2, ensure compatibility within migrate_caps_check().
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Message-ID: <20250305062825.772629-3-lizhijian@fujitsu.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
hw/rtc/mc146818rtc: Drop pre-v3 migration stream support
mc146818rtc's migration stream is at version 3 since commit 56038ef6234 ("RTC: Update the RTC clock only when reading it")
from 12 years ago, released in QEMU v1.3.0!
No versioned machines are that old, we can safely remove
support for older streams and the qdev_set_legacy_instance_id()
call.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250115210048.25396-1-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Thu, 24 Apr 2025 08:54:26 +0000 (10:54 +0200)]
tests/functional/test_ppc64_pseries: Skip test_ppc64_linux_smt_boot if necessary
The test_ppc64_linux_smt_boot function lacks the set_machine('pseries'),
so this test is currently failing in case the 'pseries' machine has not
been compiled into the binary. Add the check now to fix it.
Message-ID: <20250424085426.663377-1-thuth@redhat.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 25 Apr 2025 12:07:10 +0000 (14:07 +0200)]
Drop support for Python 3.8
Python 3.8 went "end of life" in October 2024 and Fedora 42 dropped
this version already, so the "python" CI job is currently failing.
Thus it's time to drop support for this Python version in QEMU, too.
While we're at it, also look for "python3.13" in the configure script.
Message-ID: <20250425120710.879518-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
meson/configure: add 'valgrind' option & --{en, dis}able-valgrind flag
Currently valgrind debugging support for coroutine stacks is enabled
unconditionally when valgrind/valgrind.h is found. There is no way
to disable valgrind support if valgrind.h is present in the build env.
This is bad for distros, as an dependency far down the chain may cause
valgrind.h to become installed, inadvertently enabling QEMU's valgrind
debugging support. It also means if a distro wants valgrind support
there is no way to mandate this.
The solution is to add a 'valgrind' build feature to meson and thus
configure script.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250425121713.1913424-1-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Kevin Wolf [Tue, 29 Apr 2025 15:56:54 +0000 (17:56 +0200)]
file-posix: Fix crash on discard_granularity == 0
Block devices that don't support discard have a discard_granularity of
0. Currently, this results in a division by zero when we try to make
sure that it's a multiple of request_alignment. Only try to update
bs->bl.pdiscard_alignment when we got a non-zero discard_granularity
from sysfs.
Fixes: f605796aae4 ('file-posix: probe discard alignment on Linux block devices') Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-ID: <20250429155654.102735-1-kwolf@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Gautam Gala [Wed, 23 Apr 2025 08:09:15 +0000 (10:09 +0200)]
target/s390x: Return UVC cmd code, RC and RRC value when DIAG 308 Subcode 10 fails to enter secure mode
Extend DIAG308 subcode 10 to return the UVC RC, RRC and command code
in bit positions 32-47, 16-31, and 0-15 of register R1 + 1 if the
function does not complete successfully (in addition to the
previously returned diag response code in bit position 47-63).
Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Gautam Gala <ggala@linux.ibm.com> Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Message-ID: <20250423080915.1048123-4-ggala@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Gautam Gala [Wed, 23 Apr 2025 08:09:14 +0000 (10:09 +0200)]
target/s390x: Introduce function when exiting PV
Replace an existing macro (s390_pv_cmd_exit) that looks like
a function with an actual function. The function will be used
when exiting PV instead of the macro.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Gautam Gala <ggala@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250423080915.1048123-3-ggala@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Gautam Gala [Wed, 23 Apr 2025 08:09:13 +0000 (10:09 +0200)]
target/s390x: Introduce constant when checking if PV header couldn't be decrypted
Introduce a named constant when checking the Set Secure Configuration parameters
UV call return code for the case where no valid host key was found and therefore
the PV header couldn't be decrypted (0x108).
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Gautam Gala <ggala@linux.ibm.com>
Message-ID: <20250423080915.1048123-2-ggala@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Merge into INDEX_op_{ld,st,ld2,st2}, where "2" indicates that two
inputs or outputs are required. This simplifies the processing of
i64/i128 depending on host word size.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We were using S32 | U32 for add2/sub2. But the ALGFI and SLGFI
insns that implement this both have uint32_t immediates.
This makes the composite range balanced and
enables use of -0xffffffff ... -0x80000001.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Do not clobber flags if they're live. Required in order
to perform register allocation on add/sub carry opcodes.
LA and AGHI are the same size, so use LA unconditionally.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
target/ppc: Use tcg_gen_addcio_tl for ADD and SUBF
Tested-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Using addci with two zeros as input in order to capture the value
of the carry-in bit is common. Special case this with sbb+neg so
that we do not have to load 0 into a register first.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tcg/optimize: With two const operands, prefer 0 in arg1
For most binary operands, two const operands fold.
However, the add/sub carry opcodes have a third input.
Prefer "reg, zero, const" since many risc hosts have a
zero register that can fit a "reg, reg, const" insn format.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Propagate known carry when possible, and simplify the opcodes
to not require carry-in when known. The result will be cleaned
up further by the subsequent liveness analysis pass.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tcg: Add add/sub with carry opcodes and infrastructure
Liveness needs to track carry-live state in order to
determine if the (hidden) output of the opcode is used.
Code generation needs to track carry-live state in order
to avoid clobbering cpu flags when loading constants.
So far, output routines and backends are unchanged.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tcg: Sink def, nb_iargs, nb_oargs loads in liveness_pass_1
Sink the sets of the def, nb_iargs, nb_oargs variables to
the default and do_not_remove labels. They're not really
needed beforehand, and it avoids preceding code from having
to keep them up-to-date. Note that def had *not* been kept
up-to-date; thankfully only def->flags had been used and
those bits were constant between opcode changes.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>