Re: [PULL 00/25] Migration 20230726 patches
On 7/26/23 05:14, Juan Quintela wrote: The following changes since commit 6cb2011fedf8c4e7b66b4a3abd6b42c1bae99ce6: Update version for v8.1.0-rc1 release (2023-07-25 20:09:05 +0100) are available in the Git repository at: https://gitlab.com/juan.quintela/qemu.git tags/migration-20230726-pull-request for you to fetch changes up to 697c4c86ab515a728ffb2adc2c3c04b22fa9210f: migration/rdma: Split qemu_fopen_rdma() into input/output functions (2023-07-26 10:55:56 +0200) Migration Pull request Hi This is the migration PULL request. It is the same than yesterday with proper PULL headers. It pass CI. It contains: - Fabiano rosas trheadinfo cleanups - Hyman Huang dirtylimit changes - Part of my changes - Peter Xu documentation - Tejus updato to migration descriptions - Wei want improvements for postocpy and multifd setup Please apply. Thanks, Juan. --- Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/8.1 as appropriate. r~
Re: [RFC PATCH-for-8.1] accel: Remove HAX accelerator
On 6/24/23 01:08, Philippe Mathieu-Daudé wrote:
HAX is deprecated since commits 73741fda6c ("MAINTAINERS: Abort
HAXM maintenance") and 90c167a1da ("docs/about/deprecated: Mark
HAXM in QEMU as deprecated"), released in v8.0.0.
Per the QEMU deprecation policy, we shouldn't remove it before
QEMU release v8.2.0. However per the latest HAXM release (v7.8),
the latest QEMU supported is v7.2:
Note: Up to this release, HAXM supports QEMU from 2.9.0 to 7.2.0.
(https://github.com/intel/haxm/releases/tag/v7.8.0)
The next commit (https://github.com/intel/haxm/commit/da1b8ec072)
added:
HAXM v7.8.0 is our last release and we will not accept
pull requests or respond to issues after this.
As of commit b455ce4c2f, it became very hard to build and test
HAXM. Its previous maintainers made it clear they won't help.
It doesn't seem to be a very good use of QEMU maintainers to
spend their time in a dead project. Save our time by removing
this orphan zombie code before the QEMU v8.2 release.
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS |8 -
docs/about/build-platforms.rst|2 +-
docs/about/deprecated.rst |6 -
docs/about/removed-features.rst |9 +-
docs/system/introduction.rst |3 -
meson.build |7 -
include/exec/poison.h |1 -
include/hw/core/cpu.h |2 +-
include/sysemu/hax.h | 49 -
include/sysemu/hw_accel.h |1 -
target/i386/hax/hax-accel-ops.h | 31 -
target/i386/hax/hax-i386.h| 98 --
target/i386/hax/hax-interface.h | 369 --
target/i386/hax/hax-posix.h | 61 -
target/i386/hax/hax-windows.h | 88 --
accel/stubs/hax-stub.c| 24 -
hw/intc/apic_common.c |3 +-
softmmu/cpus.c|6 -
softmmu/vl.c |6 -
target/i386/hax/hax-accel-ops.c | 105 --
target/i386/hax/hax-all.c | 1141 -
target/i386/hax/hax-mem.c | 323 -
target/i386/hax/hax-posix.c | 305 -
target/i386/hax/hax-windows.c | 485 ---
accel/stubs/meson.build |1 -
meson_options.txt |2 -
qemu-options.hx |8 +-
.../ci/org.centos/stream/8/x86_64/configure |1 -
scripts/meson-buildoptions.sh |3 -
target/i386/hax/meson.build |7 -
target/i386/meson.build |1 -
31 files changed, 13 insertions(+), 3143 deletions(-)
delete mode 100644 include/sysemu/hax.h
delete mode 100644 target/i386/hax/hax-accel-ops.h
delete mode 100644 target/i386/hax/hax-i386.h
delete mode 100644 target/i386/hax/hax-interface.h
delete mode 100644 target/i386/hax/hax-posix.h
delete mode 100644 target/i386/hax/hax-windows.h
delete mode 100644 accel/stubs/hax-stub.c
delete mode 100644 target/i386/hax/hax-accel-ops.c
delete mode 100644 target/i386/hax/hax-all.c
delete mode 100644 target/i386/hax/hax-mem.c
delete mode 100644 target/i386/hax/hax-posix.c
delete mode 100644 target/i386/hax/hax-windows.c
delete mode 100644 target/i386/hax/meson.build
Reviewed-by: Richard Henderson
r~
Re: [PATCH v4 10/10] accel/tcg: include cs_base in our hash calculations
On 5/23/23 05:50, Alex Bennée wrote:
static inline uint32_t qemu_xxhash5(uint64_t ab, uint64_t cd, uint32_t e)
{
-return qemu_xxhash7(ab, cd, e, 0, 0);
+return qemu_xxhash8(ab, cd, e, 0, 0);
}
static inline uint32_t qemu_xxhash6(uint64_t ab, uint64_t cd, uint32_t e,
uint32_t f)
{
-return qemu_xxhash7(ab, cd, e, f, 0);
+return qemu_xxhash8(ab, cd, e, f, 0);
+}
The last two arguments are 32 bit. Better as
qemu_xxhash8(ab, cd, 0, e, f);
r~
Re: [PATCH v3 10/10] hmp: Deprecate 'singlestep' member of StatusInfo
On 4/17/23 18:40, Peter Maydell wrote: The 'singlestep' member of StatusInfo has never done what the QMP documentation claims it does. What it actually reports is whether TCG is working in "one guest instruction per translation block" mode. We no longer need this field for the HMP 'info status' command, as we've moved that information to 'info jit'. It seems unlikely that anybody is monitoring the state of this obscure TCG setting via QMP, especially since QMP provides no means for changing the setting. So simply deprecate the field, without providing any replacement. Until we do eventually delete the member, correct the misstatements in the QAPI documentation about it. If we do find that there are users for this, then the most likely way we would provide replacement access to the information would be to put the accelerator QOM object at a well-known path such as /machine/accel, which could then be used with the existing qom-set and qom-get commands. Signed-off-by: Peter Maydell --- For v3: because we're only deprecating the existing member, not trying to provide a replacement with a new name, we don't need to update the iotests that use the command. (We will when we eventually drop the deprecated member.) --- docs/about/deprecated.rst | 14 ++ qapi/run-state.json | 14 +++--- 2 files changed, 25 insertions(+), 3 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v3 07/10] accel/tcg: Report one-insn-per-tb in 'info jit', not 'info status'
On 4/17/23 18:40, Peter Maydell wrote: Currently we report whether the TCG accelerator is in 'one-insn-per-tb' mode in the 'info status' output. This is a pretty minor piece of TCG specific information, and we want to deprecate the 'singlestep' field of the associated QMP command. Move the 'one-insn-per-tb' reporting to 'info jit'. We don't need a deprecate-and-drop period for this because the HMP interface has no stability guarantees. Signed-off-by: Peter Maydell --- The new 'accelerator settings' subsection of the output currently only has one item, but it would be a place to put other stuff, eg if we wanted to mention whether split-wx is enabled. --- accel/tcg/monitor.c | 14 ++ softmmu/runstate-hmp-cmds.c | 5 ++--- 2 files changed, 16 insertions(+), 3 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v3 03/10] accel/tcg: Use one_insn_per_tb global instead of old singlestep global
On 4/17/23 18:40, Peter Maydell wrote: The only place left that looks at the old 'singlestep' global variable is the TCG curr_cflags() function. Replace the old global with a new 'one_insn_per_tb' which is defined in tcg-all.c and declared in accel/tcg/internal.h. This keeps it restricted to the TCG code, unlike 'singlestep' which was available to every file in the system and defined in multiple different places for softmmu vs linux-user vs bsd-user. While we're making this change, use qatomic_read() and qatomic_set() on the accesses to the new global, because TCG will read it without holding a lock. Signed-off-by: Peter Maydell --- In discussion on v2, we talked about combining this with the 'nochain' flag so as to have a single 'tcg_cflags_global' that held the flags for the current (one_insn_per_tb, nochain) state. I have not attempted that here, because it's a little tricky: * util/log.c is built into some binaries that don't have an accelerator at all (the tools), so it can't simply call current_accel() to get the TCG accelerator Ah ha, yes, tricky. * the initial value of the logging flags is set before the TCG accelerator is even created So I leave that to somebody else to have a go at if they like. --- accel/tcg/internal.h | 2 ++ include/exec/cpu-common.h | 2 -- accel/tcg/cpu-exec.c | 2 +- accel/tcg/tcg-all.c | 6 -- bsd-user/main.c | 1 - linux-user/main.c | 1 - softmmu/globals.c | 1 - 7 files changed, 7 insertions(+), 8 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v3 03/10] accel/tcg: Use one_insn_per_tb global instead of old singlestep global
On 4/17/23 18:40, Peter Maydell wrote:
@@ -219,8 +221,8 @@ static void tcg_set_one_insn_per_tb(Object *obj, bool
value, Error **errp)
{
TCGState *s = TCG_STATE(obj);
s->one_insn_per_tb = value;
-/* For the moment, set the global also: this changes the behaviour */
-singlestep = value;
+/* Set the global also: this changes the behaviour */
+qatomic_set(_insn_per_tb, value);
}
Oh, one question: is it worth having the TCGState member at all?
Seems like these accessors could work just fine with only the global.
r~
Re: [PATCH v2 03/10] tcg: Use one-insn-per-tb accelerator property in curr_cflags()
On 4/13/23 18:24, Peter Maydell wrote:
On Mon, 3 Apr 2023 at 19:33, Richard Henderson
wrote:
On 4/3/23 07:46, Peter Maydell wrote:
uint32_t curr_cflags(CPUState *cpu)
{
uint32_t cflags = cpu->tcg_cflags;
+TCGState *tcgstate = TCG_STATE(current_accel());
As mentioned against the cover, this is a very hot path.
We should try for something less expensive. Perhaps as simple as
return cpu->tcg_cflags | tcg_cflags_global;
where cpu->tcg_cflags is updated with cpu->singlestep_enabled.
I feel like that introduces atomicity issues. If I'm reading
the code right, curr_cflags() is called without any kind
of lock held. At the moment we get away with this because
'singlestep' is an int and is always going to be atomically
updated. If we make tcg_cflags_global a value which might have
multiple bits set or not set I'm not entirely sure what the
right way is to handle the reads and writes of it.
qatomic_read() here, will dtrt for no tearing on the read.
(Not that we should have expected one anyway, for uint32_t.)
I think we can assume we have the iothread lock at any
point where we want to change either 'singlestep' or
the 'nochain' option, at least.
Indeed, it can only be changed by the monitor, under user control, so even without a lock
there's no real race there.
Using qatomic_set(, new_value) is sufficient to match the qatomic_read() for no
tearing. Concurrent threads will see the old value or the new value, but not garbage,
which is just fine.
We probably need to kick all cpus, so that they come out of long-running TB chains to see
the new value and re-translate.
r~
Re: [PATCH v2 09/10] qapi/run-state.json: Fix missing newline at end of file
On 4/3/23 07:46, Peter Maydell wrote: The run-state.json file is missing a trailing newline; add it. Signed-off-by: Peter Maydell --- Noticed this because my editor wanted to add the newline when I touched the file for the following patch... --- qapi/run-state.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 08/10] hmp: Report 'one-insn-per-tb', not 'single step mode', in 'info status' output
On 4/3/23 07:46, Peter Maydell wrote: The HMP 'info status' output includes "(single step mode)" when we are running with TCG one-insn-per-tb enabled. Change this text to "(one insn per TB)" to match the new command line option names. We don't need to have a deprecation/transition plan for this, because we make no guarantees about stability of HMP output. Signed-off-by: Peter Maydell --- softmmu/runstate-hmp-cmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 07/10] hmp: Add 'one-insn-per-tb' command equivalent to 'singlestep'
On 4/3/23 07:46, Peter Maydell wrote: The 'singlestep' HMP command is confusing, because it doesn't actually have anything to do with single-stepping the CPU. What it does do is force TCG emulation to put one guest instruction in each TB, which can be useful in some situations. Create a new HMP command 'one-insn-per-tb', so we can document that 'singlestep' is just a deprecated synonym for it, and eventually perhaps drop it. We aren't obliged to do deprecate-and-drop for HMP commands, but it's easy enough to do so, so we do. Signed-off-by: Peter Maydell --- docs/about/deprecated.rst | 9 + include/monitor/hmp.h | 2 +- softmmu/runstate-hmp-cmds.c | 2 +- tests/qtest/test-hmp.c | 1 + hmp-commands.hx | 25 + 5 files changed, 33 insertions(+), 6 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 06/10] Document that -singlestep command line option is deprecated
On 4/3/23 07:46, Peter Maydell wrote: Document that the -singlestep command line option is now deprecated, as it is replaced by either the TCG accelerator property 'one-insn-per-tb' for system emulation or the new '-one-insn-per-tb' option for usermode emulation, and remove the only use of the deprecated syntax from a README. Signed-off-by: Peter Maydell --- docs/about/deprecated.rst | 16 qemu-options.hx | 5 +++-- tcg/tci/README| 2 +- 3 files changed, 20 insertions(+), 3 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 05/10] bsd-user: Add '-one-insn-per-tb' option equivalent to '-singlestep'
On 4/3/23 07:46, Peter Maydell wrote: The '-singlestep' option is confusing, because it doesn't actually have anything to do with single-stepping the CPU. What it does do is force TCG emulation to put one guest instruction in each TB, which can be useful in some situations. Create a new command line argument -one-insn-per-tb, so we can document that -singlestep is just a deprecated synonym for it, and eventually perhaps drop it. Signed-off-by: Peter Maydell --- NB: not even compile tested! --- docs/user/main.rst | 7 ++- bsd-user/main.c| 5 +++-- 2 files changed, 9 insertions(+), 3 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 04/10] linux-user: Add '-one-insn-per-tb' option equivalent to '-singlestep'
On 4/3/23 07:46, Peter Maydell wrote: The '-singlestep' option is confusing, because it doesn't actually have anything to do with single-stepping the CPU. What it does do is force TCG emulation to put one guest instruction in each TB, which can be useful in some situations. Create a new command line argument -one-insn-per-tb, so we can document that -singlestep is just a deprecated synonym for it, and eventually perhaps drop it. Signed-off-by: Peter Maydell --- docs/user/main.rst | 7 ++- linux-user/main.c | 9 ++--- 2 files changed, 12 insertions(+), 4 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 03/10] tcg: Use one-insn-per-tb accelerator property in curr_cflags()
On 4/3/23 07:46, Peter Maydell wrote:
uint32_t curr_cflags(CPUState *cpu)
{
uint32_t cflags = cpu->tcg_cflags;
+TCGState *tcgstate = TCG_STATE(current_accel());
As mentioned against the cover, this is a very hot path.
We should try for something less expensive. Perhaps as simple as
return cpu->tcg_cflags | tcg_cflags_global;
where cpu->tcg_cflags is updated with cpu->singlestep_enabled.
r~
Re: [PATCH v2 02/10] softmmu: Don't use 'singlestep' global in QMP and HMP commands
On 4/3/23 07:46, Peter Maydell wrote: The HMP 'singlestep' command, the QMP 'query-status' command and the HMP 'info status' command (which is just wrapping the QMP command implementation) look at the 'singlestep' global variable. Make them access the new TCG accelerator 'one-insn-per-tb' property instead. This leaves the HMP and QMP command/field names and output strings unchanged; we will clean that up later. Signed-off-by: Peter Maydell --- softmmu/runstate-hmp-cmds.c | 18 -- softmmu/runstate.c | 10 +- 2 files changed, 25 insertions(+), 3 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 01/10] make one-insn-per-tb an accel option
On 4/3/23 07:46, Peter Maydell wrote: This commit adds 'one-insn-per-tb' as a property on the TCG accelerator object, so you can enable it with -accel tcg,one-insn-per-tb=on It has the same behaviour as the existing '-singlestep' command line option. We use a different name because 'singlestep' has always been a confusing choice, because it doesn't have anything to do with single-stepping the CPU. What it does do is force TCG emulation to put one guest instruction in each TB, which can be useful in some situations (such as analysing debug logs). The existing '-singlestep' commandline options are decoupled from the global 'singlestep' variable and instead now are syntactic sugar for setting the accel property. (These can then go away after a deprecation period.) The global variable remains for the moment as: * what the TCG code looks at to change its behaviour * what HMP and QMP use to query and set the behaviour In the following commits we'll clean those up to not directly look at the global variable. Signed-off-by: Peter Maydell --- accel/tcg/tcg-all.c | 21 + bsd-user/main.c | 8 ++-- linux-user/main.c | 8 ++-- softmmu/vl.c| 17 +++-- qemu-options.hx | 7 +++ 5 files changed, 55 insertions(+), 6 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 00/10] Deprecate/rename singlestep command line option, monitor interfaces
On 4/3/23 07:46, Peter Maydell wrote: * I have written patch 3 on the assumption that curr_cflags() is not such a hot codepath that we can't afford to have a QOM cast macro in it; the alternative would be to keep it using a global variable but make the global be restricted to accel/tcg/internals.h. RTH: opinions welcome... curr_cflags() is quite hot, called from lookup_tb_ptr every time we time we end a chain of directly linked TBs. You'll see lookup_tb_ptr near the top of any tcg profile. With a global variable, it might be worth combining with CPU_LOG_TB_NOCHAIN, recomputing the global if either option changes. r~
Re: [PATCH v4 4/5] docs/about/deprecated: Deprecate 32-bit arm hosts for system emulation
On 3/6/23 00:46, Thomas Huth wrote: +continuous to be supported on 32-bit arm hosts, too) "continues" Acked-by: Richard Henderson r~
Re: [PATCH 1/2] docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386
On 2/27/23 23:00, Michael S. Tsirkin wrote: On Mon, Feb 27, 2023 at 10:21:14AM -1000, Richard Henderson wrote: Removing support for building on 32 bit systems seems like a pity - it's one of a small number of ways to run 64 bit binaries on 32 bit systems, and the maintainance overhead is quite small. It's not that small. Meaning there are lots of ways to run 64 bit binaries on 32 bit systems? No, meaning the maint overhead is large. r~
Re: [PATCH 1/2] docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386
On 2/27/23 01:50, Daniel P. Berrangé wrote: On Mon, Feb 27, 2023 at 12:10:49PM +0100, Thomas Huth wrote: Hardly anybody still uses 32-bit x86 hosts today, so we should start deprecating them to finally have less test efforts. With regards to 32-bit KVM support in the x86 Linux kernel, the developers confirmed that they do not need a recent qemu-system-i386 binary here: https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/ Signed-off-by: Thomas Huth --- docs/about/deprecated.rst | 13 + 1 file changed, 13 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 15084f7bea..98517f5187 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -196,6 +196,19 @@ CI coverage support may bitrot away before the deprecation process completes. The little endian variants of MIPS (both 32 and 64 bit) are still a supported host architecture. +32-bit x86 hosts and ``qemu-system-i386`` (since 8.0) +' + +Testing 32-bit x86 host OS support takes a lot of precious time during the +QEMU contiguous integration tests, and considering that most OS vendors +stopped shipping 32-bit variants of their x86 OS distributions and most +x86 hardware from the past >10 years is capable of 64-bit, keeping the +32-bit support alive is an inadequate burden for the QEMU project. Thus +QEMU will soon drop the support for 32-bit x86 host systems and the +``qemu-system-i386`` binary. Use ``qemu-system-x86_64`` (which is a proper +superset of ``qemu-system-i386``) on a 64-bit host machine instead. I feel like we should have separate deprecation entries for the i686 host support, and for qemu-system-i386 emulator binary, as although they're related they are independant features with differing impact. Agreed. 32-bit x86 hosts Support for 32-bit x86 host deployments is increasingly uncommon in mainstream Linux distributions given the widespread availability of 64-bit x86 hardware. The QEMU project no longer considers 32-bit x86 support to be an effective use of its limited resources, and thus intends to discontinue it. Current users of QEMU on 32-bit x86 hosts should either continue using existing releases of QEMU, with the caveat that they will no longer get security fixes, or migrate to a 64-bit platform which remains capable of running 32-bit guests if needed. Ack. ``qemu-system-i386`` binary removal ''' The ``qemu-system-x86_64`` binary can be used to run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Once support for the 32-bit x86 host platform is discontinued, the ``qemu-system-i386`` binary will be redundant. Missing "kvm" in this last sentence? It is otherwise untrue for tcg. Current users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary. Ack. Same point for the next patch about 32-bit arm vs qemu-system-arm binary. Ack. r~
Re: [PATCH 1/2] docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386
On 2/27/23 10:12, Michael S. Tsirkin wrote: On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote: I feel like we should have separate deprecation entries for the i686 host support, and for qemu-system-i386 emulator binary, as although they're related they are independant features with differing impact. eg removing qemu-system-i386 affects all host architectures, not merely 32-bit x86 host, so I think we can explain the impact more clearly if we separate them. Removing qemu-system-i386 seems ok to me - I think qemu-system-x86_64 is a superset. Removing support for building on 32 bit systems seems like a pity - it's one of a small number of ways to run 64 bit binaries on 32 bit systems, and the maintainance overhead is quite small. It's not that small. It only works for single-threaded system mode. It silently does not honor atomicity for user-only mode, which is perhaps worse not working at all. r~
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
On 2/17/23 06:06, Reinoud Zandijk wrote: On Fri, Feb 17, 2023 at 11:36:41AM +0100, Markus Armbruster wrote: I feel the discussion petered out without a conclusion. I don't think letting the status quo win by inertia is a good outcome here. Which 32-bit hosts are still useful, and why? NetBSD runs on a bunch of 32 bit-only hosts (sparc32, ppc32, armv7, vax, mips32 etc.) that all run Qemu fine. They are all actively maintained and released as part of the main releases. Are you sure about that? TCG doesn't support sparc32 or vax. I suppose you could be using TCI, but I can't even imagine how slow that would be on vax. r~
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
On 1/30/23 13:14, Philippe Mathieu-Daudé wrote: On 30/1/23 20:19, Richard Henderson wrote: But I do question whether we need to support 64-bit guests on 32-bit hosts at all. Retaining 32-bit on 32-bit allows arm32 to emulate i686, which I suspect, but have no proof, is the limit of what users actually want. I presume you implicitly restrict that to user emulation, right? No, there's no specific reason to eliminate e.g. qemu-system-i386. or any other 32-bit guest. Though quite often such hardware doesn't really have enough ram to do a good job, that's not a technical argument against. WRT i686, if your example is "i686 useremu on non-x86 embedde router" then any 32-bit host is potentially interested, not only arm32. arm32 was merely an example -- the other 32-bit hosts are i686, mips, ppc. But we don't have many of them. I remember being able to run armhf binaries on armel hosts (and vice versa) was useful 7 years ago. Fair enough. Today I have no clue, we could poll the community and some distributions. Sure. r~
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
On 1/30/23 02:01, Daniel P. Berrangé wrote: I vaguely recall someone mentioned problems with atomic ops in the past, or was it 128-bit ints, caused implications for the codebase ? TCG_OVERSIZED_GUEST, where 32-bit host running 64-bit guest cannot run the guest except in round-robin mode. It's not *that* much of a support burden, since we're not going to eliminate round-robin mode. But I do question whether we need to support 64-bit guests on 32-bit hosts at all. Retaining 32-bit on 32-bit allows arm32 to emulate i686, which I suspect, but have no proof, is the limit of what users actually want. r~
Re: [PATCH v2] MIPS: remove support for trap and emulate KVM
On 12/21/22 01:17, Philippe Mathieu-Daudé wrote:
From: Paolo Bonzini
This support was limited to the Malta board, drop it.
I do not have a machine that can run VZ KVM, so I am assuming
that it works for -M malta as well.
Signed-off-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
---
Since Paolo's v1:
- Remove cpu_mips_kvm_um_phys_to_kseg0() declaration in "cpu.h"
- Remove unused KVM_KSEG0_BASE/KVM_KSEG2_BASE definitions
- Use USEG_LIMIT/KSEG0_BASE instead of magic values
/* Check where the kernel has been linked */
-if (!(kernel_entry & 0x8000ll)) {
-error_report("CONFIG_KVM_GUEST kernels are not supported");
+if (kernel_entry <= USEG_LIMIT) {
+error_report("Trap-and-Emul kernels (Linux CONFIG_KVM_GUEST)"
+ " are not supported");
-env->CP0_EBase = (cs->cpu_index & 0x3FF) | (int32_t)0x8000;
+env->CP0_EBase = KSEG0_BASE | (cs->cpu_index & 0x3FF);
---
docs/about/deprecated.rst | 9 ---
docs/about/removed-features.rst | 9 +++
hw/mips/malta.c | 46 +
target/mips/cpu.c | 7 +
target/mips/cpu.h | 3 ---
target/mips/internal.h | 3 ---
target/mips/kvm.c | 11 +---
target/mips/sysemu/addr.c | 17
target/mips/sysemu/physaddr.c | 13 --
9 files changed, 18 insertions(+), 100 deletions(-)
Reviewed-by: Richard Henderson
r~
Re: [PULL 0/3] Misc next patches
On 4/26/22 08:13, Daniel P. Berrangé wrote: The following changes since commit a1755db71e34df016ffc10aa0727360aae2c6036: Merge tag 'pull-block-2022-04-25' of https://gitlab.com/hreitz/qemu into staging (2022-04-25 13:35:41 -0700) are available in the Git repository at: https://gitlab.com/berrange/qemu tags/misc-next-pull-request for you to fetch changes up to 5cf434b5af386fadc3418df71d3738676cbb0549: github: fix config mistake preventing repo lockdown commenting (2022-04-26 16:12:26 +0100) Misc patch queue * Removes depecated --enable-fips QEMU system emulator option * Fixes array bounds check in keycode conversion for ESCC device Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/7.1 as appropriate. r~ Daniel P. Berrangé (3): softmmu: remove deprecated --enable-fips option hw/char: fix qcode array bounds check in ESCC impl github: fix config mistake preventing repo lockdown commenting .github/workflows/lockdown.yml | 6 +++--- docs/about/deprecated.rst | 12 docs/about/removed-features.rst | 11 +++ hw/char/escc.c | 2 +- include/qemu/osdep.h| 3 --- os-posix.c | 8 qemu-options.hx | 10 -- ui/vnc.c| 7 --- util/osdep.c| 28 9 files changed, 15 insertions(+), 72 deletions(-)
Re: [PATCH v2 12/12] target/riscv: Support virtual time context synchronization
On 12/10/21 2:07 AM, Yifei Jiang via wrote:
+static bool kvmtimer_needed(void *opaque)
+{
+return kvm_enabled();
+}
+
+
+static const VMStateDescription vmstate_kvmtimer = {
+.name = "cpu/kvmtimer",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = kvmtimer_needed,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(env.kvm_timer_time, RISCVCPU),
+VMSTATE_UINT64(env.kvm_timer_compare, RISCVCPU),
+VMSTATE_UINT64(env.kvm_timer_state, RISCVCPU),
+
+VMSTATE_END_OF_LIST()
+}
+};
+
+static int cpu_post_load(void *opaque, int version_id)
+{
+RISCVCPU *cpu = opaque;
+CPURISCVState *env = >env;
+
+if (kvm_enabled()) {
+env->kvm_timer_dirty = true;
+}
+return 0;
+}
This post-load belongs on the vmstate_kvmtimer struct, so that you need not re-check
kvm_enabled().
const VMStateDescription vmstate_riscv_cpu = {
.name = "cpu",
-.version_id = 3,
-.minimum_version_id = 3,
+.version_id = 4,
+.minimum_version_id = 4,
+.post_load = cpu_post_load,
No need for version change.
r~
Re: [PATCH v2 10/12] target/riscv: Add kvm_riscv_get/put_regs_timer
On 12/12/21 9:05 PM, Anup Patel wrote:
+ret = kvm_get_one_reg(cs, RISCV_TIMER_REG(env, state), );
+if (ret) {
+abort();
+}
+env->kvm_timer_state = reg;
Please read the timer frequency here.
Yep.
+
+env->kvm_timer_dirty = true;
+}
+
+static void kvm_riscv_put_regs_timer(CPUState *cs)
+{
+int ret;
+uint64_t reg;
+CPURISCVState *env = _CPU(cs)->env;
+
+if (!env->kvm_timer_dirty) {
+return;
+}
Over here, we should get the timer frequency and abort() with an
error message if it does not match env->kvm_timer_frequency
For now, migration will not work between Hosts with different
timer frequency.
You shouldn't have to do this every "put", only on migration, at which point you can
actually signal a migration error rather than aborting directly.
r~
Re: [PATCH v1 12/12] target/riscv: Support virtual time context synchronization
On 11/20/21 8:46 AM, Yifei Jiang wrote:
const VMStateDescription vmstate_riscv_cpu = {
.name = "cpu",
.version_id = 3,
.minimum_version_id = 3,
+.post_load = cpu_post_load,
.fields = (VMStateField[]) {
VMSTATE_UINTTL_ARRAY(env.gpr, RISCVCPU, 32),
VMSTATE_UINT64_ARRAY(env.fpr, RISCVCPU, 32),
@@ -211,6 +221,10 @@ const VMStateDescription vmstate_riscv_cpu = {
VMSTATE_UINT64(env.mtohost, RISCVCPU),
VMSTATE_UINT64(env.timecmp, RISCVCPU),
+VMSTATE_UINT64(env.kvm_timer_time, RISCVCPU),
+VMSTATE_UINT64(env.kvm_timer_compare, RISCVCPU),
+VMSTATE_UINT64(env.kvm_timer_state, RISCVCPU),
+
VMSTATE_END_OF_LIST()
},
Can't alter VMStateDescription.fields without bumping version.
If this is really kvm-only state, consider placing it into a subsection. But I worry
about kvm-only state because ideally we'd be able to migrate between tcg and kvm (if only
for debugging).
r~
Re: [PATCH v1 03/12] target/riscv: Implement function kvm_arch_init_vcpu
On 11/20/21 8:46 AM, Yifei Jiang wrote:
+id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
KVM_REG_RISCV_CONFIG_REG(isa));
+ret = kvm_get_one_reg(cs, id, );
+if (ret) {
+return ret;
+}
+env->misa_mxl |= isa;
This doesn't look right.
I'm sure you meant
env->misa_ext = isa;
r~
Re: [PULL 00/10] Misc 20211102 patches
On 11/2/21 12:26 PM, Gerd Hoffmann wrote: The following changes since commit 8cb41fda78c7ebde0dd248c6afe1d336efb0de50: Merge remote-tracking branch 'remotes/philmd/tags/machine-20211101' into staging (2021-11-02 05:53:45 -0400) are available in the Git repository at: git://git.kraxel.org/qemu tags/misc-20211102-pull-request for you to fetch changes up to 58d7d4c7869cb3addb0714aa7b6bd88f2b6b7edf: usb-storage: tag usb_msd_csw as packed struct (2021-11-02 17:24:18 +0100) MAINTAINERS: audio updates microvm: device tree support console: chardev fixes misc: deprecate sga usb: fix struct usb_msd_csw Christian Schoenebeck (1): MAINTAINERS: add myself as partial audio reviewer Daniel P. Berrangé (1): hw/misc: deprecate the 'sga' device Dongwon Kim (1): ui/gtk: skip any extra draw of same guest scanout blob res Gerd Hoffmann (2): microvm: add device tree support. usb-storage: tag usb_msd_csw as packed struct Nikola Pavlica (1): ui/gtk: Update the refresh rate for gl-area too Thomas Huth (1): MAINTAINERS: Add myself as a reviewer for SDL audio Volker Rümelin (3): ui/console: replace QEMUFIFO with Fifo8 ui/console: replace kbd_timer with chr_accept_input callback ui/console: remove chardev frontend connected test hw/i386/microvm-dt.h | 8 + include/hw/i386/microvm.h | 4 + include/hw/usb/msd.h | 2 +- include/ui/console.h | 1 + hw/display/virtio-gpu-udmabuf.c| 2 +- hw/i386/microvm-dt.c | 341 + hw/i386/microvm.c | 2 + hw/misc/sga.c | 2 + ui/console.c | 109 +++-- ui/gtk-egl.c | 40 ++-- ui/gtk-gl-area.c | 52 +++-- .gitlab-ci.d/buildtest.yml | 1 - MAINTAINERS| 4 + configs/targets/i386-softmmu.mak | 1 + configs/targets/x86_64-softmmu.mak | 1 + docs/about/deprecated.rst | 10 + hw/i386/meson.build| 2 +- 17 files changed, 466 insertions(+), 116 deletions(-) create mode 100644 hw/i386/microvm-dt.h create mode 100644 hw/i386/microvm-dt.c Applied, thanks. r~
Re: [PATCH v2 4/4] MAINTAINERS: Agree to maintain nanoMIPS TCG frontend
On 10/26/21 9:14 PM, Philippe Mathieu-Daudé wrote:
As of this commit, the nanoMIPS toolchains haven't been merged
in mainstream projects. However MediaTek provides a toolchain:
https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases/tag/nanoMIPS-2021.02-01
QEMU deprecation policy schedules code for removal. If we don't
need / want to remove, we should un-deprecated [*].
Since I now have spent more time with the ISA, I agree to maintain
it along with the other MIPS ISA. Therefore remove its deprecation
notice.
For historical notes, see commit a60442eb8 ("Deprecate nanoMIPS ISA").
[*] https://lore.kernel.org/qemu-devel/yvx7ygquenp83...@redhat.com/
Cc: Vince Del Vecchio
Cc: Petar Jovanovic
Reviewed-by: Jiaxun Yang
Signed-off-by: Philippe Mathieu-Daudé
---
Reviewed-by: Richard Henderson
r~
Re: [PATCH v2 3/4] MAINTAINERS: Split MIPS TCG frontend vs MIPS machines/hardware
On 10/26/21 9:14 PM, Philippe Mathieu-Daudé wrote: Hardware emulated models don't belong to the TCG MAINTAINERS section. Move them to a new 'Overall MIPS Machines' section in the 'MIPS Machines' group. Reviewed-by: Jiaxun Yang Signed-off-by: Philippe Mathieu-Daudé Message-Id:<20211004092515.3819836-4-f4...@amsat.org> --- MAINTAINERS | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 2/4] MAINTAINERS: Add entries to cover MIPS CPS / GIC hardware
On 10/26/21 9:14 PM, Philippe Mathieu-Daudé wrote: MIPS CPS and GIC models are unrelated to the TCG frontend. Move them as new sections under the 'Devices' group. Cc: Paul Burton Reviewed-by: Jiaxun Yang Signed-off-by: Philippe Mathieu-Daudé --- MAINTAINERS | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 1/4] MAINTAINERS: Add MIPS general architecture support entry
On 10/26/21 9:14 PM, Philippe Mathieu-Daudé wrote: The architecture is covered in TCG (frontend and backend) and hardware models. Add a generic section matching the 'mips' word in patch subjects. Reviewed-by: Jiaxun Yang Signed-off-by: Philippe Mathieu-Daudé Message-Id:<20211004092515.3819836-2-f4...@amsat.org> --- MAINTAINERS | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v3 3/4] fdc: Inline fdctrl_connect_drives() into fdctrl_realize_common()
On 3/9/21 8:12 AM, Markus Armbruster wrote:
@@ -2565,6 +2551,7 @@ static void fdctrl_realize_common(DeviceState *dev,
FDCtrl *fdctrl,
Error **errp)
{
int i, j;
+FDrive *drive;
static int command_tables_inited = 0;
if (fdctrl->fallback == FLOPPY_DRIVE_TYPE_AUTO) {
@@ -2604,7 +2591,13 @@ static void fdctrl_realize_common(DeviceState *dev,
FDCtrl *fdctrl,
}
floppy_bus_create(fdctrl, >bus, dev);
-fdctrl_connect_drives(fdctrl, dev, errp);
+
+for (i = 0; i < MAX_FD; i++) {
+drive = >drives[i];
FWIW, the declaration could be local to this loop.
r~
Re: [PULL 00/66] MIPS patches for 2021-01-07
On 1/8/21 5:22 AM, 罗勇刚(Yonggang Luo) wrote: >>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position >>> 80: ordinal not in range(128) > Can we always reading file in decodetree with utf8 encoding > And convert all decodetree to utf8 encoding, and the problem should resolved. > ``` > scripts/decodetree.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/decodetree.py b/scripts/decodetree.py > index 47aa9caf6d..8c9eb365ac 100644 > --- a/scripts/decodetree.py > +++ b/scripts/decodetree.py > @@ -1304,7 +1304,7 @@ def main(): > > for filename in args: > input_file = filename > - f = open(filename, 'r') > + f = open(filename, 'r', encoding="utf8") > parse_file(f, toppat) > f.close() > > ``` Thanks. Would you like to send a formal patch? r~
Re: [PATCH-for-5.2] target/mips: Deprecate nanoMIPS ISA
On 11/2/20 12:27 PM, Philippe Mathieu-Daudé wrote: > The nanoMIPS ISA has been announced in 2018 for various projects: > > GCC: https://gcc.gnu.org/legacy-ml/gcc/2018-05/msg00012.html > Linux: https://lwn.net/Articles/753605/ > QEMU: https://www.mail-archive.com/qemu-devel@nongnu.org/msg530721.html > > Unfortunately the links referenced doesn't work anymore (www.mips.com). > > From this Wayback machine link [1] we can get to a working place to > download a toolchain (a more recent release than the one referenced > in the announcement mails): > http://codescape.mips.com/components/toolchain/nanomips/2018.04-02/downloads.html > > The toolchain page mention LLVM but simply links http://llvm.org/ > where there is no reference on nanoMIPS. > > The only reference in the GCC mailing list, is the nanoMIPS > announcement: https://gcc.gnu.org/pipermail/gcc/2018-May.txt > > The developer who authored the announcements have been emailed [2] > to ask for more information but all their emails are now bouncing: > > - Your message to stefan.marko...@mips.com couldn't be delivered. > > - Your message to smarko...@wavecomp.com couldn't be delivered. > > - Couldn't deliver the message to the following recipients: > robert.sucha...@mips.com, matthew.fort...@mips.com, > marcin.nowakow...@mips.com > > Our deprecation policy do not allow feature removal before 2 release, > therefore declare the nanoMIPS ISA code deprecated as of QEMU 5.2. > This gives time to developers to update the QEMU community, or > interested parties to step in to maintain this code. > > [1] > https://web.archive.org/web/20180904044530/https://www.mips.com/develop/tools/compilers/ > [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg756392.html > > Signed-off-by: Philippe Mathieu-Daudé > --- Acked-by: Richard Henderson r~
Re: [PATCH-for-5.2] hw/mips: Remove the 'r4k' machine
On 11/2/20 2:26 AM, Philippe Mathieu-Daudé wrote: > -mips ``r4k`` platform (since 5.0) > +mips ``r4k`` platform (removed in 5.2) > ' Header underline needs adjustment. Otherwise, Acked-by: Richard Henderson r~
Re: [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation
On 9/7/20 2:05 AM, Alex Bennée wrote: > What about tweaking configure? Or should I just manually squash it in > all our CI configs? Squash in to CI, I would think. r~
Re: [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation
On 9/4/20 10:21 AM, Peter Maydell wrote: > On Fri, 4 Sep 2020 at 17:52, Alex Bennée wrote: >> >> It's buggy and we are not sure anyone uses it. > >> +``ppc64abi32`` CPUs (since 5.2.0) >> +' >> + >> +The ``ppc64abi32`` architecture has a number of issues which regularly >> +trip up our CI testing and is suspected to be quite broken. >> +Furthermore the maintainers are unsure what the correct behaviour >> +should be and strongly suspect no one actually uses it. > > IRC discussion suggests we do know what the correct behaviour > is -- it should be "what the compat32 interface of a 64-bit > PPC kernel gives you", it's just that the code doesn't do that > (and never has?). It's like the mipsn32, mipsn32el, sparc32plus > ABIs which we also implement (hopefully correctly...) > > But "this has always been broken and nobody complained" is > a good reason to deprecate anyway. Indeed. With the last sentence changed to "For that reason the maintainers strongly suspect no one actually uses it." Reviewed-by: Richard Henderson r~
