Re: [PATCH] hw/rdma: Deprecate the pvrdma device and the rdma subsystem
On 27/9/23 15:30, Thomas Huth wrote: This subsystem is said to be in a bad shape (see e.g. [1], [2] and [3]), and nobody seems to feel responsible to pick up patches for this and send them via a pull request. For example there is a patch for a CVE-worthy bug posted more than half a year ago [4] which has never been merged. Quoting Markus: "Given the shape it is in, I wouldn't let friends use it in production" - we shouldn't expose this to our users in the current state. Thus let's mark it as deprecated and finally remove it unless somebody steps up and improves the code quality and adds proper regression tests. [1] https://lore.kernel.org/qemu-devel/20230918144206.560120-1-arm...@redhat.com/ [2] https://lore.kernel.org/qemu-devel/zqnojjoqofu73...@redhat.com/ [3] https://lore.kernel.org/qemu-devel/1054981c-e8ae-c676-3b04-eeb030e11...@tls.msk.ru/ [4] https://lore.kernel.org/qemu-devel/20230301142926.18686-1-yuval.shaia...@gmail.com/ [5] https://lore.kernel.org/qemu-devel/8734z9f086@pond.sub.org/ Signed-off-by: Thomas Huth --- MAINTAINERS | 2 +- docs/about/deprecated.rst | 8 hw/rdma/vmw/pvrdma_main.c | 2 ++ 3 files changed, 11 insertions(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé
[PULL 01/41] accel: Remove HAX accelerator
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 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.
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.
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.
[*] https://github.com/intel/haxm/releases/tag/v7.8.0
Reviewed-by: Richard Henderson
Acked-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Message-Id: <20230831082016.60885-1-phi...@linaro.org>
---
MAINTAINERS |8 -
docs/about/build-platforms.rst|2 +-
docs/about/deprecated.rst |6 -
docs/about/index.rst |2 +-
docs/about/removed-features.rst | 11 +-
docs/system/index.rst |2 +-
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/Kconfig |3 -
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 -
34 files changed, 16 insertions(+), 3149 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
diff --git a/MAINTAINERS b/MAINTAINERS
index 6111b6b4d9..3b29568ed4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -543,14 +543,6 @@ F: include/sysemu/xen.h
F: include/sysemu/xen-mapcache.h
F: stubs/xen-hw-stub.c
-Guest CPU Cores (HAXM)
--
-X86 HAXM CPUs
-S: Orphan
-F: accel/stubs/hax-stub.c
-F: include/sysemu/hax.h
-F: target/i386/hax/
-
Guest CPU Cores (NVMM)
--
NetBSD Virtual Machine Monitor (NVMM) CPU support
diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
index 0e2cb9e770..f2a7aec56f 100644
--- a/docs/about/build-platforms.rst
+++ b/docs/about/build-platforms.rst
@@ -52,7 +52,7 @@ Those hosts are officially supported, with various
accelerators:
* - SPARC
- tcg
* - x86
- - hax, hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
+ - hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
Other host architectures are not supported. It is possible to build QEMU system
emulation on an unsupported host architecture using the configure
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 92a2bafd2b..dc4da95329 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -105,12 +105,6 @@ Use ``-machine hpet=off`` instead.
The ``-no-acpi`` setting has been turned into a machine property
[PATCH v2] accel: Remove HAX accelerator
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 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.
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.
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.
[*] https://github.com/intel/haxm/releases/tag/v7.8.0
Reviewed-by: Richard Henderson
Acked-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
---
I plan to commit this in my next PR.
---
MAINTAINERS |8 -
docs/about/build-platforms.rst|2 +-
docs/about/deprecated.rst |6 -
docs/about/index.rst |2 +-
docs/about/removed-features.rst | 11 +-
docs/system/index.rst |2 +-
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/Kconfig |3 -
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 -
34 files changed, 16 insertions(+), 3149 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
diff --git a/MAINTAINERS b/MAINTAINERS
index 6111b6b4d9..3b29568ed4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -543,14 +543,6 @@ F: include/sysemu/xen.h
F: include/sysemu/xen-mapcache.h
F: stubs/xen-hw-stub.c
-Guest CPU Cores (HAXM)
--
-X86 HAXM CPUs
-S: Orphan
-F: accel/stubs/hax-stub.c
-F: include/sysemu/hax.h
-F: target/i386/hax/
-
Guest CPU Cores (NVMM)
--
NetBSD Virtual Machine Monitor (NVMM) CPU support
diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
index 0e2cb9e770..f2a7aec56f 100644
--- a/docs/about/build-platforms.rst
+++ b/docs/about/build-platforms.rst
@@ -52,7 +52,7 @@ Those hosts are officially supported, with various
accelerators:
* - SPARC
- tcg
* - x86
- - hax, hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
+ - hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
Other host architectures are not supported. It is possible to build QEMU system
emulation on an unsupported host architecture using the configure
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 92a2bafd2b..dc4da95329 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -105,12 +105,6 @@ Use ``-machine hpet=off`` instead.
The ``-no-acpi`` setting has been turned into a machine property.
Use ``-machine acpi=off`` instead.
-``-ac
Re: [PATCH] Fix some typos in documentation and comments
On 30/7/23 20:03, Stefan Weil wrote: Signed-off-by: Stefan Weil --- This patch was triggered by a spelling check for the generated QEMU documentation using codespell. It does not try to fix all typos which still exist in the QEMU code, but has a focus on those required to fix the documentation. Nevertheless some code comments with the same typos were fixed, too. I think the patch is trivial, so maybe it can still be included in the upcoming release, but that's not strictly necessary. Stefan docs/about/deprecated.rst| 2 +- docs/devel/qom.rst | 2 +- docs/system/devices/nvme.rst | 2 +- hw/core/loader.c | 4 ++-- include/exec/memory.h| 2 +- ui/vnc-enc-tight.c | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) Thanks, queued via misc-fixes.
Re: [PATCH] Fix some typos in documentation and comments
On 30/7/23 20:03, Stefan Weil wrote: Signed-off-by: Stefan Weil --- This patch was triggered by a spelling check for the generated QEMU documentation using codespell. It does not try to fix all typos which still exist in the QEMU code, but has a focus on those required to fix the documentation. Nevertheless some code comments with the same typos were fixed, too. I think the patch is trivial, so maybe it can still be included in the upcoming release, but that's not strictly necessary. Stefan docs/about/deprecated.rst| 2 +- docs/devel/qom.rst | 2 +- docs/system/devices/nvme.rst | 2 +- hw/core/loader.c | 4 ++-- include/exec/memory.h| 2 +- ui/vnc-enc-tight.c | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [RFC PATCH-for-8.1] accel: Remove HAX accelerator
On 24/6/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é
---
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 5b258b446b..cc8a1e38a9 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -659,15 +659,18 @@ Use ``Icelake-Server`` instead.
System accelerators
---
-Userspace local APIC with KVM (x86, removed 8.0)
+Userspace local APIC with KVM (x86, removed in 8.0)
Oops I didn't mean to commit this line. The doc won't build with padding.
``-M kernel-irqchip=off`` cannot be used on KVM if the CPU model includes
a local APIC. The ``split`` setting is supported, as is using ``-M
kernel-irqchip=off`` when the CPU does not have a local APIC.
[RFC PATCH-for-8.1] accel: Remove HAX accelerator
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
diff --git a/MAINTAINERS b/MAINTAINERS
index 1da135b0c8..aa30640670 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -544,14 +544,6 @@ F: include/sysemu/xen.h
F: include/sysemu/xen-mapcache.h
F: stubs/xen-hw-stub.c
-Guest CPU Cores (HAXM)
--
-X86 HAXM CPUs
-S: Orphan
-F: accel/stubs/hax-stub.c
-F: include/sysemu/hax.h
-F: target/i386/hax/
-
Guest CPU Cores (NVMM)
--
NetBSD Virtual Machine Monitor (NVMM) CPU support
diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
index 0e2cb9e770..f2a7aec56f 100644
--- a/docs/about/build-platforms.rst
+++ b/docs/about/build-platforms.rst
@@ -52,7 +52,7 @@ Those hosts are officially supported, with various
accelerators:
* - SPARC
- tcg
* - x86
- - hax, hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
+ - hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
Other host architectures are not supported. It is possible to build QEMU system
emulation on an unsupported host architecture using the configure
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0743459862..c1d6dde8f7 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -105,12 +105,6 @@ Use ``-machine hpet=off`` instead.
The ``-no-acpi`` setting has been turned into a machine property.
Use ``-machine acpi=off`` instead.
-``-accel hax`` (since 8.0)
-''
-
-The HAXM project has been retired (see https://github.com/intel/haxm
Re: [PATCH v5 04/10] scripts/qapi: document the tool that generated the file
On 24/5/23 15:39, Alex Bennée wrote: This makes it a little easier for developers to find where things where being generated. Reviewed-by: Richard Henderson Signed-off-by: Alex Bennée Message-Id: <20230523125000.3674739-5-alex.ben...@linaro.org> --- scripts/qapi/gen.py | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v4 02/10] trace-events: remove the remaining vcpu trace events
On 23/5/23 14:49, Alex Bennée wrote: While these are all in helper functions being designated vcpu events complicates the removal of the dynamic vcpu state code. TCG plugins allow you to instrument vcpu_[init|exit|idle]. We rename cpu_reset and make it a normal trace point. Reviewed-by: Stefan Hajnoczi Reviewed-by: Richard Henderson Message-Id: <20230503091756.1453057-3-alex.ben...@linaro.org> Signed-off-by: Alex Bennée Message-Id: <20230505155336.137393-3-alex.ben...@linaro.org> --- hw/core/cpu-common.c | 4 ++-- trace/control-target.c | 1 - trace/control.c| 2 -- hw/core/trace-events | 3 +++ trace-events | 31 --- 5 files changed, 5 insertions(+), 36 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v4 01/10] *-user: remove the guest_user_syscall tracepoints
On 23/5/23 14:49, Alex Bennée wrote: This is pure duplication now. Both bsd-user and linux-user have builtin strace support and we can also track syscalls via the plugins system. Message-Id: <20230420150009.1675181-2-alex.ben...@linaro.org> Reviewed-by: Warner Losh Reviewed-by: Stefan Hajnoczi Reviewed-by: Richard Henderson Message-Id: <20230503091756.1453057-2-alex.ben...@linaro.org> Signed-off-by: Alex Bennée Message-Id: <20230505155336.137393-2-alex.ben...@linaro.org> --- include/user/syscall-trace.h | 4 bsd-user/freebsd/os-syscall.c | 2 -- trace-events | 19 --- 3 files changed, 25 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v4 05/10] qapi: make the vcpu parameters deprecated for 8.1
On 23/5/23 14:49, Alex Bennée wrote:
I don't think I can remove the parameters directly but certainly mark
them as deprecated.
Message-Id: <20230420150009.1675181-6-alex.ben...@linaro.org>
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Richard Henderson
Message-Id: <20230503091756.1453057-6-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée
Message-Id: <20230505155336.137393-6-alex.ben...@linaro.org>
---
v4
- used @deprecated in json
- added note to deprecated.rst
---
docs/about/deprecated.rst | 9 +
qapi/trace.json | 38 ++
2 files changed, 27 insertions(+), 20 deletions(-)
@@ -52,19 +53,17 @@
#
# @name: Event name pattern (case-sensitive glob).
#
-# @vcpu: The vCPU to query (any by default; since 2.7).
+# @vcpu: The vCPU to query (since 2.7).
+#
+# Features:
+# @deprecated: Member @vcpu is deprecated, and always false.
#
# Returns: a list of @TraceEventInfo for the matching events
#
# An event is returned if:
#
-# - its name matches the @name pattern, and
-# - if @vcpu is given, the event has the "vcpu" property.
-#
-# Therefore, if @vcpu is given, the operation will only match per-vCPU
-# events, returning their state on the specified vCPU. Special case:
-# if @name is an exact match, @vcpu is given and the event does not
-# have the "vcpu" property, an error is returned.
+# - its name matches the @name pattern
+# There are no longer any per-vCPU events
Maybe convert the 2 spaces by a newline, or even better simply:
# An event is returned if its name matches the @name pattern
# (There are no longer any per-vCPU events).
#
# Since: 2.2
#
@@ -75,7 +74,8 @@
# <- { "return": [ { "name": "qemu_memalign", "state": "disabled", "vcpu":
false } ] }
##
{ 'command': 'trace-event-get-state',
- 'data': {'name': 'str', '*vcpu': 'int'},
+ 'data': {'name': 'str',
+ '*vcpu': {'type': 'int', 'features': ['deprecated'] } },
'returns': ['TraceEventInfo'] }
##
@@ -91,15 +91,13 @@
#
# @vcpu: The vCPU to act upon (all by default; since 2.7).
#
-# An event's state is modified if:
+# Features:
+# @deprecated: Member @vcpu is deprecated, and always false.
#
-# - its name matches the @name pattern, and
-# - if @vcpu is given, the event has the "vcpu" property.
+# An event's state is modified if:
#
-# Therefore, if @vcpu is given, the operation will only match per-vCPU
-# events, setting their state on the specified vCPU. Special case: if
-# @name is an exact match, @vcpu is given and the event does not have
-# the "vcpu" property, an error is returned.
+# - its name matches the @name pattern
+# There are no longer any per-vCPU events
Ditto.
Otherwise:
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v3 04/10] linux-user: Add '-one-insn-per-tb' option equivalent to '-singlestep'
On 20/4/23 11:19, Peter Maydell wrote:
On Thu, 20 Apr 2023 at 10:13, Philippe Mathieu-Daudé wrote:
On 17/4/23 18:40, 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
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
---
docs/user/main.rst | 7 ++-
linux-user/main.c | 9 ++---
2 files changed, 12 insertions(+), 4 deletions(-)
@@ -500,8 +500,11 @@ static const struct qemu_argument arg_table[] = {
"logfile", "write logs to 'logfile' (default stderr)"},
{"p", "QEMU_PAGESIZE",true, handle_arg_pagesize,
"pagesize", "set the host page size to 'pagesize'"},
-{"singlestep", "QEMU_SINGLESTEP", false, handle_arg_singlestep,
- "", "run in singlestep mode"},
+{"one-insn-per-tb",
+ "QEMU_ONE_INSN_PER_TB", false, handle_arg_one_insn_per_tb,
+ "", "run with one guest instruction per emulated TB"},
+{"singlestep", "QEMU_SINGLESTEP", false, handle_arg_one_insn_per_tb,
+ "", "deprecated synonym for -one-insn-per-tb"},
Maybe worth mentioning QEMU_ONE_INSN_PER_TB too here:
"deprecated synonyms for -one-insn-per-tb and QEMU_ONE_INSN_PER_TB"
There's not a lot of space in the -help output, and I think in
context it's clear enough without.
Fine.
Re: [PATCH v3 05/10] bsd-user: Add '-one-insn-per-tb' option equivalent to '-singlestep'
On 17/4/23 18:40, 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 Reviewed-by: Warner Losh Reviewed-by: Richard Henderson --- docs/user/main.rst | 7 ++- bsd-user/main.c| 5 +++-- 2 files changed, 9 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v3 04/10] linux-user: Add '-one-insn-per-tb' option equivalent to '-singlestep'
On 17/4/23 18:40, 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
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
---
docs/user/main.rst | 7 ++-
linux-user/main.c | 9 ++---
2 files changed, 12 insertions(+), 4 deletions(-)
@@ -500,8 +500,11 @@ static const struct qemu_argument arg_table[] = {
"logfile", "write logs to 'logfile' (default stderr)"},
{"p", "QEMU_PAGESIZE",true, handle_arg_pagesize,
"pagesize", "set the host page size to 'pagesize'"},
-{"singlestep", "QEMU_SINGLESTEP", false, handle_arg_singlestep,
- "", "run in singlestep mode"},
+{"one-insn-per-tb",
+ "QEMU_ONE_INSN_PER_TB", false, handle_arg_one_insn_per_tb,
+ "", "run with one guest instruction per emulated TB"},
+{"singlestep", "QEMU_SINGLESTEP", false, handle_arg_one_insn_per_tb,
+ "", "deprecated synonym for -one-insn-per-tb"},
Maybe worth mentioning QEMU_ONE_INSN_PER_TB too here:
"deprecated synonyms for -one-insn-per-tb and QEMU_ONE_INSN_PER_TB"
Reviewed-by: Philippe Mathieu-Daudé
{"strace", "QEMU_STRACE", false, handle_arg_strace,
"", "log system calls"},
{"seed", "QEMU_RAND_SEED", true, handle_arg_seed,
Re: [PATCH v3 10/10] hmp: Deprecate 'singlestep' member of StatusInfo
On 17/4/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: Philippe Mathieu-Daudé
Re: [PATCH v3 09/10] qapi/run-state.json: Fix missing newline at end of file
On 17/4/23 18:40, Peter Maydell wrote: The run-state.json file is missing a trailing newline; add it. Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson --- 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: Philippe Mathieu-Daudé
Re: [PATCH v3 08/10] hmp: Add 'one-insn-per-tb' command equivalent to 'singlestep'
On 17/4/23 18:40, 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 Reviewed-by: Dr. David Alan Gilbert Reviewed-by: Richard Henderson --- 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: Philippe Mathieu-Daudé
Re: [PATCH v3 07/10] accel/tcg: Report one-insn-per-tb in 'info jit', not 'info status'
On 17/4/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. Ideally we should have a AccelClass::qmp_query_info() handler optionally implemented by accelerators, and a single HMP 'info accel' which convert the QMP handler result to human text. This is a start :) Reviewed-by: Philippe Mathieu-Daudé --- accel/tcg/monitor.c | 14 ++ softmmu/runstate-hmp-cmds.c | 5 ++--- 2 files changed, 16 insertions(+), 3 deletions(-)
Re: [PATCH v3 06/10] Document that -singlestep command line option is deprecated
On 17/4/23 18:40, 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 Reviewed-by: Richard Henderson --- docs/about/deprecated.rst | 16 qemu-options.hx | 5 +++-- tcg/tci/README| 2 +- 3 files changed, 20 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v3 03/10] accel/tcg: Use one_insn_per_tb global instead of old singlestep global
On 17/4/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 * 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: Philippe Mathieu-Daudé
Re: [PATCH v3 02/10] softmmu: Don't use 'singlestep' global in QMP and HMP commands
On 17/4/23 18:40, 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 Reviewed-by: Richard Henderson --- softmmu/runstate-hmp-cmds.c | 18 -- softmmu/runstate.c | 10 +- 2 files changed, 25 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v4 2/5] docs/about/deprecated: Deprecate the qemu-system-i386 binary
On 6/3/23 15:06, Daniel P. Berrangé wrote:
On Mon, Mar 06, 2023 at 02:48:16PM +0100, Thomas Huth wrote:
On 06/03/2023 10.27, Daniel P. Berrangé wrote:
On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
[...] If a 32-bit CPU guest
+environment should be enforced, you can switch off the "long mode" CPU
+flag, e.g. with ``-cpu max,lm=off``.
I had the idea to check this today and this is not quite sufficient,
[...]
A further difference is that qemy-system-i686 does not appear to enable
the 'syscall' flag, but I've not figured out where that difference is
coming from in the code.
I think I just spotted this by accident in target/i386/cpu.c
around line 637:
#ifdef TARGET_X86_64
#define TCG_EXT2_X86_64_FEATURES (CPUID_EXT2_SYSCALL | CPUID_EXT2_LM)
#else
#define TCG_EXT2_X86_64_FEATURES 0
#endif
Hmm, so right now the difference between qemu-system-i386 and
qemu-system-x86_64 is based on compile time conditionals. So we
have the burden of building everything twice and also a burden
of testing everything twice.
If we eliminate qemu-system-i386 we get rid of our own burden,
but users/mgmt apps need to adapt to force qemu-system-x86_64
to present a 32-bit system.
What about if we had qemu-system-i386 be a hardlink to
qemu-system-x86_64, and then changed behaviour based off the
executed binary name ?
ie if running qemu-system-i386, we could present a 32-bit CPU by
default. We eliminate all of our double compilation burden still.
We still have extra testing burden, but it is in a fairly narrow
area, so does not imply x2 the testing burden just $small-percentage
extra testing ? That would means apps/users would not need to change
at all, but we still get most of the win we're after on the
QEMU side
Essentially #ifdef TARGET_X86_64 would be change 'if (is_64bit) {...}'
in a handful of places, with 'bool is_64bit' initialized in main() from
argv[0] ?
That is what Alex suggested me to do with ARM binaries as a prototype
of unifying 32/64-bit binaries, avoiding to break users scripts.
Re: [PATCH v4 4/5] docs/about/deprecated: Deprecate 32-bit arm hosts for system emulation
On 6/3/23 09:46, Thomas Huth wrote: For running QEMU in system emulation mode, the user needs a rather strong host system, i.e. not only an embedded low-frequency controller. All recent beefy arm host machines should support 64-bit now, it's unlikely that anybody is still seriously using QEMU on a 32-bit arm CPU, so we deprecate the 32-bit arm hosts here to finally save use some time and precious CI minutes. Reviewed-by: Daniel P. Berrangé Reviewed-by: Wilfred Mallawa Signed-off-by: Thomas Huth --- docs/about/deprecated.rst | 9 + 1 file changed, 9 insertions(+) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v4 3/5] gitlab-ci.d/crossbuilds: Drop the i386 system emulation job
On 6/3/23 09:46, Thomas Huth wrote: Hardly anybody still uses 32-bit x86 environments for running QEMU with full system emulation, so let's stop wasting our scarce CI minutes with this job. (There are still the 32-bit MinGW and TCI jobs around for having some compile test coverage on 32-bit) Reviewed-by: Daniel P. Berrangé Reviewed-by: Wilfred Mallawa Signed-off-by: Thomas Huth --- .gitlab-ci.d/crossbuilds.yml | 10 -- 1 file changed, 10 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v3 3/6] gitlab-ci.d/crossbuilds: Drop the i386 jobs
On 3/3/23 11:14, Thomas Huth wrote: Hardly anybody still uses 32-bit x86 environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs. (There are still the 32-bit MinGW and TCI jobs around for having some compile test coverage on 32-bit, and the dockerfile can stay in case someone wants to reproduce a flaw locally) Reviewed-by: Daniel P. Berrangé Reviewed-by: Wilfred Mallawa Signed-off-by: Thomas Huth --- .gitlab-ci.d/crossbuilds.yml | 20 1 file changed, 20 deletions(-) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index d3a31a2112..b96439146f 100644 --- a/.gitlab-ci.d/crossbuilds.yml +++ b/.gitlab-ci.d/crossbuilds.yml @@ -43,26 +43,6 @@ cross-arm64-user: variables: IMAGE: debian-arm64-cross -cross-i386-system: - extends: -- .cross_system_build_job -- .cross_test_artifacts - needs: -job: i386-fedora-cross-container - variables: -IMAGE: fedora-i386-cross -MAKE_CHECK_ARGS: check-qtest - -cross-i386-user: - extends: -- .cross_user_build_job -- .cross_test_artifacts - needs: -job: i386-fedora-cross-container - variables: -IMAGE: fedora-i386-cross -MAKE_CHECK_ARGS: check The cross-i386-user job might require an Ack from Laurent, so cc'ing him.
Re: [PATCH v2 4/6] docs/about/deprecated: Deprecate the qemu-system-arm binary
On 2/3/23 17:31, Thomas Huth wrote: qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now. Signed-off-by: Thomas Huth --- docs/about/deprecated.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a30aa8dfdf..21ce70b5c9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Thus users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary instead. +``qemu-system-arm`` binary (since 8.0) +'' + +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``. The +latter was mainly a requirement for running KVM on 32-bit arm hosts, but +this 32-bit KVM support has been removed some years ago already (see: s/some/few/? +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=541ad0150ca4 +). Thus the QEMU project will drop the ``qemu-system-arm`` binary in a +future release. Use ``qemu-system-aarch64`` instead. If we unify, wouldn't it be simpler to name the single qemu-system binary emulating various ARM architectures as 'qemu-system-arm'?
Re: [PATCH v2 0/6] Deprecate support for 32-bit x86 and arm hosts
On 2/3/23 17:31, Thomas Huth wrote: We're struggling quite badly with our CI minutes on the shared gitlab runners, so we urgently need to think of ways to cut down our supported build and target environments. qemu-system-i386 and qemu-system-arm are not really required anymore, since nobody uses KVM on the corresponding systems for production anymore, and the -x86_64 and -arch64 variants are a proper superset of those binaries. So it's time to deprecate them and the corresponding 32-bit host environments now. This is a follow-up patch series from the previous discussion here: https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-th...@redhat.com/ where people still mentioned that there is still interest in certain support for 32-bit host hardware. But as far as I could see, there is no real need for 32-bit x86 host support and for system emulation on 32-bit arm hosts anymore, so it should be fine if we drop these host environments soon (these are also the two architectures that contribute the most to the long test times in our CI, so we would benefit a lot by dropping those). It is not clear from your cover that the deprecation only concern system emulation on these hosts, not user emulation. I wonder about tools. Apparently they depend on sysemu now. I was building a 'configure --enable-tools --disable-system' but now it is empty.
Re: [PATCH v2 6/6] gitlab-ci.d/crossbuilds: Drop the 32-bit arm system emulation jobs
On 2/3/23 17:31, Thomas Huth wrote: Hardly anybody still uses 32-bit arm environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs. Signed-off-by: Thomas Huth --- .gitlab-ci.d/crossbuilds.yml | 14 -- 1 file changed, 14 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 1/2] docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386
On 28/2/23 09:59, Michael S. Tsirkin wrote: On Mon, Feb 27, 2023 at 10:21:14AM -1000, Richard Henderson wrote: 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. Will the same occur with 64-bit hosts when we introduce a 128-bit target? If so, there is no much code we'll be able to drop, We should probably block multi-threading on 32 bit then. so this sound a user experience fix.
Re: [PATCH 1/2] docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386
On 27/2/23 21: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. Doesn't qemu-system-i386 start the CPU in a different mode that qemu-system-x86_64? Last time we discussed it, we mention adding -32 and -64 CLI flags to maintain compat, and IIRC this flag would add boot code to switch the CPU in 32-b. But then maybe I misunderstood. Thomas said, "CPUs must start in the same mode they start in HW". 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. In fact, keeping this support around forces correct use of posix APIs such as e.g. PRIx64 which makes the code base more future-proof.
Re: [PATCH v2 06.5/18] hw/ide/piix: Allow using PIIX3-IDE as standalone PCI function
On 20/2/23 10:52, Philippe Mathieu-Daudé wrote:
On 20/2/23 10:10, Gerd Hoffmann wrote:
On Mon, Feb 20, 2023 at 09:00:44AM +0100, Philippe Mathieu-Daudé wrote:
In order to allow Frankenstein uses such plugging a PIIX3
IDE function on a ICH9 chipset (which already exposes AHCI
ports...) as:
$ qemu-system-x86_64 -M q35 -device piix3-ide
add a kludge to automatically wires the IDE IRQs on an ISA
bus exposed by a PCI-to-ISA bridge (usually function #0).
Restrict this kludge to the PIIX3.
Well. On physical hardware you have a config switch in the bios
setup which turns off sata and enables ide instead (i.e. the
chipset implements both and can be configured to expose the one
or the other).
If we want support ide for q35 we should IMHO do something simliar
instead of making piix-ide user-pluggable. We already have -machine
q35,sata={on,off}. We could extend that somehow, by adding
ide={on,off}, or by using storage={sata,ide,off} instead.
This has been discussed now and then in the past and the usual
conclusion was that there is little reason to implement that given
that you can just use the 'pc' machine type. For guests that old
that they can't handle sata storage this is usually the better fit
anyway ...
I think we might not using the same words, but agree on the goal :)
Since this has been discussed in the past, I suppose some users
want this config available. Why are they using this convoluted
config? Could it be due to lack of good documentation?
Do we really need a storage={sata,ide,off} flag? I don't see its
value. Help cloud users to have a sane config?
(old) boards exist with both IDE/SATA and we might want to emulate
some of them, but IMO such boards should be well modeled (Either
in C or later in declarative language) but not automagically created
from CLI.
IOW:
- using PIIX on Q35 (or any machine exposing a PCI bus) is
acceptable, but the chipset should be instantiated as a whole.
So to be clear I'm not against "-M q35 -device piix3", we should
keep that working.
- we shouldn't try to maintain such Frankenstein corner cases which
force us to add complex hacks, hard to remove, which limit us
in implementing new features and cost us a lot of maintenance /
testing time.
So I propose we deprecate this config so we can keep going forward.
(More generally I'd like to not allow instantiating part of chipset).
So there is a design problem here.
- ICH expose ISA bridge (fn0) with ISA IRQs.
- internal ICH SATA fn wires the IRQs 14/15
if we plug a cripple piix3-ide function which lookup for fn0 (ISA
bridge) to wire its IRQs 14/15, we end up having 2 devices able
to raise/lower IRQs while in the BQL iothread.
IOW, one device raise an IRQ, while the other lower the same IRQ...
thus the 1st device IRQ is acked from HW and missed from guest SW.
Daniel tested such config (2 drives used concurrently, one on IDE
and one on SATA) and reported "lost interrupt" from dmesg.
I haven't investigated using a SplitIrq object, but this doesn't
match real hw.
If user want to suffer from poor quality, we should find a different
(valid) config to add IDE drives to Q35 machine. Or maybe it is
a documentation problem, and we should redirect the users to the
best config.
Ref about similar problems:
https://lore.kernel.org/qemu-devel/b8d457d1-40b1-adb5-a2ac-98070f62a...@eik.bme.hu/
https://lore.kernel.org/qemu-devel/y%2fsu8eb2nio0i...@redhat.com/
PD: For the remote-pci it is different because it is based on
PCIe which serializes MSIX IRQs, so no way to overwrite one.
Re: [PATCH v2] Deprecate the "-no-acpi" command line switch
On 24/2/23 10:05, Thomas Huth wrote: Similar to "-no-hpet", the "-no-acpi" switch is a legacy command line option that should be replaced with the "acpi" machine parameter nowadays. Signed-off-by: Thomas Huth --- v2: Fixed stypid copy-n-paste bug (Thanks to Sunil for spotting it!) docs/about/deprecated.rst | 6 ++ softmmu/vl.c | 1 + 2 files changed, 7 insertions(+) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] Deprecate the "-no-acpi" command line switch
On 24/2/23 08:34, Thomas Huth wrote: Similar to "-no-hpet", the "-no-acpi" switch is a legacy command line option that should be replaced with the "acpi" machine parameter nowadays. Signed-off-by: Thomas Huth --- docs/about/deprecated.rst | 6 ++ softmmu/vl.c | 1 + 2 files changed, 7 insertions(+) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v3 2/2] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and Persistent)
On 21/2/23 15:00, Jonathan Cameron wrote: From: Gregory Price This commit enables each CXL Type-3 device to contain one volatile memory region and one persistent region. Two new properties have been added to cxl-type3 device initialization: [volatile-memdev] and [persistent-memdev] The existing [memdev] property has been deprecated and will default the memory region to a persistent memory region (although a user may assign the region to a ram or file backed region). It cannot be used in combination with the new [persistent-memdev] property. Partitioning volatile memory from persistent memory is not yet supported. Volatile memory is mapped at DPA(0x0), while Persistent memory is mapped at DPA(vmem->size), per CXL Spec 8.2.9.8.2.0 - Get Partition Info. Signed-off-by: Gregory Price Reviewed-by: Davidlohr Bueso Reviewed-by: Fan Ni Tested-by: Fan Ni Signed-off-by: Jonathan Cameron --- v3: - Don't set the DVSEC range register base address v2: - Fixed an off by one in address space selection. - Gather tags. --- docs/system/devices/cxl.rst| 49 -- hw/cxl/cxl-mailbox-utils.c | 26 +-- hw/mem/cxl_type3.c | 294 + include/hw/cxl/cxl_device.h| 11 +- tests/qtest/bios-tables-test.c | 8 +- tests/qtest/cxl-test.c | 76 +++-- 6 files changed, 353 insertions(+), 111 deletions(-) diff --git a/docs/system/devices/cxl.rst b/docs/system/devices/cxl.rst index f25783a4ec..89a41cff73 100644 --- a/docs/system/devices/cxl.rst +++ b/docs/system/devices/cxl.rst @@ -300,7 +300,7 @@ Example topology involving a switch:: Example command lines - -A very simple setup with just one directly attached CXL Type 3 device:: +A very simple setup with just one directly attached CXL Type 3 Persistent Memory device:: qemu-system-aarch64 -M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max \ ... @@ -308,7 +308,28 @@ A very simple setup with just one directly attached CXL Type 3 device:: -object memory-backend-file,id=cxl-lsa1,share=on,mem-path=/tmp/lsa.raw,size=256M \ -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ - -device cxl-type3,bus=root_port13,memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0 \ + -device cxl-type3,bus=root_port13,persistent-memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0 \ + -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G + +A very simple setup with just one directly attached CXL Type 3 Volatile Memory device:: + + qemu-system-aarch64 -M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max \ + ... + -object memory-backend-ram,id=vmem0,share=on,size=256M \ + -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ + -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ + -device cxl-type3,bus=root_port13,volatile-memdev=vmem0,id=cxl-vmem0 \ + -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G + +The same volatile setup may optionally include an LSA region:: + + qemu-system-aarch64 -M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max \ + ... + -object memory-backend-ram,id=vmem0,share=on,size=256M \ + -object memory-backend-file,id=cxl-lsa0,share=on,mem-path=/tmp/lsa.raw,size=256M \ + -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ + -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ + -device cxl-type3,bus=root_port13,volatile-memdev=vmem0,lsa=cxl-lsa0,id=cxl-vmem0 \ -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G A setup suitable for 4 way interleave. Only one fixed window provided, to enable 2 way @@ -328,13 +349,13 @@ the CXL Type3 device directly attached (no switches).:: -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ -device pxb-cxl,bus_nr=222,bus=pcie.0,id=cxl.2 \ -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ - -device cxl-type3,bus=root_port13,memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0 \ + -device cxl-type3,bus=root_port13,persistent-memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0 \ -device cxl-rp,port=1,bus=cxl.1,id=root_port14,chassis=0,slot=3 \ - -device cxl-type3,bus=root_port14,memdev=cxl-mem2,lsa=cxl-lsa2,id=cxl-pmem1 \ + -device cxl-type3,bus=root_port14,persistent-memdev=cxl-mem2,lsa=cxl-lsa2,id=cxl-pmem1 \ -device cxl-rp,port=0,bus=cxl.2,id=root_port15,chassis=0,slot=5 \ - -device cxl-type3,bus=root_port15,memdev=cxl-mem3,lsa=cxl-lsa3,id=cxl-pmem2 \ + -device cxl-type3,bus=root_port15,persistent-memdev=cxl-mem3,lsa=cxl-lsa3,id=cxl-pmem2 \ -device cxl-rp,port=1,bus=cxl.2,id=root_port16,chassis=0,slot=6 \ - -device cxl-type3,bus=root_port16,memdev=cxl-mem4,lsa=cxl-lsa4,id=cxl-pmem3 \ + -device cxl-type3,bus=root_port16,persistent-memdev=cxl-mem4,lsa=cxl-lsa4,id=cxl-pmem3 \ -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.targets.1=cxl.2,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=8k An example of 4 devices below a switch suitable for 1, 2 or 4 way interleave:: @@ -354,15
Re: [PATCH v2 06.5/18] hw/ide/piix: Allow using PIIX3-IDE as standalone PCI function
On 20/2/23 10:10, Gerd Hoffmann wrote:
On Mon, Feb 20, 2023 at 09:00:44AM +0100, Philippe Mathieu-Daudé wrote:
In order to allow Frankenstein uses such plugging a PIIX3
IDE function on a ICH9 chipset (which already exposes AHCI
ports...) as:
$ qemu-system-x86_64 -M q35 -device piix3-ide
add a kludge to automatically wires the IDE IRQs on an ISA
bus exposed by a PCI-to-ISA bridge (usually function #0).
Restrict this kludge to the PIIX3.
Well. On physical hardware you have a config switch in the bios
setup which turns off sata and enables ide instead (i.e. the
chipset implements both and can be configured to expose the one
or the other).
If we want support ide for q35 we should IMHO do something simliar
instead of making piix-ide user-pluggable. We already have -machine
q35,sata={on,off}. We could extend that somehow, by adding
ide={on,off}, or by using storage={sata,ide,off} instead.
This has been discussed now and then in the past and the usual
conclusion was that there is little reason to implement that given
that you can just use the 'pc' machine type. For guests that old
that they can't handle sata storage this is usually the better fit
anyway ...
I think we might not using the same words, but agree on the goal :)
Since this has been discussed in the past, I suppose some users
want this config available. Why are they using this convoluted
config? Could it be due to lack of good documentation?
Do we really need a storage={sata,ide,off} flag? I don't see its
value. Help cloud users to have a sane config?
(old) boards exist with both IDE/SATA and we might want to emulate
some of them, but IMO such boards should be well modeled (Either
in C or later in declarative language) but not automagically created
from CLI.
IOW:
- using PIIX on Q35 (or any machine exposing a PCI bus) is
acceptable, but the chipset should be instantiated as a whole.
So to be clear I'm not against "-M q35 -device piix3", we should
keep that working.
- we shouldn't try to maintain such Frankenstein corner cases which
force us to add complex hacks, hard to remove, which limit us
in implementing new features and cost us a lot of maintenance /
testing time.
So I propose we deprecate this config so we can keep going forward.
(More generally I'd like to not allow instantiating part of chipset).
Re: [PATCH v2 07/18] hw/ide/piix: Ensure IDE output IRQs are wired at realization
+Daniel, Igor, Marcel & libvirt
On 16/2/23 16:33, Philippe Mathieu-Daudé wrote:
On 16/2/23 15:43, Bernhard Beschow wrote:
On Wed, Feb 15, 2023 at 5:20 PM Philippe Mathieu-Daudé
mailto:phi...@linaro.org>> wrote:
Ensure both IDE output IRQ lines are wired.
We can remove the last use of isa_get_irq(NULL).
Signed-off-by: Philippe Mathieu-Daudé mailto:phi...@linaro.org>>
---
hw/ide/piix.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 9d876dd4a7..b75a4ddcca 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -133,14 +133,17 @@ static bool pci_piix_init_bus(PCIIDEState *d,
unsigned i, Error **errp)
static const struct {
int iobase;
int iobase2;
- int isairq;
} port_info[] = {
- {0x1f0, 0x3f6, 14},
- {0x170, 0x376, 15},
+ {0x1f0, 0x3f6},
+ {0x170, 0x376},
};
int ret;
- qemu_irq irq_out = d->irq[i] ? : isa_get_irq(NULL,
port_info[i].isairq);
+ if (!d->irq[i]) {
+ error_setg(errp, "output IDE IRQ %u not connected", i);
+ return false;
+ }
+
ide_bus_init(>bus[i], sizeof(d->bus[i]), DEVICE(d), i, 2);
ret = ide_init_ioport(>bus[i], NULL, port_info[i].iobase,
port_info[i].iobase2);
@@ -149,7 +152,7 @@ static bool pci_piix_init_bus(PCIIDEState *d,
unsigned i, Error **errp)
object_get_typename(OBJECT(d)), i);
return false;
}
- ide_bus_init_output_irq(>bus[i], irq_out);
+ ide_bus_init_output_irq(>bus[i], d->irq[i]);
bmdma_init(>bus[i], >bmdma[i], d);
d->bmdma[i].bus = >bus[i];
-- 2.38.1
This now breaks user-created piix3-ide:
qemu-system-x86_64 -M q35 -device piix3-ide
Results in:
qemu-system-x86_64: -device piix3-ide: output IDE IRQ 0 not connected
Thank you for this real-life-impossible-but-exists-in-QEMU test-case!
Do we really want to maintain this Frankenstein use case?
1/ Q35 comes with a PCIe bus on which sits a ICH chipset, which already
contains a AHCI function exposing multiple IDE buses.
What is the point on using an older tech?
2/ Why can we plug a PCI function on a PCIe bridge without using a
pcie-pci-bridge?
3/ Chipsets come as a whole. Software drivers might expect all PCI
functions working (Linux considering each function individually
is not the norm)
I get your use case working with the following diff [*]:
-- >8 --
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 74e2f4288d..cb1628963a 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -140,8 +140,19 @@ static bool pci_piix_init_bus(PCIIDEState *d,
unsigned i, Error **errp)
};
if (!d->irq[i]) {
-error_setg(errp, "output IDE IRQ %u not connected", i);
-return false;
+if (DEVICE_GET_CLASS(d)->user_creatable) {
+/* Returns NULL unless there is exactly one ISA bus */
+Object *isabus = object_resolve_path_type("", TYPE_ISA_BUS,
NULL);
+
+if (!isabus) {
+error_setg(errp, "Unable to find a single ISA bus");
+return false;
+}
+d->irq[i] = isa_bus_get_irq(ISA_BUS(isabus), 14 + i);
+} else {
+error_setg(errp, "output IDE IRQ %u not connected", i);
+return false;
+}
}
ide_bus_init(>bus[i], sizeof(d->bus[i]), DEVICE(d), i, 2);
@@ -201,6 +212,13 @@ static void piix3_ide_class_init(ObjectClass
*klass, void *data)
k->class_id = PCI_CLASS_STORAGE_IDE;
set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
dc->hotpluggable = false;
+/*
+ * This function is part of a Super I/O chip and shouldn't be user
+ * creatable. However QEMU accepts impossible hardware setups such
+ * plugging a PIIX IDE function on a ICH ISA bridge.
+ * Keep this Frankenstein (ab)use working.
+ */
+dc->user_creatable = true;
}
static const TypeInfo piix3_ide_info = {
@@ -224,6 +242,8 @@ static void piix4_ide_class_init(ObjectClass *klass,
void *data)
k->class_id = PCI_CLASS_STORAGE_IDE;
set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
dc->hotpluggable = false;
+/* Reason: Part of a Super I/O chip */
+dc->user_creatable = false;
}
---
But the hardware really looks Frankenstein now:
(qemu) info qom-tree
/machine (pc-q35-8.0-machine)
/peripheral-anon (container)
/device[0] (piix3-ide)
/bmdma[0] (memory-region)
/bmdma[1] (memory-region)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/ide.6 (IDE)
/ide.7 (IDE)
/ide[0] (memory-region)
/ide[1
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
(Cc'ing Huacai & Jiaxun).
On 17/2/23 17:38, Paolo Bonzini wrote:
On 2/17/23 11:47, Daniel P. Berrangé 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?
Which 32-bit hosts does Linux still provide KVM support for.
All except ARM: MIPS, x86, PPC and RISC-V.
I would like to remove x86, but encountered some objections.
MIPS, nobody is really using it I think.
32-bit was added in 2014, commit 222e7d11e7 ("target-mips: Enable KVM
support in build system"). I'm not aware of anybody using it (even
testing it). I don't have hardware to test it (neither time).
We are still cross-compiling it although.
64-bit support was added recently (see commit aa2953fd16 "configure:
Add KVM target support for MIPS64") and is used (see commit fbc5884ce2
"meson.build: Re-enable KVM support for MIPS" from 2020), however I
tend to see it more as hobbyist use than production one. Besides it
is listed as 'Odd Fixes' in MAINTAINERS (still 2020, commit 134f7f7da1
"MAINTAINERS: Reactivate MIPS KVM CPUs").
So that leaves PPC and RISC-V.
If any, is there an EOL date for Linux 32-bit KVM support ?
No, and I don't think there's going to be one.
Paolo
Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events
On 14/2/23 13:17, Markus Armbruster wrote: Philippe Mathieu-Daudé writes: On 14/2/23 12:49, Markus Armbruster wrote: Daniel P. Berrangé writes: [...] What's the documented way to construct a QOM path, given only an ID as input ? QOM paths a gap in our documentation, even though the composition tree structure has been stable since day one, and is de facto ABI. Short answer: "/machine/peripheral/ID". Long answer follows. We have three "containers" under /machine that serve as parents for devices: * /machine/peripheral/ Parent of user-created devices with ID. Children are named "ID". Put there by qdev_set_id(), called from qdev_device_add_from_qdict(). On "user-created": Nothing stops board code to abuse qdev_set_id() for onboard devices, directly or indirectly, but it really, really shouldn't. * /machine/peripheral-anon/ Parent of user-created devices without ID. Children are named "device[N]", where N counts up from zero. Put there by qdev_set_id(), called from qdev_device_add_from_qdict(). Again, abuse by board code is possible, but would be wrong. Beware: a particular device's N changes when the set of devices created before it grows or shrinks. Messing with the machine type can change it (different onboard devices). * /machine/unattached/ Surrogate parent of onboard devices created without a parent. Put there by device_set_realized() (general case), qdev_connect_gpio_out_named() (input pins) , memory_region_do_init() (memory regions), qemu_create_machine() (the main sysbus). I believe this container was created as a convenience, so we don't have to retrofit parents to existing code. Probably abused ever since. Are you suggesting this is a stable interface and we can not move devices (like from /machine/unattached/ to /machine/peripheral/) without going thru the deprecation process? Difficult question! The point of not changing interfaces incompatibly without a grace period / deprecation process is not breaking users of the interface. When an interface has always worked a certain way, its users may well depend on it, whether it's documented or not. The question to ask is always "will this break users?" For documented aspects, we generally assume it will. Doesn't mean we can simply assume "won't" for undocumented aspects. Does this make sense? Yes, but I never considered the QOM paths as a stable interface... I'm very surprised. "Automatically assigned to /machine/unattached/" doesn't seem quite stable...
Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events
On 14/2/23 12:49, Markus Armbruster wrote: Daniel P. Berrangé writes: On Tue, Feb 14, 2023 at 10:25:22AM +0100, Peter Krempa wrote: On Tue, Feb 14, 2023 at 09:54:22 +0100, Markus Armbruster wrote: Daniel P. Berrangé writes: On Mon, Feb 13, 2023 at 05:01:01PM +0300, Vladimir Sementsov-Ogievskiy wrote: The device field is redundant, because QOM path always include device ID when this ID exist. The flipside to that view is that applications configuring QEMU are specifying the device ID for -device (CLI) / device_add (QMP) and not the QOM path. IOW, the device ID is the more interesting field than QOM path, so feels like the wrong one to be dropping. QOM path is a reliable way to identify a device. Device ID isn't: devices need not have one. Therefore, dropping the QOM path would be wrong. Is there any real benefit to dropping this ? The device ID is a trap for the unwary: relying on it is fine until you run into a scenario where you have to deal with devices lacking IDs. Note that libvirt's code is still using the 'device' bit rather than QOM path and the fix might not be entirely trivial although should not be too hard. What's the documented way to construct a QOM path, given only an ID as input ? QOM paths a gap in our documentation, even though the composition tree structure has been stable since day one, and is de facto ABI. Short answer: "/machine/peripheral/ID". Long answer follows. We have three "containers" under /machine that serve as parents for devices: * /machine/peripheral/ Parent of user-created devices with ID. Children are named "ID". Put there by qdev_set_id(), called from qdev_device_add_from_qdict(). On "user-created": Nothing stops board code to abuse qdev_set_id() for onboard devices, directly or indirectly, but it really, really shouldn't. * /machine/peripheral-anon/ Parent of user-created devices without ID. Children are named "device[N]", where N counts up from zero. Put there by qdev_set_id(), called from qdev_device_add_from_qdict(). Again, abuse by board code is possible, but would be wrong. Beware: a particular device's N changes when the set of devices created before it grows or shrinks. Messing with the machine type can change it (different onboard devices). * /machine/unattached/ Surrogate parent of onboard devices created without a parent. Put there by device_set_realized() (general case), qdev_connect_gpio_out_named() (input pins) , memory_region_do_init() (memory regions), qemu_create_machine() (the main sysbus). I believe this container was created as a convenience, so we don't have to retrofit parents to existing code. Probably abused ever since. Are you suggesting this is a stable interface and we can not move devices (like from /machine/unattached/ to /machine/peripheral/) without going thru the deprecation process?
Re: [PATCH 1/2] log: Add separate debug option for logging invalid memory accesses
On 13/2/23 18:17, Peter Xu wrote:
On Mon, Feb 13, 2023 at 05:34:04PM +0100, BALATON Zoltan wrote:
On Mon, 13 Feb 2023, Peter Xu wrote:
On Mon, Feb 13, 2023 at 03:47:42PM +0100, BALATON Zoltan wrote:
On Mon, 13 Feb 2023, Peter Xu wrote:
On Mon, Feb 13, 2023 at 12:41:29PM +0100, Thomas Huth wrote:
On 07/02/2023 17.33, BALATON Zoltan wrote:
On Tue, 31 Jan 2023, BALATON Zoltan wrote:
On Thu, 19 Jan 2023, BALATON Zoltan wrote:
Currently -d guest_errors enables logging of different invalid actions
by the guest such as misusing hardware, accessing missing features or
invalid memory areas. The memory access logging can be quite verbose
which obscures the other messages enabled by this debug switch so
separate it by adding a new -d memaccess option to make it possible to
control it independently of other guest error logs.
Signed-off-by: BALATON Zoltan
Ping? Could somebody review and pick it up please?
Ping?
Patch makes sense to me and looks fine, so:
Reviewed-by: Thomas Huth
... I think this should go via one of the "Memory API" maintainers branches?
Paolo? Peter? David?
Paolo normally does the pull, I assume that'll still be the case. The
patch looks good to me if Phil's comment will be addressed on merging with
the old mask, which makes sense to me:
Keeping the old mask kind of defies the purpose. I've tried to explain that
in the commit message but now that two of you did not get it maybe that
message needs to be clarified instead?
I think it's clear enough. My fault to not read carefully into the
message, sorry.
However, could you explain why a memory_region_access_valid() failure
shouldn't belong to LOG_GUEST_ERROR?
commit e54eba1986f6c4bac2951e7f90a849cd842e25e4
Author: Peter Maydell
Date: Thu Oct 18 14:11:35 2012 +0100
qemu-log: Add new log category for guest bugs
Add a new category for device models to log guest behaviour
which is likely to be a guest bug of some kind (accessing
nonexistent registers, reading 32 bit wide registers with
a byte access, etc). Making this its own log category allows
those who care (mostly guest OS authors) to see the complaints
without bothering most users.
Such an illegal memory access is definitely a suitable candidate of guest
misbehave to me.
Problem is that a lot of machines have unimplemented hardware that are valid
on real machine but we don't model them so running guests which access these
generate constant flow of unassigned memory access log which obscures the
actual guest_errors when an modelled device is accessed in unexpected ways.
For an example you can try booting MorphOS on mac99,via=pmu as described
here: http://zero.eik.bme.hu/~balaton/qemu/amiga/#morphos
(or the pegasos2 command too). We could add dummy registers to silence these
but I think it's better to either implement it correctly or leave it
unimplemented so we don't hide errors by the dummy implementation.
Not to mention Phil always have a good point that you may be violating
others using guest_error already so what they wanted to capture can
misterious going away without noticing, even if it may service your goal.
IOW it's a slight ABI and I think we ned justification to break it.
Probably this should be documented in changelog or do we need depracation
for a debug option meant for developers mostly? I did not think so. Also I
can't think of other way to solve this without changing what guest_erorrs do
unless we change the name of that flag as well. Also not that when this was
originally added it did not contain mem access logs as those were controlled
by a define in memory.c until Philippe changed it and added them to
guest_errors. So in a way I want the previous functionality back.
I see, thanks.
Indeed it's only a debug option, so I don't know whether the abi needs the
attention here.
I quickly looked at all the masks and afaict this is really a special and
very useful one that if I'm a cloud provider I can run some script trying
to capture those violations using this bit to identify suspecious guests.
So I think it would still be great to not break it if possible, IMHO.
Since currently I don't see an immediate limitation of having qemu log mask
being a single bit for each of the entry, one way to satisfy your need (and
also keep the old behavior, iiuc), is to make guest_errors a sugar syntax
to cover 2 bits. It shouldn't be complicated at all, I assume:
+/* This covers the generic guest errors besides memory violations */
#define LOG_GUEST_ERROR(1 << 11)
+/*
+ * This covers the guest errors on memory violations; see LOG_GUEST_ERROR
+ * for generic guest errors.
+ */
+#define LOG_GUEST_ERROR_MEM (1 << 21)
+#define LOG_GUEST_ERROR_ALL (LOG_GUEST_ERROR | LOG_GUEST_ERROR_MEM)
-{ LOG_GUEST_ERROR, "guest_errors",
+{ LOG_GUEST_ERROR_ALL, "guest_errors",
Then somehow squashed with your changes. It'll make "guest_errors" not
exactly matching the name of LOG_* but I think it may not be a big concern.
Re: [RFC PATCH] build: deprecate --enable-gprof builds and remove from CI
On 31/1/23 11:36, Philippe Mathieu-Daudé wrote: On 31/1/23 10:42, Alex Bennée wrote: As gprof relies on instrumentation you rarely get useful data compared to a real optimised build. Lets deprecate the build option and simplify the CI configuration as a result. Signed-off-by: Alex Bennée Cc: Thomas Huth --- docs/about/deprecated.rst | 14 ++ meson.build | 7 ++- .gitlab-ci.d/buildtest.yml | 19 --- meson_options.txt | 3 ++- 4 files changed, 26 insertions(+), 17 deletions(-) Reviewed-by: Philippe Mathieu-Daudé (Tracked as https://gitlab.com/qemu-project/qemu/-/issues/1338)
Re: [RFC PATCH] build: deprecate --enable-gprof builds and remove from CI
On 31/1/23 10:42, Alex Bennée wrote: As gprof relies on instrumentation you rarely get useful data compared to a real optimised build. Lets deprecate the build option and simplify the CI configuration as a result. Signed-off-by: Alex Bennée Cc: Thomas Huth --- docs/about/deprecated.rst | 14 ++ meson.build| 7 ++- .gitlab-ci.d/buildtest.yml | 19 --- meson_options.txt | 3 ++- 4 files changed, 26 insertions(+), 17 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
On 31/1/23 00:33, Richard Henderson wrote: 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. I am not concerned by the RAM limit but by the community maintenance cost. As of 2023, QEMU v7.2.0 is usable on 32-bit. Fixes will be backported in the v7.2.x stable releases. Maybe this is enough for 32-bit host users; and planning the unavailability of features released in v8.2 or v9.0 for 32-bit hosts doesn't seem unreasonable. Stefan Weil once posted stats of Win32 vs Win64 binary downloads from last year IIRC, and Win32 is still consumed (but maybe the difference comes from mirrors or users always downloading both versions). WRT i686, if your example is "i686 useremu on non-x86 embedded 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 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? WRT i686, if your example is "i686 useremu on non-x86 embedde router" then any 32-bit host is potentially interested, not only arm32. I remember being able to run armhf binaries on armel hosts (and vice versa) was useful 7 years ago. Today I have no clue, we could poll the community and some distributions.
Re: [PATCH v2] i386: Deprecate the -no-hpet QEMU command line option
On 29/12/22 12:49, Thomas Huth wrote: The HPET setting has been turned into a machine property a while ago already, so we should finally do the next step and deprecate the legacy CLI option, too. Signed-off-by: Thomas Huth --- v2: - Rebased to current version from master branch / adjusted version info - Dropped the descrpition in hw/i386/pc.c (already done via another patch) Note: The "hpet" property should now show up in the output of the "query-command-line-options" QMP command since commit 2f129fc107b4a, so it should be feasible for libvirt now to properly probe for the property . docs/about/deprecated.rst | 6 ++ softmmu/vl.c | 1 + qemu-options.hx | 2 +- 3 files changed, 8 insertions(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v2] MIPS: remove support for trap and emulate KVM
On 21/12/22 10: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(-)
Thanks, queued to mips-next.
[PATCH v2] MIPS: remove support for trap and emulate KVM
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(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 93affe3669..b28f50b22f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -199,15 +199,6 @@ deprecated. Use ``sections`` instead.
Member ``section-size`` in return value elements with meta-type ``uint64`` is
deprecated. Use ``sections`` instead.
-System accelerators
-
-MIPS ``Trap-and-Emul`` KVM support (since 6.0)
-''
-
-The MIPS ``Trap-and-Emul`` KVM host and guest support has been removed
-from Linux upstream kernel, declare it deprecated.
-
Host Architectures
--
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 63df9848fd..22b4b5d128 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -617,6 +617,15 @@ x86 ``Icelake-Client`` CPU (removed in 7.1)
There isn't ever Icelake Client CPU, it is some wrong and imaginary one.
Use ``Icelake-Server`` instead.
+System accelerators
+---
+
+MIPS "Trap-and-Emulate" KVM support (removed in 8.0)
+
+
+The MIPS "Trap-and-Emulate" KVM host and guest support was removed
+from Linux in 2021, and is not supported anymore by QEMU either.
+
System emulator machines
diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index e5050ecd3c..fed8b65f1e 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -58,6 +58,7 @@
#include "semihosting/semihost.h"
#include "hw/mips/cps.h"
#include "hw/qdev-clock.h"
+#include "target/mips/internal.h"
#define ENVP_PADDR 0x2000
#define ENVP_VADDR cpu_mips_phys_to_kseg0(NULL, ENVP_PADDR)
@@ -870,7 +871,6 @@ static uint64_t load_kernel(void)
uint32_t *prom_buf;
long prom_size;
int prom_index = 0;
-uint64_t (*xlate_to_kseg0) (void *opaque, uint64_t addr);
uint8_t rng_seed[32];
char rng_seed_hex[sizeof(rng_seed) * 2 + 1];
size_t rng_seed_prom_offset;
@@ -894,19 +894,10 @@ static uint64_t load_kernel(void)
}
/* Check where the kernel has been linked */
-if (kernel_entry & 0x8000ll) {
-if (kvm_enabled()) {
-error_report("KVM guest kernels must be linked in useg. "
- "Did you forget to enable CONFIG_KVM_GUEST?");
-exit(1);
-}
-
-xlate_to_kseg0 = cpu_mips_phys_to_kseg0;
-} else {
-/* if kernel entry is in useg it is probably a KVM T kernel */
-mips_um_ksegs_enable();
-
-xlate_to_kseg0 = cpu_mips_kvm_um_phys_to_kseg0;
+if (kernel_entry <= USEG_LIMIT) {
+error_report("Trap-and-Emul kernels (Linux CONFIG_KVM_GUEST)"
+ " are not supported");
+exit(1);
}
/* load initrd */
@@ -947,7 +938,7 @@ static uint64_t load_kernel(void)
if (initrd_size > 0) {
prom_set(prom_buf, prom_index++,
"rd_start=0x%" PRIx64 " rd_size=%" PRId64 " %s",
- xlate_to_kseg0(NULL, initrd_offset),
+ cpu_mips_phys_to_kseg0(NULL, initrd_offset),
initrd_size, loaderparams.kernel_cmdline);
} else {
prom_set(prom_buf, prom_index++, "%s", loaderparams.kernel_cmdline);
@@ -1039,11 +1030,6 @@ static void main_cpu_reset(void *opaque)
}
Re: [PATCH v2 08/11] vfio/migration: Remove VFIO migration protocol v1
On Mon, May 30, 2022 at 7:56 PM Avihai Horon wrote:
>
> Now that v2 protocol implementation has been added, remove the
> deprecated v1 implementation.
Worth a note in docs/about/deprecated.rst?
> Signed-off-by: Avihai Horon
> ---
> hw/vfio/common.c | 19 +-
> hw/vfio/migration.c | 698 +-
> hw/vfio/trace-events | 5 -
> include/hw/vfio/vfio-common.h | 5 -
> 4 files changed, 24 insertions(+), 703 deletions(-)
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 5541133ec9..00c6cb0ffe 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -355,14 +355,7 @@ static bool
> vfio_devices_all_dirty_tracking(VFIOContainer *container)
> return false;
> }
>
> -if (!migration->v2 &&
> -(vbasedev->pre_copy_dirty_page_tracking == ON_OFF_AUTO_OFF)
> &&
> -(migration->device_state_v1 & VFIO_DEVICE_STATE_V1_RUNNING))
> {
> -return false;
> -}
> -
> -if (migration->v2 &&
> -(vbasedev->pre_copy_dirty_page_tracking == ON_OFF_AUTO_OFF)
> &&
> +if ((vbasedev->pre_copy_dirty_page_tracking == ON_OFF_AUTO_OFF)
> &&
> (migration->device_state == VFIO_DEVICE_STATE_RUNNING ||
> migration->device_state == VFIO_DEVICE_STATE_RUNNING_P2P)) {
> return false;
> @@ -393,14 +386,8 @@ static bool
> vfio_devices_all_running_and_mig_active(VFIOContainer *container)
> return false;
> }
>
> -if (!migration->v2 &&
> -migration->device_state_v1 & VFIO_DEVICE_STATE_V1_RUNNING) {
> -continue;
> -}
> -
> -if (migration->v2 &&
> -(migration->device_state == VFIO_DEVICE_STATE_RUNNING ||
> - migration->device_state == VFIO_DEVICE_STATE_RUNNING_P2P)) {
> +if (migration->device_state == VFIO_DEVICE_STATE_RUNNING ||
> +migration->device_state == VFIO_DEVICE_STATE_RUNNING_P2P) {
> continue;
> } else {
> return false;
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index de68eadb09..852759e6ca 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -121,220 +121,6 @@ static int vfio_migration_set_state(VFIODevice
> *vbasedev,
> return 0;
> }
>
> -static inline int vfio_mig_access(VFIODevice *vbasedev, void *val, int count,
> - off_t off, bool iswrite)
> -{
> -int ret;
> -
> -ret = iswrite ? pwrite(vbasedev->fd, val, count, off) :
> -pread(vbasedev->fd, val, count, off);
> -if (ret < count) {
> -error_report("vfio_mig_%s %d byte %s: failed at offset 0x%"
> - HWADDR_PRIx", err: %s", iswrite ? "write" : "read",
> count,
> - vbasedev->name, off, strerror(errno));
> -return (ret < 0) ? ret : -EINVAL;
> -}
> -return 0;
> -}
> -
> -static int vfio_mig_rw(VFIODevice *vbasedev, __u8 *buf, size_t count,
> - off_t off, bool iswrite)
> -{
> -int ret, done = 0;
> -__u8 *tbuf = buf;
> -
> -while (count) {
> -int bytes = 0;
> -
> -if (count >= 8 && !(off % 8)) {
> -bytes = 8;
> -} else if (count >= 4 && !(off % 4)) {
> -bytes = 4;
> -} else if (count >= 2 && !(off % 2)) {
> -bytes = 2;
> -} else {
> -bytes = 1;
> -}
> -
> -ret = vfio_mig_access(vbasedev, tbuf, bytes, off, iswrite);
> -if (ret) {
> -return ret;
> -}
> -
> -count -= bytes;
> -done += bytes;
> -off += bytes;
> -tbuf += bytes;
> -}
> -return done;
> -}
> -
> -#define vfio_mig_read(f, v, c, o) vfio_mig_rw(f, (__u8 *)v, c, o,
> false)
> -#define vfio_mig_write(f, v, c, o) vfio_mig_rw(f, (__u8 *)v, c, o, true)
> -
> -#define VFIO_MIG_STRUCT_OFFSET(f) \
> - offsetof(struct vfio_device_migration_info,
> f)
> -/*
> - * Change the device_state register for device @vbasedev. Bits set in @mask
> - * are preserved, bits set in @value are set, and bits not set in either
> @mask
> - * or @value are cleared in device_state. If the register cannot be accessed,
> - * the resulting state would be invalid, or the device enters an error state,
> - * an error is returned.
> - */
> -
> -static int vfio_migration_v1_set_state(VFIODevice *vbasedev, uint32_t mask,
> - uint32_t value)
> -{
> -VFIOMigration *migration = vbasedev->migration;
> -VFIORegion *region = >region;
> -off_t dev_state_off = region->fd_offset +
> - VFIO_MIG_STRUCT_OFFSET(device_state);
> -uint32_t device_state;
> -int ret;
> -
> -ret = vfio_mig_read(vbasedev, _state,
Re: [PATCH 3/4] os-posix: refactor code handling the -chroot argument
On 4/3/22 12:56, Daniel P. Berrangé wrote: Change the change_root() function so that it takes its input as parameters instead of relying on static global variables. Signed-off-by: Daniel P. Berrangé --- os-posix.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 1/4] softmmu: remove deprecated --enable-fips option
On 4/3/22 12:56, Daniel P. Berrangé wrote: Users requiring FIPS support must build QEMU with either the libgcrypt or gnutls libraries for as the crytography backend. Signed-off-by: Daniel P. Berrangé --- docs/about/deprecated.rst | 12 docs/about/removed-features.rst | 11 +++ include/qemu/osdep.h| 3 --- os-posix.c | 8 qemu-options.hx | 10 -- ui/vnc.c| 7 --- util/osdep.c| 28 7 files changed, 11 insertions(+), 68 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v1 08/12] target/riscv: Handle KVM_EXIT_RISCV_SBI exit
Hi,
On 11/20/21 08:46, Yifei Jiang wrote:
> Use char-fe to handle console sbi call, which implement early
> console io while apply 'earlycon=sbi' into kernel parameters.
>
> Signed-off-by: Yifei Jiang
> Signed-off-by: Mingwang Li
> ---
> target/riscv/kvm.c | 42 -
> target/riscv/sbi_ecall_interface.h | 72 ++
> 2 files changed, 113 insertions(+), 1 deletion(-)
> create mode 100644 target/riscv/sbi_ecall_interface.h
>
> diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
> index 8da2648d1a..6d419ba02e 100644
> --- a/target/riscv/kvm.c
> +++ b/target/riscv/kvm.c
> @@ -38,6 +38,8 @@
> #include "qemu/log.h"
> #include "hw/loader.h"
> #include "kvm_riscv.h"
> +#include "sbi_ecall_interface.h"
> +#include "chardev/char-fe.h"
>
> static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type, uint64_t
> idx)
> {
> @@ -440,9 +442,47 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cs)
> return true;
> }
>
> +static int kvm_riscv_handle_sbi(struct kvm_run *run)
> +{
> +int ret = 0;
> +unsigned char ch;
> +switch (run->riscv_sbi.extension_id) {
> +case SBI_EXT_0_1_CONSOLE_PUTCHAR:
> +ch = run->riscv_sbi.args[0];
> +qemu_chr_fe_write(serial_hd(0)->be, , sizeof(ch));
> +break;
> +case SBI_EXT_0_1_CONSOLE_GETCHAR:
> +ret = qemu_chr_fe_read_all(serial_hd(0)->be, , sizeof(ch));
> +if (ret == sizeof(ch)) {
> +run->riscv_sbi.args[0] = ch;
> +} else {
> +run->riscv_sbi.args[0] = -1;
> +}
> +break;
Shouldn't this code use the Semihosting Console API from
"semihosting/console.h" instead?
Re: [PATCH v2 1/2] tests/acceptance: introduce new check-avocado tartget
On 11/8/21 10:24, Daniel P. Berrangé wrote: > On Mon, Nov 08, 2021 at 08:59:51AM +0100, Thomas Huth wrote: >> On 05/11/2021 16.53, Willian Rampazzo wrote: >>> This introduces a new `make` target, `check-avocado`, and adds a >>> deprecation message about the `check-acceptance` target. This is >>> a preparation for renaming the `tests/acceptance` folder to >>> `tests/avocado`. >>> >>> The plan is to remove the call to the `check-avocado` target one >>> or two months after the release and leave the warning to force >>> people to move to the new `check-avocado` target. >>> >>> Later, the `check-acceptance` target can be removed. The intent >>> is to avoid a direct impact during the current soft freeze. >>> >>> Suggested-by: Philippe Mathieu-Daudé >>> Signed-off-by: Willian Rampazzo >>> --- >>> docs/about/deprecated.rst | 13 + >>> tests/Makefile.include| 17 - >>> 2 files changed, 25 insertions(+), 5 deletions(-) >>> >>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst >>> index 56f9ad15ab..7bf8da8325 100644 >>> --- a/docs/about/deprecated.rst >>> +++ b/docs/about/deprecated.rst >>> @@ -410,3 +410,16 @@ nanoMIPS ISA >>> The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain. >>> As it is hard to generate binaries for it, declare it deprecated. >>> + >>> +Testing >>> +--- >>> + >>> +Renaming of the acceptance folder to avocado >>> + >>> + >>> +The ``tests/acceptance`` folder was never used to store acceptance tests >>> +in terms of software engineering. This naming can confuse developers >>> +adding tests using the Avocado Framework to this folder. The folder >>> +name change to ``tests/avocado`` also changed the ``make`` target from >>> +``check-acceptance`` to ``check-avocado``. In this case, the use of the >>> +``check-acceptance`` target is deprecated. >> >> Not sure whether we need to document this in deprecated.rst, too, since >> we're normally only listing the things here that affect the users of the >> qemu binaries, not the people who want to recompile and run the tests... >> OTOH, I don't mind too much either if we list it here... Anybody else got an >> opinion on this? > > Deprecations are only things for user facing changes in the apps. OK. > For build system changes we don't bother with any deprecation cycle. > Just make the change immediately and document it in the release notes. Understood. Willian, do you mind updating the release notes? https://wiki.qemu.org/ChangeLog/6.2#Testing_and_CI
Re: [PATCH v2 1/2] tests/acceptance: introduce new check-avocado tartget
On 11/8/21 08:59, Thomas Huth wrote: > On 05/11/2021 16.53, Willian Rampazzo wrote: >> This introduces a new `make` target, `check-avocado`, and adds a >> deprecation message about the `check-acceptance` target. This is >> a preparation for renaming the `tests/acceptance` folder to >> `tests/avocado`. >> >> The plan is to remove the call to the `check-avocado` target one >> or two months after the release and leave the warning to force >> people to move to the new `check-avocado` target. >> >> Later, the `check-acceptance` target can be removed. The intent >> is to avoid a direct impact during the current soft freeze. >> >> Suggested-by: Philippe Mathieu-Daudé >> Signed-off-by: Willian Rampazzo >> --- >> docs/about/deprecated.rst | 13 + >> tests/Makefile.include | 17 - >> 2 files changed, 25 insertions(+), 5 deletions(-) >> >> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst >> index 56f9ad15ab..7bf8da8325 100644 >> --- a/docs/about/deprecated.rst >> +++ b/docs/about/deprecated.rst >> @@ -410,3 +410,16 @@ nanoMIPS ISA >> The ``nanoMIPS`` ISA has never been upstreamed to any compiler >> toolchain. >> As it is hard to generate binaries for it, declare it deprecated. >> + >> +Testing >> +--- >> + >> +Renaming of the acceptance folder to avocado >> + >> + >> +The ``tests/acceptance`` folder was never used to store acceptance tests >> +in terms of software engineering. This naming can confuse developers >> +adding tests using the Avocado Framework to this folder. The folder >> +name change to ``tests/avocado`` also changed the ``make`` target from >> +``check-acceptance`` to ``check-avocado``. In this case, the use of the >> +``check-acceptance`` target is deprecated. > > Not sure whether we need to document this in deprecated.rst, too, since > we're normally only listing the things here that affect the users of the > qemu binaries, not the people who want to recompile and run the tests... > OTOH, I don't mind too much either if we list it here... Anybody else > got an opinion on this? Hmm OK my bad, I asked Willian to add that without noticing this file is for "only things that affect the users". Willian, if you agree with Thomas, I can remove this change from your patch.
Re: [PATCH v2 0/2] tests/acceptance: rename tests acceptance to tests avocado
On 11/5/21 16:53, Willian Rampazzo wrote: > In the discussion about renaming the `tests/acceptance` [1], the > conclusion was that the folders inside `tests` are related to the > framework running the tests and not directly related to the type of > the tests. > > This changes the folder to `tests/avocado` and adjusts the MAKEFILE, the > CI related files and the documentation. > > [1] https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg06553.html > > GitLab pipeline with new naming: > https://gitlab.com/willianrampazzo/qemu/-/pipelines/403056475 > > Changes from v1: > - Split changes on Makefile leaving `check-acceptance` available and >adding a deprecate warning message when it is used. >(Suggested-by: Philippe Mathieu-Daudé) > - Remove unrelated changes. > > Signed-off-by: Willian Rampazzo > > Willian Rampazzo (2): > tests/acceptance: introduce new check-avocado tartget > tests/acceptance: rename tests acceptance to tests avocado Thanks, series queued.
Re: [PATCH v2 1/2] tests/acceptance: introduce new check-avocado tartget
On 11/5/21 16:53, Willian Rampazzo wrote: > This introduces a new `make` target, `check-avocado`, and adds a > deprecation message about the `check-acceptance` target. This is > a preparation for renaming the `tests/acceptance` folder to > `tests/avocado`. > > The plan is to remove the call to the `check-avocado` target one > or two months after the release and leave the warning to force > people to move to the new `check-avocado` target. > > Later, the `check-acceptance` target can be removed. The intent > is to avoid a direct impact during the current soft freeze. > > Suggested-by: Philippe Mathieu-Daudé > Signed-off-by: Willian Rampazzo > --- > docs/about/deprecated.rst | 13 + > tests/Makefile.include| 17 - > 2 files changed, 25 insertions(+), 5 deletions(-) Typo "target" in subject (no need to respin). Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu-Daudé
[PATCH] docs/about/deprecated: Remove empty 'related binaries' section
Commit 497a30dbb06 ("qemu-img: Require -F with -b backing image")
removed the content of the "Related binaries" section but forgot
to remove the section title. Since it is now empty, remove it too.
Signed-off-by: Philippe Mathieu-Daudé
---
docs/about/deprecated.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 56f9ad15ab5..5e514fb443d 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -370,9 +370,6 @@ The ``I7200`` guest CPU relies on the nanoMIPS ISA, which
is deprecated
(the ISA has never been upstreamed to a compiler toolchain). Therefore
this CPU is also deprecated.
-Related binaries
-
-
Backwards compatibility
---
--
2.31.1
Re: [PATCH v2 4/4] MAINTAINERS: Agree to maintain nanoMIPS TCG frontend
On 10/27/21 06:14, 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é
> ---
> v2: un-deprecate (danpb)
> ---
> docs/about/deprecated.rst | 23 ---
> MAINTAINERS | 6 +-
> 2 files changed, 1 insertion(+), 28 deletions(-)
I tried to add nanoMIPS testing using the Codescape toolchain
suggested by MediaTek [*], unfortunately QEMU user-mode is not
able to run any nanoMIPS binary. Various pieces are missing.
In particular, mainstream QEMU doesn't implement the p32 ABI,
ELF binaries are handled as o32 and the syscall table doesn't
match anything correct.
I am sorry but I can not proceed further with this patch.
[*]
https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases/tag/nanoMIPS-2021.02-01
Re: [PATCH v2 8/9] qapi: Factor out compat_policy_input_ok()
On 10/29/21 18:55, Markus Armbruster wrote:
> Markus Armbruster writes:
>
>> The code to check policy for handling deprecated input is triplicated.
>> Factor it out into compat_policy_input_ok() before I mess with it in
>> the next commit.
>>
>> Signed-off-by: Markus Armbruster
>> Reviewed-by: Philippe Mathieu-Daudé
>> ---
>> include/qapi/compat-policy.h | 7 +
>> qapi/qapi-visit-core.c | 18 +
>> qapi/qmp-dispatch.c | 51 +++-
>> qapi/qobject-input-visitor.c | 19 +++---
>> 4 files changed, 55 insertions(+), 40 deletions(-)
>> +bool compat_policy_input_ok(unsigned special_features,
>> +const CompatPolicy *policy,
>> +ErrorClass error_class,
>> +const char *kind, const char *name,
>> +Error **errp)
>> +{
>> +if ((special_features & 1u << QAPI_DEPRECATED)
>> +&& !compat_policy_input_ok1("Deprecated",
>> +policy->deprecated_input,
>> +error_class, kind, name, errp)) {
>> +return false;
>> +}
>> +return true;
>> +}
>> +
>> Visitor *qobject_input_visitor_new_qmp(QObject *obj)
>> {
>> Visitor *v = qobject_input_visitor_new(obj);
>
> I'm moving the new functions along with @compat_policy to qapi-util.c,
> so the QAPI visitors survive linking without qmp-dispatch.o.
OK. I am waiting your series to get in before respining my QAPI
sysemu/user series which will re-scramble meson.build here.
Probably too late for this release. Not super important, it just
saves energy avoiding generating / building unused files.
Re: [PATCH v2 5/9] qapi: Generalize struct member policy checking
On 10/29/21 17:34, Markus Armbruster wrote:
> Eric Blake writes:
>
>> On Thu, Oct 28, 2021 at 12:25:16PM +0200, Markus Armbruster wrote:
>>> The generated visitor functions call visit_deprecated_accept() and
>>> visit_deprecated() when visiting a struct member with special feature
>>> flag 'deprecated'. This makes the feature flag visible to the actual
>>> visitors. I want to make feature flag 'unstable' visible there as
>>> well, so I can add policy for it.
>>>
>>> To let me make it visible, replace these functions by
>>> visit_policy_reject() and visit_policy_skip(), which take the member's
>>> special features as an argument. Note that the new functions have the
>>> opposite sense, i.e. the return value flips.
>>>
>>> Signed-off-by: Markus Armbruster
>>> ---
>>
>>> +++ b/qapi/qapi-forward-visitor.c
>>> @@ -246,25 +246,27 @@ static void forward_field_optional(Visitor *v, const
>>> char *name, bool *present)
>>> visit_optional(ffv->target, name, present);
>>> }
>>>
>>> -static bool forward_field_deprecated_accept(Visitor *v, const char *name,
>>> -Error **errp)
>>> +static bool forward_field_policy_reject(Visitor *v, const char *name,
>>> +unsigned special_features,
>>> +Error **errp)
>>> {
>>> ForwardFieldVisitor *ffv = to_ffv(v);
>>>
>>> if (!forward_field_translate_name(ffv, , errp)) {
>>> return false;
>>
>> Should this return value be flipped?
>>
>>> }
>>> -return visit_deprecated_accept(ffv->target, name, errp);
>>> +return visit_policy_reject(ffv->target, name, special_features, errp);
>>> }
>>>
>>> -static bool forward_field_deprecated(Visitor *v, const char *name)
>>> +static bool forward_field_policy_skip(Visitor *v, const char *name,
>>> + unsigned special_features)
>>> {
>>> ForwardFieldVisitor *ffv = to_ffv(v);
>>>
>>> if (!forward_field_translate_name(ffv, , NULL)) {
>>> return false;
>>
>> and here too?
>
> Good catch!
Ouch. I admit this patch logic is hard to review, but couldn't come
with a nice way to split it further.
> These functions are called indirectly like
>
> if (visit_policy_reject(v, "values", 1u << QAPI_DEPRECATED, errp)) {
> return false;
> }
> if (!visit_policy_skip(v, "values", 1u << QAPI_DEPRECATED)) {
> if (!visit_type_strList(v, "values", >values, errp)) {
> return false;
> }
> }
>
> visit_policy_reject() must return true when it sets an error, or else we
> call visit_policy_skip() with @errp pointing to non-null.
>
> Same argument for visit_policy_skip().
>
>>> }
>>> -return visit_deprecated(ffv->target, name);
>>> +return visit_policy_skip(ffv->target, name, special_features);
>>> }
>>>
>>
>> Otherwise, the rest of the logic changes for flipped sense look right.
>
Re: [PATCH v2 5/9] qapi: Generalize struct member policy checking
On 10/29/21 16:01, Markus Armbruster wrote: > Philippe Mathieu-Daudé writes: > >> On 10/28/21 12:25, Markus Armbruster wrote: >>> The generated visitor functions call visit_deprecated_accept() and >>> visit_deprecated() when visiting a struct member with special feature >>> flag 'deprecated'. This makes the feature flag visible to the actual >>> visitors. I want to make feature flag 'unstable' visible there as >>> well, so I can add policy for it. >>> >>> To let me make it visible, replace these functions by >>> visit_policy_reject() and visit_policy_skip(), which take the member's >>> special features as an argument. Note that the new functions have the >>> opposite sense, i.e. the return value flips. >>> >>> Signed-off-by: Markus Armbruster >>> --- >>> include/qapi/visitor-impl.h | 6 -- >>> include/qapi/visitor.h| 17 + >>> qapi/qapi-forward-visitor.c | 16 +--- >>> qapi/qapi-visit-core.c| 22 -- >>> qapi/qobject-input-visitor.c | 15 ++- >>> qapi/qobject-output-visitor.c | 9 ++--- >>> qapi/trace-events | 4 ++-- >>> scripts/qapi/visit.py | 14 +++--- >>> 8 files changed, 63 insertions(+), 40 deletions(-) >>> case COMPAT_POLICY_INPUT_CRASH: >> >> Clearer as: >> >> abort(); >>default: >>g_assert_not_reached(); > > Maybe, but making it so has nothing to do with this patch. It could > perhaps be done in PATCH 8, or in a followup patch. > >> Otherwise, >> Reviewed-by: Philippe Mathieu-Daudé > > Okay to tack your R-by to the unmodified patch? Sure.
Re: [PATCH v2 6/9] qapi: Generalize command policy checking
On 10/29/21 17:28, Eric Blake wrote:
> On Thu, Oct 28, 2021 at 12:25:17PM +0200, Markus Armbruster wrote:
>> The code to check command policy can see special feature flag
>> 'deprecated' as command flag QCO_DEPRECATED. I want to make feature
>> flag 'unstable' visible there as well, so I can add policy for it.
>>
>> To let me make it visible, add member @special_features (a bitset of
>> QapiSpecialFeature) to QmpCommand, and adjust the generator to pass it
>> through qmp_register_command(). Then replace "QCO_DEPRECATED in
>> @flags" by QAPI_DEPRECATED in @special_features", and drop
>> QCO_DEPRECATED.
>>
>> Signed-off-by: Markus Armbruster
>> Reviewed-by: Philippe Mathieu-Daudé
>> Acked-by: John Snow
>> ---
>
>> +++ b/qapi/qmp-dispatch.c
>> @@ -176,7 +176,7 @@ QDict *qmp_dispatch(const QmpCommandList *cmds, QObject
>> *request,
>>"The command %s has not been found", command);
>> goto out;
>> }
>> -if (cmd->options & QCO_DEPRECATED) {
>> +if (cmd->special_features & 1u << QAPI_DEPRECATED) {
>
> I admit having to check the C operator precedence table when reading
This doesn't seem a good use of (y)our time. Using a pair of parenthesis
is simpler.
I expect in a not far future that compilers emit a warning for this.
> this (<< is higher than &); if writing it myself, I would probably
> have used explicit () to avoid reviewer confusion, but what you have
> is correct. (After grepping for ' & 1.*<<' and ' & (1.*<<', it looks
> like authors using explicit precedence happens more often, but that
> there are other instances in the code base relying on implicit
> precedence.)
$ git grep -E ' & [0-9a-zA-Z_]+ <<'
hw/dma/pl330.c:997:if (~ch->parent->inten & ch->parent->ev_status &
1 << ev_id) {
hw/dma/xlnx-zynq-devcfg.c:198:if (s->regs[R_LOCK] & 1 << i) {
hw/intc/grlib_irqmp.c:144:if (s->broadcast & 1 << irq) {
hw/net/fsl_etsec/rings.c:491:if (etsec->regs[RSTAT].value & 1 << (23
- ring_nbr)) {
hw/net/virtio-net.c:748:(n->host_features & 1ULL <<
VIRTIO_NET_F_MTU)) {
hw/pci-host/mv64361.c:812:if ((ch & 0xff << i) && !(val
& 0xff << i)) {
hw/pci-host/mv64361.c:858:if (s->gpp_int_level && !(val & 0xff
<< b)) {
hw/ssi/xilinx_spi.c:123:qemu_set_irq(s->cs_lines[i],
!(~s->regs[R_SPISSR] & 1 << i));
hw/ssi/xilinx_spips.c:441:r[idx[!d]] |= x[idx[d]] & 1 <<
bit[d] ? 1 << bit[!d] : 0;
target/s390x/cpu_features.c:56:if (init[i] & 1ULL << j) {
tests/qtest/bios-tables-test.c:209:if (!(val & 1UL << 20 /*
HW_REDUCED_ACPI */)) {
Not that many.
Re: [PATCH v2 5/9] qapi: Generalize struct member policy checking
On 10/28/21 12:25, Markus Armbruster wrote:
> The generated visitor functions call visit_deprecated_accept() and
> visit_deprecated() when visiting a struct member with special feature
> flag 'deprecated'. This makes the feature flag visible to the actual
> visitors. I want to make feature flag 'unstable' visible there as
> well, so I can add policy for it.
>
> To let me make it visible, replace these functions by
> visit_policy_reject() and visit_policy_skip(), which take the member's
> special features as an argument. Note that the new functions have the
> opposite sense, i.e. the return value flips.
>
> Signed-off-by: Markus Armbruster
> ---
> include/qapi/visitor-impl.h | 6 --
> include/qapi/visitor.h| 17 +
> qapi/qapi-forward-visitor.c | 16 +---
> qapi/qapi-visit-core.c| 22 --
> qapi/qobject-input-visitor.c | 15 ++-
> qapi/qobject-output-visitor.c | 9 ++---
> qapi/trace-events | 4 ++--
> scripts/qapi/visit.py | 14 +++---
> 8 files changed, 63 insertions(+), 40 deletions(-)
> -static bool qobject_input_deprecated_accept(Visitor *v, const char *name,
> -Error **errp)
> +static bool qobject_input_policy_reject(Visitor *v, const char *name,
> +unsigned special_features,
> +Error **errp)
> {
> +if (!(special_features & 1u << QAPI_DEPRECATED)) {
> +return false;
> +}
> +
> switch (v->compat_policy.deprecated_input) {
> case COMPAT_POLICY_INPUT_ACCEPT:
> -return true;
> +return false;
> case COMPAT_POLICY_INPUT_REJECT:
> error_setg(errp, "Deprecated parameter '%s' disabled by policy",
> name);
> -return false;
> +return true;
> case COMPAT_POLICY_INPUT_CRASH:
Clearer as:
abort();
default:
g_assert_not_reached();
Otherwise,
Reviewed-by: Philippe Mathieu-Daudé
> default:
> abort();
Re: [PATCH v2 4/9] qapi: Tools for sets of special feature flags in generated code
On 10/28/21 12:25, Markus Armbruster wrote: > New enum QapiSpecialFeature enumerates the special feature flags. > > New helper gen_special_features() returns code to represent a > collection of special feature flags as a bitset. > > The next few commits will put them to use. > > Signed-off-by: Markus Armbruster > Reviewed-by: John Snow > --- > include/qapi/util.h| 4 > scripts/qapi/gen.py| 8 > scripts/qapi/schema.py | 3 +++ > 3 files changed, 15 insertions(+) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v2 7/9] qapi: Generalize enum member policy checking
On 10/28/21 12:25, Markus Armbruster wrote: > The code to check enumeration value policy can see special feature > flag 'deprecated' in QEnumLookup member flags[value]. I want to make > feature flag 'unstable' visible there as well, so I can add policy for > it. > > Instead of extending flags[], replace it by @special_features (a > bitset of QapiSpecialFeature), because that's how special features get > passed around elsewhere. > > Signed-off-by: Markus Armbruster > Acked-by: John Snow > --- > include/qapi/util.h| 5 + > qapi/qapi-visit-core.c | 3 ++- > scripts/qapi/types.py | 22 -- > 3 files changed, 15 insertions(+), 15 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
[PATCH v2 4/4] MAINTAINERS: Agree to maintain nanoMIPS TCG frontend
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é
---
v2: un-deprecate (danpb)
---
docs/about/deprecated.rst | 23 ---
MAINTAINERS | 6 +-
2 files changed, 1 insertion(+), 28 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0bed6ecb1da..5f4e4eeb2b0 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -246,13 +246,6 @@ System emulator CPUS
``Icelake-Client`` CPU Models are deprecated. Use ``Icelake-Server`` CPU
Models instead.
-MIPS ``I7200`` CPU Model (since 5.2)
-
-
-The ``I7200`` guest CPU relies on the nanoMIPS ISA, which is deprecated
-(the ISA has never been upstreamed to a compiler toolchain). Therefore
-this CPU is also deprecated.
-
QEMU API (QAPI) events
--
@@ -342,13 +335,6 @@ The ``ppc64abi32`` architecture has a number of issues
which regularly
trip up our CI testing and is suspected to be quite broken. For that
reason the maintainers strongly suspect no one actually uses it.
-MIPS ``I7200`` CPU (since 5.2)
-''
-
-The ``I7200`` guest CPU relies on the nanoMIPS ISA, which is deprecated
-(the ISA has never been upstreamed to a compiler toolchain). Therefore
-this CPU is also deprecated.
-
Related binaries
@@ -380,12 +366,3 @@ point to a version that doesn't break runnability
guarantees
versions, aliases will point to newer CPU model versions
depending on the machine type, so management software must
resolve CPU model aliases before starting a virtual machine.
-
-Guest Emulator ISAs
-
-nanoMIPS ISA
-
-
-The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain.
-As it is hard to generate binaries for it, declare it deprecated.
diff --git a/MAINTAINERS b/MAINTAINERS
index efcfa57cd6a..71b198139c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -237,14 +237,10 @@ R: Aleksandar Rikalo
S: Odd Fixes
F: target/mips/
F: disas/mips.c
+X: disas/nanomips.*
F: docs/system/cpu-models-mips.rst.inc
F: tests/tcg/mips/
-MIPS TCG CPUs (nanoMIPS ISA)
-S: Orphan
-F: disas/nanomips.*
-F: target/mips/tcg/*nanomips*
-
NiosII TCG CPUs
M: Chris Wulff
M: Marek Vasut
--
2.31.1
[PATCH v2 1/4] MAINTAINERS: Add MIPS general architecture support entry
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(-) diff --git a/MAINTAINERS b/MAINTAINERS index 894dc431052..5369fe2a129 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -109,6 +109,12 @@ K: ^Subject:.*(?i)s390x? T: git https://gitlab.com/cohuck/qemu.git s390-next L: qemu-s3...@nongnu.org +MIPS general architecture support +M: Philippe Mathieu-Daudé +R: Jiaxun Yang +S: Odd Fixes +K: ^Subject:.*(?i)mips + Guest CPU cores (TCG) - Overall TCG CPUs @@ -242,7 +248,6 @@ F: include/hw/mips/ F: include/hw/misc/mips_* F: include/hw/timer/mips_gictimer.h F: tests/tcg/mips/ -K: ^Subject:.*(?i)mips MIPS TCG CPUs (nanoMIPS ISA) S: Orphan -- 2.31.1
[PATCH v2 2/4] MAINTAINERS: Add entries to cover MIPS CPS / GIC hardware
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(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5369fe2a129..62a37aa94b5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -239,14 +239,8 @@ F: target/mips/ F: configs/devices/mips*/* F: disas/mips.c F: docs/system/cpu-models-mips.rst.inc -F: hw/intc/mips_gic.c F: hw/mips/ -F: hw/misc/mips_* -F: hw/timer/mips_gictimer.c -F: include/hw/intc/mips_gic.h F: include/hw/mips/ -F: include/hw/misc/mips_* -F: include/hw/timer/mips_gictimer.h F: tests/tcg/mips/ MIPS TCG CPUs (nanoMIPS ISA) @@ -2270,6 +2264,20 @@ S: Odd Fixes F: hw/intc/openpic.c F: include/hw/ppc/openpic.h +MIPS CPS +M: Philippe Mathieu-Daudé +S: Odd Fixes +F: hw/misc/mips_* +F: include/hw/misc/mips_* + +MIPS GIC +M: Philippe Mathieu-Daudé +S: Odd Fixes +F: hw/intc/mips_gic.c +F: hw/timer/mips_gictimer.c +F: include/hw/intc/mips_gic.h +F: include/hw/timer/mips_gictimer.h + Subsystems -- Overall Audio backends -- 2.31.1
[PATCH v2 0/4] MAINTAINERS: Sanitize 'MIPS TCG CPUs' section
Move various files unrelated to MIPS TCG frontend into new sections. Since v1: - Do not add Paul without his consent - un-deprecate nanoMIPS Philippe Mathieu-Daudé (4): MAINTAINERS: Add MIPS general architecture support entry MAINTAINERS: Add entries to cover MIPS CPS / GIC hardware MAINTAINERS: Split MIPS TCG frontend vs MIPS machines/hardware MAINTAINERS: Agree to maintain nanoMIPS TCG frontend docs/about/deprecated.rst | 23 - MAINTAINERS | 43 +-- 2 files changed, 28 insertions(+), 38 deletions(-) -- 2.31.1
[PATCH v2 3/4] MAINTAINERS: Split MIPS TCG frontend vs MIPS machines/hardware
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(-) diff --git a/MAINTAINERS b/MAINTAINERS index 62a37aa94b5..efcfa57cd6a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -236,11 +236,8 @@ R: Jiaxun Yang R: Aleksandar Rikalo S: Odd Fixes F: target/mips/ -F: configs/devices/mips*/* F: disas/mips.c F: docs/system/cpu-models-mips.rst.inc -F: hw/mips/ -F: include/hw/mips/ F: tests/tcg/mips/ MIPS TCG CPUs (nanoMIPS ISA) @@ -1169,6 +1166,13 @@ F: hw/microblaze/petalogix_ml605_mmu.c MIPS Machines - +Overall MIPS Machines +M: Philippe Mathieu-Daudé +S: Odd Fixes +F: configs/devices/mips*/* +F: hw/mips/ +F: include/hw/mips/ + Jazz M: Hervé Poussineau R: Aleksandar Rikalo -- 2.31.1
Re: [PATCH 5/9] qapi: Generalize struct member policy checking
On 10/25/21 07:25, Markus Armbruster wrote:
> The generated visitor functions call visit_deprecated_accept() and
> visit_deprecated() when visiting a struct member with special feature
> flag 'deprecated'. This makes the feature flag visible to the actual
> visitors. I want to make feature flag 'unstable' visible there as
> well, so I can add policy for it.
>
> To let me make it visible, replace these functions by
> visit_policy_reject() and visit_policy_skip(), which take the member's
> special features as an argument. Note that the new functions have the
> opposite sense, i.e. the return value flips.
>
> Signed-off-by: Markus Armbruster
> ---
> include/qapi/visitor-impl.h | 6 --
> include/qapi/visitor.h| 17 +
> qapi/qapi-forward-visitor.c | 16 +---
> qapi/qapi-visit-core.c| 22 --
> qapi/qobject-input-visitor.c | 15 ++-
> qapi/qobject-output-visitor.c | 9 ++---
> qapi/trace-events | 4 ++--
> scripts/qapi/visit.py | 14 +++---
> 8 files changed, 63 insertions(+), 40 deletions(-)
> diff --git a/qapi/qobject-input-visitor.c b/qapi/qobject-input-visitor.c
> index 71b24a4429..fda485614b 100644
> --- a/qapi/qobject-input-visitor.c
> +++ b/qapi/qobject-input-visitor.c
> @@ -662,16 +662,21 @@ static void qobject_input_optional(Visitor *v, const
> char *name, bool *present)
> *present = true;
> }
>
> -static bool qobject_input_deprecated_accept(Visitor *v, const char *name,
> -Error **errp)
> +static bool qobject_input_policy_reject(Visitor *v, const char *name,
> +unsigned special_features,
> +Error **errp)
> {
> +if (!(special_features && 1u << QAPI_DEPRECATED)) {
Unreachable =) Proof than extract() is safer :P
> +return false;
> +}
Re: [PATCH 8/9] qapi: Factor out compat_policy_input_ok()
On 10/26/21 11:46, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> On 10/25/21 07:25, Markus Armbruster wrote:
>>> The code to check policy for handling deprecated input is triplicated.
>>> Factor it out into compat_policy_input_ok() before I mess with it in
>>> the next commit.
>>>
>>> Signed-off-by: Markus Armbruster
>>> ---
>>> include/qapi/compat-policy.h | 7 +
>>> qapi/qapi-visit-core.c | 18 +
>>> qapi/qmp-dispatch.c | 51 +++-
>>> qapi/qobject-input-visitor.c | 19 +++---
>>> 4 files changed, 55 insertions(+), 40 deletions(-)
>>
>>> diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
>>> index 8cca18c891..e29ade134c 100644
>>> --- a/qapi/qmp-dispatch.c
>>> +++ b/qapi/qmp-dispatch.c
>>> @@ -28,6 +28,40 @@
>>>
>>> CompatPolicy compat_policy;
>>>
>>> +static bool compat_policy_input_ok1(const char *adjective,
>>> +CompatPolicyInput policy,
>>> +ErrorClass error_class,
>>> +const char *kind, const char *name,
>>> +Error **errp)
>>> +{
>>> +switch (policy) {
>>> +case COMPAT_POLICY_INPUT_ACCEPT:
>>> +return true;
>>> +case COMPAT_POLICY_INPUT_REJECT:
>>> +error_set(errp, error_class, "%s %s %s disabled by policy",
>>> + adjective, kind, name);
>>> +return false;
>>> +case COMPAT_POLICY_INPUT_CRASH:
>>> +default:
>>> +abort();
>>
>> g_assert_not_reached() provides a nicer user experience.
>
> I find it hard to care for making the experience of a crash that should
> never ever happen nicer :)
Well COMPAT_POLICY_INPUT_CRASH can happen... What about:
case COMPAT_POLICY_INPUT_CRASH:
error_printf("%s %s %s disabled by policy",
adjective, kind, name);
abort();
default:
g_assert_not_reached();
Re: [PATCH 1/9] qapi: New special feature flag "unstable"
On 10/25/21 14:05, Kashyap Chamarthy wrote: > On Mon, Oct 25, 2021 at 07:25:24AM +0200, Markus Armbruster wrote: >> By convention, names starting with "x-" are experimental. The parts >> of external interfaces so named may be withdrawn or changed >> incompatibly in future releases. >> >> Drawback: promoting something from experimental to stable involves a >> name change. Client code needs to be updated. >> >> Moreover, the convention is not universally observed: >> >> * QOM type "input-barrier" has properties "x-origin", "y-origin". >> Looks accidental, but it's ABI since 4.2. >> >> * QOM types "memory-backend-file", "memory-backend-memfd", >> "memory-backend-ram", and "memory-backend-epc" have a property >> "x-use-canonical-path-for-ramblock-id" that is documented to be >> stable despite its name. > > Looks like there's another stable property with an "x-" prefix: > "x-remote-object", part of QOM type @RemoteObjectProperties. IIRC "x-remote-object" and RemoteObjectProperties are not stable.
Re: [PATCH 8/9] qapi: Factor out compat_policy_input_ok()
On 10/25/21 07:25, Markus Armbruster wrote:
> The code to check policy for handling deprecated input is triplicated.
> Factor it out into compat_policy_input_ok() before I mess with it in
> the next commit.
>
> Signed-off-by: Markus Armbruster
> ---
> include/qapi/compat-policy.h | 7 +
> qapi/qapi-visit-core.c | 18 +
> qapi/qmp-dispatch.c | 51 +++-
> qapi/qobject-input-visitor.c | 19 +++---
> 4 files changed, 55 insertions(+), 40 deletions(-)
> diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
> index 8cca18c891..e29ade134c 100644
> --- a/qapi/qmp-dispatch.c
> +++ b/qapi/qmp-dispatch.c
> @@ -28,6 +28,40 @@
>
> CompatPolicy compat_policy;
>
> +static bool compat_policy_input_ok1(const char *adjective,
> +CompatPolicyInput policy,
> +ErrorClass error_class,
> +const char *kind, const char *name,
> +Error **errp)
> +{
> +switch (policy) {
> +case COMPAT_POLICY_INPUT_ACCEPT:
> +return true;
> +case COMPAT_POLICY_INPUT_REJECT:
> +error_set(errp, error_class, "%s %s %s disabled by policy",
> + adjective, kind, name);
> +return false;
> +case COMPAT_POLICY_INPUT_CRASH:
> +default:
> +abort();
g_assert_not_reached() provides a nicer user experience.
> +}
> +}
> +
> +bool compat_policy_input_ok(unsigned special_features,
> +const CompatPolicy *policy,
> +ErrorClass error_class,
> +const char *kind, const char *name,
> +Error **errp)
> +{
> +if ((special_features & 1u << QAPI_DEPRECATED)
Matter of taste, I find code using extract() easier to review:
extract64(special_features, QAPI_DEPRECATED, 1)
> +&& !compat_policy_input_ok1("Deprecated",
> + policy->deprecated_input,
> +error_class, kind, name, errp)) {
> +return false;
> +}
> +return true;
> +}
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 6/9] qapi: Generalize command policy checking
On 10/25/21 07:25, Markus Armbruster wrote: > The code to check command policy can see special feature flag > 'deprecated' as command flag QCO_DEPRECATED. I want to make feature > flag 'unstable' visible there as well, so I can add policy for it. > > To let me make it visible, add member @special_features (a bitset of > QapiSpecialFeature) to QmpCommand, and adjust the generator to pass it > through qmp_register_command(). Then replace "QCO_DEPRECATED in > @flags" by QAPI_DEPRECATED in @special_features", and drop > QCO_DEPRECATED. > > Signed-off-by: Markus Armbruster > --- > include/qapi/qmp/dispatch.h | 5 +++-- > monitor/misc.c | 6 -- > qapi/qmp-dispatch.c | 2 +- > qapi/qmp-registry.c | 4 +++- > storage-daemon/qemu-storage-daemon.c | 3 ++- > scripts/qapi/commands.py | 9 - > 6 files changed, 17 insertions(+), 12 deletions(-) > > diff --git a/include/qapi/qmp/dispatch.h b/include/qapi/qmp/dispatch.h > index 0ce88200b9..1e4240fd0d 100644 > --- a/include/qapi/qmp/dispatch.h > +++ b/include/qapi/qmp/dispatch.h > @@ -25,7 +25,6 @@ typedef enum QmpCommandOptions > QCO_ALLOW_OOB = (1U << 1), > QCO_ALLOW_PRECONFIG = (1U << 2), > QCO_COROUTINE = (1U << 3), > -QCO_DEPRECATED= (1U << 4), > } QmpCommandOptions; > > typedef struct QmpCommand > @@ -34,6 +33,7 @@ typedef struct QmpCommand > /* Runs in coroutine context if QCO_COROUTINE is set */ > QmpCommandFunc *fn; > QmpCommandOptions options; > +unsigned special_features; > QTAILQ_ENTRY(QmpCommand) node; > bool enabled; > const char *disable_reason; > @@ -42,7 +42,8 @@ typedef struct QmpCommand > typedef QTAILQ_HEAD(QmpCommandList, QmpCommand) QmpCommandList; > > void qmp_register_command(QmpCommandList *cmds, const char *name, > - QmpCommandFunc *fn, QmpCommandOptions options); > + QmpCommandFunc *fn, QmpCommandOptions options, > + unsigned special_features); What about: typedef unsigned QapiFeatureMask; ? Otherwise: Reviewed-by: Philippe Mathieu-Daudé
[PATCH v3 1/2] tests: Remove uses of deprecated raspi2/raspi3 machine names
Commit 155e1c82ed0 deprecated the raspi2/raspi3 machine names.
Use the recommended new names: raspi2b and raspi3b.
Signed-off-by: Philippe Mathieu-Daudé
---
docs/devel/qgraph.rst | 38 -
tests/qtest/libqos/qgraph.h | 6 ++--
tests/qtest/libqos/qgraph_internal.h| 2 +-
tests/qtest/boot-serial-test.c | 2 +-
tests/qtest/libqos/arm-raspi2-machine.c | 8 +++---
tests/unit/test-qgraph.c| 2 +-
tests/acceptance/boot_linux_console.py | 6 ++--
7 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/docs/devel/qgraph.rst b/docs/devel/qgraph.rst
index 39e293687e6..c2882c3a334 100644
--- a/docs/devel/qgraph.rst
+++ b/docs/devel/qgraph.rst
@@ -41,7 +41,7 @@ Nodes
A node can be of four types:
-- **QNODE_MACHINE**: for example ``arm/raspi2``
+- **QNODE_MACHINE**: for example ``arm/raspi2b``
- **QNODE_DRIVER**:for example ``generic-sdhci``
- **QNODE_INTERFACE**: for example ``sdhci`` (interface for all ``-sdhci``
drivers).
@@ -119,12 +119,12 @@ It is possible to troubleshoot unavailable tests by
running::
# |-> dest='i440FX-pcihost' type=0 (node=0x5591421117f0)
# src=''
# |-> dest='x86_64/pc' type=0 (node=0x559142111600)
- # |-> dest='arm/raspi2' type=0 (node=0x559142110740)
+ # |-> dest='arm/raspi2b' type=0 (node=0x559142110740)
...
# }
# ALL QGRAPH NODES: {
# name='virtio-net-tests/announce-self' type=3 cmd_line='(null)'
[available]
- # name='arm/raspi2' type=0 cmd_line='-M raspi2 ' [UNAVAILABLE]
+ # name='arm/raspi2b' type=0 cmd_line='-M raspi2b ' [UNAVAILABLE]
...
# }
@@ -135,8 +135,8 @@ qgraph path in the "ALL QGRAPH EDGES" output as follows: ''
-> 'x86_64/pc' ->
'virtio-net'. The root of the qgraph is '' and the depth first search begins
there.
-The ``arm/raspi`` machine node is listed as "UNAVAILABLE". Although it is
-reachable from the root via '' -> 'arm/raspi2' the node is unavailable because
+The ``arm/raspi2b`` machine node is listed as "UNAVAILABLE". Although it is
+reachable from the root via '' -> 'arm/raspi2b' the node is unavailable because
the QEMU binary did not list it when queried by the framework. This is expected
because we used the ``qemu-system-x86_64`` binary which does not support ARM
machine types.
@@ -158,7 +158,7 @@ Here we continue the ``sdhci`` use case, with the following
scenario:
- ``sdhci-test`` aims to test the ``read[q,w], writeq`` functions
offered by the ``sdhci`` drivers.
- The current ``sdhci`` device is supported by both ``x86_64/pc`` and ``ARM``
- (in this example we focus on the ``arm-raspi2``) machines.
+ (in this example we focus on the ``arm-raspi2b``) machines.
- QEMU offers 2 types of drivers: ``QSDHCI_MemoryMapped`` for ``ARM`` and
``QSDHCI_PCI`` for ``x86_64/pc``. Both implement the
``read[q,w], writeq`` functions.
@@ -180,11 +180,11 @@ In order to implement such scenario in qgraph, the test
developer needs to:
all the pci drivers available)
``sdhci-pci --consumes--> pci-bus``
-- Create an ``arm/raspi2`` machine node. This machine ``contains``
+- Create an ``arm/raspi2b`` machine node. This machine ``contains``
a ``generic-sdhci`` memory mapped ``sdhci`` driver node, representing
``QSDHCI_MemoryMapped``.
- ``arm/raspi2 --contains--> generic-sdhci``
+ ``arm/raspi2b --contains--> generic-sdhci``
- Create the ``sdhci`` interface node. This interface offers the
functions that are shared by all ``sdhci`` devices.
The interface is produced by ``sdhci-pci`` and ``generic-sdhci``,
@@ -199,7 +199,7 @@ In order to implement such scenario in qgraph, the test
developer needs to:
``sdhci-test --consumes--> sdhci``
-``arm-raspi2`` machine, simplified from
+``arm-raspi2b`` machine, simplified from
``tests/qtest/libqos/arm-raspi2-machine.c``::
#include "qgraph.h"
@@ -217,7 +217,7 @@ In order to implement such scenario in qgraph, the test
developer needs to:
return >alloc;
}
-fprintf(stderr, "%s not present in arm/raspi2\n", interface);
+fprintf(stderr, "%s not present in arm/raspi2b\n", interface);
g_assert_not_reached();
}
@@ -229,7 +229,7 @@ In order to implement such scenario in qgraph, the test
developer needs to:
return >sdhci.obj;
}
-fprintf(stderr, "%s not present in arm/raspi2\n", device);
+fprintf(stderr, "%s not present in arm/raspi2b\n", device);
g_assert_not_reached();
}
@@ -253,10 +253,10 @@ In order to implement such scenario in qgraph, the test
developer needs to:
static void raspi2_register_nodes(void)
{
-/* arm/raspi2 --contains--> generic-sdhci */
-qos_node_create_machine("arm/raspi2",
+/* arm/raspi2b --contains--> generic-sdhci */
+
[PATCH v3 0/2] hw/arm/raspi: Remove deprecated raspi2/raspi3 aliases
Since v2: - updated "Since 6.1" -> "Since 6.2" Peter reported CI failure [*] but I can't reproduce: https://gitlab.com/philmd/qemu/-/pipelines/360227279 Since v1: - renamed tests (Peter) [*] https://lore.kernel.org/qemu-devel/CAFEAcA8PLvMUEzyu=sn4bn4mu30w1aaju+t+i__5jnb0qmz...@mail.gmail.com/ Philippe Mathieu-Daudé (2): tests: Remove uses of deprecated raspi2/raspi3 machine names hw/arm/raspi: Remove deprecated raspi2/raspi3 aliases docs/about/deprecated.rst | 7 - docs/about/removed-features.rst | 7 + docs/devel/qgraph.rst | 38 - tests/qtest/libqos/qgraph.h | 6 ++-- tests/qtest/libqos/qgraph_internal.h| 2 +- hw/arm/raspi.c | 2 -- tests/qtest/boot-serial-test.c | 2 +- tests/qtest/libqos/arm-raspi2-machine.c | 8 +++--- tests/unit/test-qgraph.c| 2 +- tests/acceptance/boot_linux_console.py | 6 ++-- 10 files changed, 39 insertions(+), 41 deletions(-) -- 2.31.1
[PATCH v3 2/2] hw/arm/raspi: Remove deprecated raspi2/raspi3 aliases
Remove the raspi2/raspi3 machine aliases, deprecated since commit 155e1c82ed0. Signed-off-by: Philippe Mathieu-Daudé --- docs/about/deprecated.rst | 7 --- docs/about/removed-features.rst | 7 +++ hw/arm/raspi.c | 2 -- 3 files changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 8d4fd384a59..1e1a5e96ad4 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -207,13 +207,6 @@ this CPU is also deprecated. System emulator machines -Raspberry Pi ``raspi2`` and ``raspi3`` machines (since 5.2) -''' - -The Raspberry Pi machines come in various models (A, A+, B, B+). To be able -to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3`` -machines have been renamed ``raspi2b`` and ``raspi3b``. - Aspeed ``swift-bmc`` machine (since 6.1) diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst index 08f9e625ce6..9d0d90c90d9 100644 --- a/docs/about/removed-features.rst +++ b/docs/about/removed-features.rst @@ -574,6 +574,13 @@ This machine has been renamed ``fuloong2e``. These machine types were very old and likely could not be used for live migration from old QEMU versions anymore. Use a newer machine type instead. +Raspberry Pi ``raspi2`` and ``raspi3`` machines (removed in 6.2) + + +The Raspberry Pi machines come in various models (A, A+, B, B+). To be able +to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3`` +machines have been renamed ``raspi2b`` and ``raspi3b``. + linux-user mode CPUs diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c index 0ada91c05e9..146d35382bf 100644 --- a/hw/arm/raspi.c +++ b/hw/arm/raspi.c @@ -340,7 +340,6 @@ static void raspi2b_machine_class_init(ObjectClass *oc, void *data) MachineClass *mc = MACHINE_CLASS(oc); RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc); -mc->alias = "raspi2"; rmc->board_rev = 0xa21041; raspi_machine_class_common_init(mc, rmc->board_rev); }; @@ -360,7 +359,6 @@ static void raspi3b_machine_class_init(ObjectClass *oc, void *data) MachineClass *mc = MACHINE_CLASS(oc); RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc); -mc->alias = "raspi3"; rmc->board_rev = 0xa02082; raspi_machine_class_common_init(mc, rmc->board_rev); }; -- 2.31.1
Re: [PATCH] hw/arm/raspi: Remove deprecated raspi2/raspi3 aliases
Hi Peter, Can this patch go via your qemu-arm tree (it is reviewed)? On 5/3/21 12:57 PM, Philippe Mathieu-Daudé wrote: > Remove the raspi2/raspi3 machine aliases, > deprecated since commit 155e1c82ed0. > > Signed-off-by: Philippe Mathieu-Daudé > --- > docs/system/deprecated.rst | 7 --- > docs/system/removed-features.rst | 7 +++ > hw/arm/raspi.c | 2 -- > 3 files changed, 7 insertions(+), 9 deletions(-) > > diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst > index 80cae862528..7895bd4d849 100644 > --- a/docs/system/deprecated.rst > +++ b/docs/system/deprecated.rst > @@ -238,13 +238,6 @@ this CPU is also deprecated. > System emulator machines > > > -Raspberry Pi ``raspi2`` and ``raspi3`` machines (since 5.2) > -''' > - > -The Raspberry Pi machines come in various models (A, A+, B, B+). To be able > -to distinguish which model QEMU is implementing, the ``raspi2`` and > ``raspi3`` > -machines have been renamed ``raspi2b`` and ``raspi3b``. > - > Device options > -- > > diff --git a/docs/system/removed-features.rst > b/docs/system/removed-features.rst > index 29e90601a51..8a8b8ca627b 100644 > --- a/docs/system/removed-features.rst > +++ b/docs/system/removed-features.rst > @@ -312,6 +312,13 @@ This machine has been renamed ``fuloong2e``. > These machine types were very old and likely could not be used for live > migration from old QEMU versions anymore. Use a newer machine type instead. > > +Raspberry Pi ``raspi2`` and ``raspi3`` machines (removed in 6.1) > + > + > +The Raspberry Pi machines come in various models (A, A+, B, B+). To be able > +to distinguish which model QEMU is implementing, the ``raspi2`` and > ``raspi3`` > +machines have been renamed ``raspi2b`` and ``raspi3b``. > + > > linux-user mode CPUs > > diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c > index 990509d3852..20bba0316f1 100644 > --- a/hw/arm/raspi.c > +++ b/hw/arm/raspi.c > @@ -342,7 +342,6 @@ static void raspi2b_machine_class_init(ObjectClass *oc, > void *data) > MachineClass *mc = MACHINE_CLASS(oc); > RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc); > > -mc->alias = "raspi2"; > rmc->board_rev = 0xa21041; > raspi_machine_class_common_init(mc, rmc->board_rev); > }; > @@ -362,7 +361,6 @@ static void raspi3b_machine_class_init(ObjectClass *oc, > void *data) > MachineClass *mc = MACHINE_CLASS(oc); > RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc); > > -mc->alias = "raspi3"; > rmc->board_rev = 0xa02082; > raspi_machine_class_common_init(mc, rmc->board_rev); > }; >
[PATCH] hw/arm/raspi: Remove deprecated raspi2/raspi3 aliases
Remove the raspi2/raspi3 machine aliases, deprecated since commit 155e1c82ed0. Signed-off-by: Philippe Mathieu-Daudé --- docs/system/deprecated.rst | 7 --- docs/system/removed-features.rst | 7 +++ hw/arm/raspi.c | 2 -- 3 files changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 80cae862528..7895bd4d849 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -238,13 +238,6 @@ this CPU is also deprecated. System emulator machines -Raspberry Pi ``raspi2`` and ``raspi3`` machines (since 5.2) -''' - -The Raspberry Pi machines come in various models (A, A+, B, B+). To be able -to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3`` -machines have been renamed ``raspi2b`` and ``raspi3b``. - Device options -- diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst index 29e90601a51..8a8b8ca627b 100644 --- a/docs/system/removed-features.rst +++ b/docs/system/removed-features.rst @@ -312,6 +312,13 @@ This machine has been renamed ``fuloong2e``. These machine types were very old and likely could not be used for live migration from old QEMU versions anymore. Use a newer machine type instead. +Raspberry Pi ``raspi2`` and ``raspi3`` machines (removed in 6.1) + + +The Raspberry Pi machines come in various models (A, A+, B, B+). To be able +to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3`` +machines have been renamed ``raspi2b`` and ``raspi3b``. + linux-user mode CPUs diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c index 990509d3852..20bba0316f1 100644 --- a/hw/arm/raspi.c +++ b/hw/arm/raspi.c @@ -342,7 +342,6 @@ static void raspi2b_machine_class_init(ObjectClass *oc, void *data) MachineClass *mc = MACHINE_CLASS(oc); RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc); -mc->alias = "raspi2"; rmc->board_rev = 0xa21041; raspi_machine_class_common_init(mc, rmc->board_rev); }; @@ -362,7 +361,6 @@ static void raspi3b_machine_class_init(ObjectClass *oc, void *data) MachineClass *mc = MACHINE_CLASS(oc); RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc); -mc->alias = "raspi3"; rmc->board_rev = 0xa02082; raspi_machine_class_common_init(mc, rmc->board_rev); }; -- 2.26.3
[PULL 1/2] target/mips/mxu_translate.c: Fix array overrun for D16MIN/D16MAX
From: Peter Maydell
Coverity reported (CID 1450831) an array overrun in
gen_mxu_D16MAX_D16MIN():
1103 } else if (unlikely((XRb == 0) || (XRa == 0))) {
1112 if (opc == OPC_MXU_D16MAX) {
1113 tcg_gen_smax_i32(mxu_gpr[XRa - 1], t0, t1);
1114 } else {
1115 tcg_gen_smin_i32(mxu_gpr[XRa - 1], t0, t1);
1116 }
>>> Overrunning array "mxu_gpr" of 15 8-byte elements at element
index 4294967295 (byte offset 34359738367) using index "XRa - 1U"
(which evaluates to 4294967295).
This happens because the code is confused about which of XRa, XRb and
XRc is the output, and which are the inputs. XRa is the output, but
most of the conditions separating out different special cases are
written as if XRc is the output, with the result that we can end up
in the code path that assumes XRa is non-0 even when it is zero.
Fix the erroneous code, bringing it in to line with the structure
used in functions like gen_mxu_S32MAX_S32MIN() and
gen_mxu_Q8MAX_Q8MIN().
Fixes: CID 1450831
Fixes: bb84cbf38505bd1d8
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20210316131353.4533-1-peter.mayd...@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/mxu_translate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/mips/mxu_translate.c b/target/mips/mxu_translate.c
index afc008f..fb0a811af6c 100644
--- a/target/mips/mxu_translate.c
+++ b/target/mips/mxu_translate.c
@@ -1095,12 +1095,12 @@ static void gen_mxu_D16MAX_D16MIN(DisasContext *ctx)
if (unlikely(pad != 0)) {
/* opcode padding incorrect -> do nothing */
-} else if (unlikely(XRc == 0)) {
+} else if (unlikely(XRa == 0)) {
/* destination is zero register -> do nothing */
-} else if (unlikely((XRb == 0) && (XRa == 0))) {
+} else if (unlikely((XRb == 0) && (XRc == 0))) {
/* both operands zero registers -> just set destination to zero */
-tcg_gen_movi_i32(mxu_gpr[XRc - 1], 0);
-} else if (unlikely((XRb == 0) || (XRa == 0))) {
+tcg_gen_movi_i32(mxu_gpr[XRa - 1], 0);
+} else if (unlikely((XRb == 0) || (XRc == 0))) {
/* exactly one operand is zero register - find which one is not...*/
uint32_t XRx = XRb ? XRb : XRc;
/* ...and do half-word-wise max/min with one operand 0 */
--
2.26.2
[PULL 2/2] target/mips: Deprecate Trap-and-Emul KVM support
From: Jiaxun Yang Upstream kernel had removed both host[1] and guest[2] support. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=45c7e8af4a5e3f0bea4ac209eea34118dd57ac64 [2]: https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a1515ec7204edca770c07929df8538fcdb03ad46 Signed-off-by: Jiaxun Yang Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20210317011235.7425-1-jiaxun.y...@flygoat.com> Signed-off-by: Philippe Mathieu-Daudé --- docs/system/deprecated.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 67c98dcaa0c..d3004acf948 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -186,6 +186,15 @@ Use the more generic commands ``block-export-add`` and ``block-export-del`` instead. As part of this deprecation, where ``nbd-server-add`` used a single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``. +System accelerators +--- + +MIPS ``Trap-and-Emul`` KVM support (since 6.0) +'' + +The MIPS ``Trap-and-Emul`` KVM host and guest support has been removed +from upstream kernel, declare it deprecated. + System emulator CPUS -- 2.26.2
[PULL 0/2] MIPS patches for 2021-03-22
The following changes since commit bdee969c0e65d4d509932b1d70e3a3b2ffbff6d5: Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into staging (2021-03-19 18:01:17 +) are available in the Git repository at: https://github.com/philmd/qemu.git tags/mips-fixes-20210322 for you to fetch changes up to 83bbc537a151730741c04e40d23711067330dab9: target/mips: Deprecate Trap-and-Emul KVM support (2021-03-22 11:28:04 +0100) MIPS patches queue - Fix array overrun (Coverity CID 1450831) - Deprecate KVM TE (Trap-and-Emul) Jiaxun Yang (1): target/mips: Deprecate Trap-and-Emul KVM support Peter Maydell (1): target/mips/mxu_translate.c: Fix array overrun for D16MIN/D16MAX docs/system/deprecated.rst | 9 + target/mips/mxu_translate.c | 8 2 files changed, 13 insertions(+), 4 deletions(-) -- 2.26.2
Re: [PATCH v2] target/mips: Deprecate Trap-and-Emul KVM support
On 3/17/21 2:12 AM, Jiaxun Yang wrote: > Upstream kernel had removed both host[1] and guest[2] support. > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=45c7e8af4a5e3f0bea4ac209eea34118dd57ac64 > [2]: > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a1515ec7204edca770c07929df8538fcdb03ad46 > > Signed-off-by: Jiaxun Yang > > Signed-off-by: Jiaxun Yang > --- > v2: Fix up tittle and sphinx format (f4bug) > Lost in the sea of emails :-) > --- > docs/system/deprecated.rst | 9 + > 1 file changed, 9 insertions(+) Thanks, applied to mips-fixes.
Re: [PATCH v2] target/mips: Deprecate Trap-and-Emul KVM support
On 3/17/21 2:12 AM, Jiaxun Yang wrote: > Upstream kernel had removed both host[1] and guest[2] support. > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=45c7e8af4a5e3f0bea4ac209eea34118dd57ac64 > [2]: > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a1515ec7204edca770c07929df8538fcdb03ad46 > > Signed-off-by: Jiaxun Yang > > Signed-off-by: Jiaxun Yang > --- > v2: Fix up tittle and sphinx format (f4bug) > Lost in the sea of emails :-) > --- > docs/system/deprecated.rst | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] target/mips: Deprecate Trap-and-Emul KVM support
Jiaxun, ping for moving the section? On 3/12/21 10:43 AM, Philippe Mathieu-Daudé wrote: > +Paolo/Thomas/KVM > > On 3/12/21 2:03 AM, Jiaxun Yang wrote: >> Upstream kernel had removed both host[1] and guest[2] support. >> >> [1]: >> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=45c7e8af4a5e3f0bea4ac209eea34118dd57ac64 >> [2]: >> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a1515ec7204edca770c07929df8538fcdb03ad46 >> >> Signed-off-by: Jiaxun Yang >> --- >> docs/system/deprecated.rst | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst >> index cfabe69846..a409c65485 100644 >> --- a/docs/system/deprecated.rst >> +++ b/docs/system/deprecated.rst >> @@ -496,3 +496,11 @@ nanoMIPS ISA >> >> The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain. >> As it is hard to generate binaries for it, declare it deprecated. >> + >> +KVM features >> +--- > > "" else Sphinx complains. > >> + >> +MIPS Trap-and-Emul KVM support > > Missing "since which release" information. > >> + >> +The MIPS ``Trap-and-Emul`` KVM host and guest support has been removed >> +from upstream kernel, declare it deprecated. >> > > What about adding an accelerator section and add this as a sub-section? > > -- >8 -- > diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst > index a4515d8acd3..9c702a4ea7b 100644 > --- a/docs/system/deprecated.rst > +++ b/docs/system/deprecated.rst > @@ -292,6 +292,15 @@ The ``acl_show``, ``acl_reset``, ``acl_policy``, > ``acl_add``, and > ``acl_remove`` commands are deprecated with no replacement. Authorization > for VNC should be performed using the pluggable QAuthZ objects. > > +System accelerators > +--- > + > +MIPS ``Trap-and-Emul`` KVM support (since 6.0) > +'' > + > +The MIPS ``Trap-and-Emul`` KVM host and guest support has been removed > +from upstream kernel, declare it deprecated. > + > System emulator CPUS > > > --- >
Re: [PATCH] target/mips: Deprecate Trap-and-Emul KVM support
+Paolo/Thomas/KVM On 3/12/21 2:03 AM, Jiaxun Yang wrote: > Upstream kernel had removed both host[1] and guest[2] support. > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=45c7e8af4a5e3f0bea4ac209eea34118dd57ac64 > [2]: > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a1515ec7204edca770c07929df8538fcdb03ad46 > > Signed-off-by: Jiaxun Yang > --- > docs/system/deprecated.rst | 8 > 1 file changed, 8 insertions(+) > > diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst > index cfabe69846..a409c65485 100644 > --- a/docs/system/deprecated.rst > +++ b/docs/system/deprecated.rst > @@ -496,3 +496,11 @@ nanoMIPS ISA > > The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain. > As it is hard to generate binaries for it, declare it deprecated. > + > +KVM features > +--- "" else Sphinx complains. > + > +MIPS Trap-and-Emul KVM support Missing "since which release" information. > + > +The MIPS ``Trap-and-Emul`` KVM host and guest support has been removed > +from upstream kernel, declare it deprecated. > What about adding an accelerator section and add this as a sub-section? -- >8 -- diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index a4515d8acd3..9c702a4ea7b 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -292,6 +292,15 @@ The ``acl_show``, ``acl_reset``, ``acl_policy``, ``acl_add``, and ``acl_remove`` commands are deprecated with no replacement. Authorization for VNC should be performed using the pluggable QAuthZ objects. +System accelerators +--- + +MIPS ``Trap-and-Emul`` KVM support (since 6.0) +'' + +The MIPS ``Trap-and-Emul`` KVM host and guest support has been removed +from upstream kernel, declare it deprecated. + System emulator CPUS ---
Re: [PATCH 00/14] deprecations: remove many old deprecations
On 2/24/21 3:38 PM, Peter Maydell wrote:
> On Wed, 24 Feb 2021 at 13:21, Daniel P. Berrangé wrote:
>>
>> The following features have been deprecated for well over the 2
>> release cycle we promise
>>
>> ``-usbdevice`` (since 2.10.0)
>> ``-drive file=3Djson:{...{'driver':'file'}}`` (since 3.0)
>> ``-vnc acl`` (since 4.0.0)
>> ``-mon ...,control=3Dreadline,pretty=3Don|off`` (since 4.1)
>
> Are the literal '=3D' here intended ?
No, this is a git-publish bug:
https://github.com/stefanha/git-publish/issues/88
Apparently the fix is not yet backported to Fedora.
Re: [PATCH v2 3/4] utils: Deprecate hex-with-suffix sizes
On 2/11/21 9:44 PM, Eric Blake wrote: > Supporting '0x20M' looks odd, particularly since we have a 'B' suffix > that is ambiguous for bytes, as well as a less-frequently-used 'E' > suffix for extremely large exibytes. In practice, people using hex > inputs are specifying values in bytes (and would have written > 0x200, or possibly relied on default_suffix in the case of > qemu_strtosz_MiB), and the use of scaling suffixes makes the most > sense for inputs in decimal (where the user would write 32M). But > rather than outright dropping support for hex-with-suffix, let's > follow our deprecation policy. Sadly, since qemu_strtosz() does not > have an Err** parameter, and plumbing that in would be a much larger > task, we instead go with just directly emitting the deprecation > warning to stderr. > > Signed-off-by: Eric Blake > --- > docs/system/deprecated.rst | 8 > util/cutils.c | 10 +- > 2 files changed, 17 insertions(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [RFC] Change default ipv6 network from fec0/10 (site local) to fe80/10 (link local)
Hi Doug, Cc'ing more developers. On 1/27/21 8:13 PM, Doug Evans wrote: > Hi. > > This is just an information gathering question. I don't know enough to > formally propose the change. > I happened to notice QEMU's default for the ipv6 network is fec0::/10 > which is deprecated (RFC3879). > I think(!) an obvious replacement is fe80::/10, link local. > > Has anyone thought about this issue or know of reasons why we shouldn't > make this change? I'm a bit worried this could break various scripts and firewall rules where this is the expected default range...
Re: [PATCH] Deprecate pmem=on with non-DAX capable backend file
Cc'ing MST.
On 1/20/21 8:31 PM, Igor Mammedov wrote:
> On Mon, 11 Jan 2021 15:33:32 -0500
> Igor Mammedov wrote:
>
>> It is not safe to pretend that emulated NVDIMM supports
>> persistence while backend actually failed to enable it
>> and used non-persistent mapping as fall back.
>> Instead of falling-back, QEMU should be more strict and
>> error out with clear message that it's not supported.
>> So if user asks for persistence (pmem=on), they should
>> store backing file on NVDIMM.
>>
>> Signed-off-by: Igor Mammedov
>> Reviewed-by: Philippe Mathieu-Daudé
>> ---
>> v2:
>> rephrase deprecation comment andwarning message
>> (Philippe Mathieu-Daudé )
>
> I've posted as v1 though it's v2 and it looks like it fell through cracks,
>
> can someone pick it up if it looks fine, please?
>
>> ---
>> docs/system/deprecated.rst | 17 +
>> util/mmap-alloc.c | 3 +++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
>> index bacd76d7a5..e79fb02b3a 100644
>> --- a/docs/system/deprecated.rst
>> +++ b/docs/system/deprecated.rst
>> @@ -327,6 +327,23 @@ The Raspberry Pi machines come in various models (A,
>> A+, B, B+). To be able
>> to distinguish which model QEMU is implementing, the ``raspi2`` and
>> ``raspi3``
>> machines have been renamed ``raspi2b`` and ``raspi3b``.
>>
>> +Backend options
>> +---
>> +
>> +Using non-persistent backing file with pmem=on (since 6.0)
>> +''
>> +
>> +This option is used when ``memory-backend-file`` is consumed by emulated
>> NVDIMM
>> +device. However enabling ``memory-backend-file.pmem`` option, when backing
>> file
>> +is (a) not DAX capable or (b) not on a filesystem that support direct
>> mapping
>> +of persistent memory, is not safe and may lead to data loss or corruption
>> in case
>> +of host crash.
>> +Options are:
>> +- modify VM configuration to set ``pmem=off`` to continue using fake
>> NVDIMM
>> + (without persistence guaranties) with backing file on non DAX storage
>> +- move backing file to NVDIMM storage and keep ``pmem=on``
>> + (to have NVDIMM with persistence guaranties).
>> +
>> Device options
>> --
>>
>> diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
>> index 27dcccd8ec..0388cc3be2 100644
>> --- a/util/mmap-alloc.c
>> +++ b/util/mmap-alloc.c
>> @@ -20,6 +20,7 @@
>> #include "qemu/osdep.h"
>> #include "qemu/mmap-alloc.h"
>> #include "qemu/host-utils.h"
>> +#include "qemu/error-report.h"
>>
>> #define HUGETLBFS_MAGIC 0x958458f6
>>
>> @@ -166,6 +167,8 @@ void *qemu_ram_mmap(int fd,
>> "crash.\n", file_name);
>> g_free(proc_link);
>> g_free(file_name);
>> +warn_report("Using non DAX backing file with 'pmem=on' option"
>> +" is deprecated");
>> }
>> /*
>> * if map failed with MAP_SHARED_VALIDATE | MAP_SYNC,
>
Re: [PULL 00/66] MIPS patches for 2021-01-07
Hi Peter, Le ven. 8 janv. 2021 11:35, Peter Maydell a écrit : > On Thu, 7 Jan 2021 at 22:25, Philippe Mathieu-Daudé > wrote: > > > > The following changes since commit > 470dd6bd360782f5137f7e3376af6a44658eb1d3: > > > > Merge remote-tracking branch > 'remotes/stsquad/tags/pull-testing-060121-4' into staging (2021-01-06 > 22:18:36 +) > > > > are available in the Git repository at: > > > > https://gitlab.com/philmd/qemu.git tags/mips-20210107 > > > > for you to fetch changes up to f97d339d612b86d8d336a11f01719a10893d6707: > > > > docs/system: Remove deprecated 'fulong2e' machine alias (2021-01-07 > 22:57:49 +0100) > > > > > > MIPS patches queue > > > > - Simplify CPU/ISA definitions > > - Various maintenance code movements in translate.c > > - Convert part of the MSA ASE instructions to decodetree > > - Convert some instructions removed from Release 6 to decodetree > > - Remove deprecated 'fulong2e' machine alias > > Hi; this failed to build on some of my hosts: > > [1/4674] Generating 'libqemu-mipsel-softmmu.fa.p/decode-mips64r6.c.inc'. > FAILED: libqemu-mipsel-softmmu.fa.p/decode-mips64r6.c.inc > /usr/bin/python3 /home/petmay01/qemu-for-merges/scripts/decodetree.py > ../../target/mips/mips64r6.decode --static-deco > de=decode_mips64r6 -o libqemu-mipsel-softmmu.fa.p/decode-mips64r6.c.inc > Traceback (most recent call last): > File "/home/petmay01/qemu-for-merges/scripts/decodetree.py", line > 1397, in > main() > File "/home/petmay01/qemu-for-merges/scripts/decodetree.py", line > 1308, in main > parse_file(f, toppat) > File "/home/petmay01/qemu-for-merges/scripts/decodetree.py", line > 994, in parse_file > for line in f: > File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position > 80: ordinal not in range(128) > My lastname in the copyright line =) [2/4674] Generating 'libqemu-mipsel-softmmu.fa.p/decode-msa64.c.inc'. > FAILED: libqemu-mipsel-softmmu.fa.p/decode-msa64.c.inc > /usr/bin/python3 /home/petmay01/qemu-for-merges/scripts/decodetree.py > ../../target/mips/msa64.decode --static-decode= > decode_msa64 -o libqemu-mipsel-softmmu.fa.p/decode-msa64.c.inc > Traceback (most recent call last): > File "/home/petmay01/qemu-for-merges/scripts/decodetree.py", line > 1397, in > main() > File "/home/petmay01/qemu-for-merges/scripts/decodetree.py", line > 1308, in main > parse_file(f, toppat) > File "/home/petmay01/qemu-for-merges/scripts/decodetree.py", line > 994, in parse_file > for line in f: > File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position > 93: ordinal not in range(128) > > etc. > > Looks like decodetree fails to cope with non-ASCII characters in > its input file -- probably this depends on the host locale settings: > I think these hosts run in the 'C' locale. > Can you provide more information on your host so we can cover it in Gitlab-CI? Thanks, Phil. >
Re: [PULL 00/66] MIPS patches for 2021-01-07
On 1/7/21 11:21 PM, Philippe Mathieu-Daudé wrote:
> The following changes since commit 470dd6bd360782f5137f7e3376af6a44658eb1d3:
>
> Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-060121-4'
> into staging (2021-01-06 22:18:36 +)
>
> are available in the Git repository at:
>
> https://gitlab.com/philmd/qemu.git tags/mips-20210107
>
> for you to fetch changes up to f97d339d612b86d8d336a11f01719a10893d6707:
>
> docs/system: Remove deprecated 'fulong2e' machine alias (2021-01-07
> 22:57:49 +0100)
>
>
> MIPS patches queue
>
> - Simplify CPU/ISA definitions
> - Various maintenance code movements in translate.c
> - Convert part of the MSA ASE instructions to decodetree
> - Convert some instructions removed from Release 6 to decodetree
> - Remove deprecated 'fulong2e' machine alias
>
>
I forgot to mention there is a checkpatch.pl error with
patch 23 ("Move common helpers from helper.c to cpu.c")
due to code movement:
ERROR: space prohibited after that '&' (ctx:WxW)
#52: FILE: target/mips/cpu.c:53:
+cu = (v >> CP0St_CU0) & 0xf;
^
ERROR: space prohibited after that '&' (ctx:WxW)
#53: FILE: target/mips/cpu.c:54:
+mx = (v >> CP0St_MX) & 0x1;
^
ERROR: space prohibited after that '&' (ctx:WxW)
#54: FILE: target/mips/cpu.c:55:
+ksu = (v >> CP0St_KSU) & 0x3;
^
ERROR: space prohibited after that '&' (ctx:WxW)
#81: FILE: target/mips/cpu.c:82:
+uint32_t ksux = (1 << CP0St_KX) & val;
^
ERROR: space prohibited after that '&' (ctx:WxW)
#89: FILE: target/mips/cpu.c:90:
+mask &= ~(((1 << CP0St_SR) | (1 << CP0St_NMI)) & val);
^
ERROR: space prohibited after that '&' (ctx:WxW)
#116: FILE: target/mips/cpu.c:117:
+mask &= ~((1 << CP0Ca_WP) & val);
^
ERROR: space prohibited after that '&' (ctx:WxW)
#121: FILE: target/mips/cpu.c:122:
+if ((old ^ env->CP0_Cause) & (1 << CP0Ca_DC)) {
^
ERROR: space prohibited after that '&' (ctx:WxW)
#131: FILE: target/mips/cpu.c:132:
+if ((old ^ env->CP0_Cause) & (1 << (CP0Ca_IP + i))) {
^
total: 8 errors, 0 warnings, 433 lines checked
[PULL 66/66] docs/system: Remove deprecated 'fulong2e' machine alias
The 'fulong2e' machine alias has been marked as deprecated since
QEMU v5.1 (commit c3a09ff68dd, the machine is renamed 'fuloong2e').
Time to remove it now.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Huacai Chen
Reviewed-by: Thomas Huth
Message-Id: <20210106184602.3771551-1-f4...@amsat.org>
---
docs/system/deprecated.rst | 5 -
docs/system/removed-features.rst | 5 +
hw/mips/fuloong2e.c | 1 -
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index bacd76d7a58..e20bfcb17a4 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -309,11 +309,6 @@ The 'scsi-disk' device is deprecated. Users should use
'scsi-hd' or
System emulator machines
-mips ``fulong2e`` machine (since 5.1)
-'
-
-This machine has been renamed ``fuloong2e``.
-
``pc-1.0``, ``pc-1.1``, ``pc-1.2`` and ``pc-1.3`` (since 5.0)
'
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 8b20d78a4d0..430fc33ca18 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -120,6 +120,11 @@ mips ``r4k`` platform (removed in 5.2)
This machine type was very old and unmaintained. Users should use the ``malta``
machine type instead.
+mips ``fulong2e`` machine alias (removed in 6.0)
+
+
+This machine has been renamed ``fuloong2e``.
+
Related binaries
diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index 29805242caa..bac2adbd5ae 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -383,7 +383,6 @@ static void mips_fuloong2e_init(MachineState *machine)
static void mips_fuloong2e_machine_init(MachineClass *mc)
{
mc->desc = "Fuloong 2e mini pc";
-mc->alias = "fulong2e"; /* Incorrect name used up to QEMU 4.2
*/
mc->init = mips_fuloong2e_init;
mc->block_default_type = IF_IDE;
mc->default_cpu_type = MIPS_CPU_TYPE_NAME("Loongson-2E");
--
2.26.2
[PULL 65/66] target/mips: Convert Rel6 LL/SC opcodes to decodetree
LL/SC opcodes have been removed from the Release 6.
Add a single decodetree entry for the opcodes, triggering
Reserved Instruction if ever used.
Remove unreachable check_insn_opc_removed() calls.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20201208203704.243704-14-f4...@amsat.org>
---
target/mips/mips32r6.decode | 2 ++
target/mips/translate.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/mips/mips32r6.decode b/target/mips/mips32r6.decode
index 3ec50704cf2..489c20aa4e9 100644
--- a/target/mips/mips32r6.decode
+++ b/target/mips/mips32r6.decode
@@ -31,4 +31,6 @@ REMOVED 101010 - - #
SWL
REMOVED 101110 - - # SWR
REMOVED 10 - - # CACHE
+REMOVED 11 - - # LL
REMOVED 110011 - - # PREF
+REMOVED 111000 - - # SC
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 9f717aab287..b5b7706a7c2 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28585,7 +28585,6 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
if (ctx->insn_flags & INSN_R5900) {
check_insn_opc_user_only(ctx, INSN_R5900);
}
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
/* Fallthrough */
case OPC_LWL:
case OPC_LWR:
@@ -28606,7 +28605,6 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
break;
case OPC_SC:
check_insn(ctx, ISA_MIPS2);
- check_insn_opc_removed(ctx, ISA_MIPS_R6);
if (ctx->insn_flags & INSN_R5900) {
check_insn_opc_user_only(ctx, INSN_R5900);
}
--
2.26.2
[PULL 64/66] target/mips: Convert Rel6 LLD/SCD opcodes to decodetree
LLD/SCD opcodes have been removed from the Release 6.
Add a single decodetree entry for the opcodes, triggering
Reserved Instruction if ever used.
Remove unreachable check_insn_opc_removed() calls.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20201208203704.243704-13-f4...@amsat.org>
---
target/mips/mips64r6.decode | 3 +++
target/mips/translate.c | 2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/target/mips/mips64r6.decode b/target/mips/mips64r6.decode
index 8c3fc5dae9c..609b8958d25 100644
--- a/target/mips/mips64r6.decode
+++ b/target/mips/mips64r6.decode
@@ -21,3 +21,6 @@ REMOVED 011010 - - #
LDL
REMOVED 011011 - - # LDR
REMOVED 101100 - - # SDL
REMOVED 101101 - - # SDR
+
+REMOVED 110100 - - # LLD
+REMOVED 00 - - # SCD
diff --git a/target/mips/translate.c b/target/mips/translate.c
index f46d7c5f80b..9f717aab287 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28871,7 +28871,6 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
if (ctx->insn_flags & INSN_R5900) {
check_insn_opc_user_only(ctx, INSN_R5900);
}
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
/* fall through */
case OPC_LDL:
case OPC_LDR:
@@ -28889,7 +2,6 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
gen_st(ctx, op, rt, rs, imm);
break;
case OPC_SCD:
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
check_insn(ctx, ISA_MIPS3);
if (ctx->insn_flags & INSN_R5900) {
check_insn_opc_user_only(ctx, INSN_R5900);
--
2.26.2
[PULL 63/66] target/mips: Convert Rel6 LDL/LDR/SDL/SDR opcodes to decodetree
LDL/LDR/SDL/SDR opcodes have been removed from the Release 6.
Add a single decodetree entry for the opcodes, triggering
Reserved Instruction if ever used.
Remove unreachable check_insn_opc_removed() calls.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20201208203704.243704-12-f4...@amsat.org>
---
target/mips/mips64r6.decode | 6 ++
target/mips/translate.c | 5 +
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/target/mips/mips64r6.decode b/target/mips/mips64r6.decode
index e812224341e..8c3fc5dae9c 100644
--- a/target/mips/mips64r6.decode
+++ b/target/mips/mips64r6.decode
@@ -10,8 +10,14 @@
# (Document Number: MD00087-2B-MIPS64BIS-AFP-6.06)
#
+!extern
rd rt rs sa !extern
@lsa.. rs:5 rt:5 rd:5 ... sa:2 ..
DLSA00 . . . 000 .. 010101 @lsa
+
+REMOVED 011010 - - # LDL
+REMOVED 011011 - - # LDR
+REMOVED 101100 - - # SDL
+REMOVED 101101 - - # SDR
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 73efbd24585..f46d7c5f80b 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28871,11 +28871,10 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
if (ctx->insn_flags & INSN_R5900) {
check_insn_opc_user_only(ctx, INSN_R5900);
}
+check_insn_opc_removed(ctx, ISA_MIPS_R6);
/* fall through */
case OPC_LDL:
case OPC_LDR:
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
-/* fall through */
case OPC_LWU:
case OPC_LD:
check_insn(ctx, ISA_MIPS3);
@@ -28884,8 +28883,6 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
break;
case OPC_SDL:
case OPC_SDR:
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
-/* fall through */
case OPC_SD:
check_insn(ctx, ISA_MIPS3);
check_mips_64(ctx);
--
2.26.2
[PULL 61/66] target/mips: Convert Rel6 LWL/LWR/SWL/SWR opcodes to decodetree
LWL/LWR/SWL/SWR opcodes have been removed from the Release 6.
Add a single decodetree entry for the opcodes, triggering
Reserved Instruction if ever used.
Remove unreachable check_insn_opc_removed() calls.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20201208203704.243704-10-f4...@amsat.org>
---
target/mips/mips32r6.decode | 5 +
target/mips/translate.c | 5 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/target/mips/mips32r6.decode b/target/mips/mips32r6.decode
index e3b3934539a..89a0085fafd 100644
--- a/target/mips/mips32r6.decode
+++ b/target/mips/mips32r6.decode
@@ -20,5 +20,10 @@ REMOVED 010011 - - - - --
# COP1X (COP3)
REMOVED 011100 - - - - -- # SPECIAL2
+REMOVED 100010 - - # LWL
+REMOVED 100110 - - # LWR
+REMOVED 101010 - - # SWL
+REMOVED 101110 - - # SWR
+
REMOVED 10 - - # CACHE
REMOVED 110011 - - # PREF
diff --git a/target/mips/translate.c b/target/mips/translate.c
index e8389738c57..0d729293f6b 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28589,11 +28589,10 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
if (ctx->insn_flags & INSN_R5900) {
check_insn_opc_user_only(ctx, INSN_R5900);
}
+check_insn_opc_removed(ctx, ISA_MIPS_R6);
/* Fallthrough */
case OPC_LWL:
case OPC_LWR:
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
- /* Fallthrough */
case OPC_LB:
case OPC_LH:
case OPC_LW:
@@ -28604,8 +28603,6 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
break;
case OPC_SWL:
case OPC_SWR:
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
-/* fall through */
case OPC_SB:
case OPC_SH:
case OPC_SW:
--
2.26.2
[PULL 62/66] target/mips: Convert Rel6 LWLE/LWRE/SWLE/SWRE opcodes to decodetree
LWLE/LWRE/SWLE/SWRE (EVA) opcodes have been removed from
the Release 6. Add a single decodetree entry for the opcodes,
triggering Reserved Instruction if ever used.
Remove unreachable check_insn_opc_removed() calls.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20201208203704.243704-11-f4...@amsat.org>
---
target/mips/mips32r6.decode | 5 +
target/mips/translate.c | 4
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/target/mips/mips32r6.decode b/target/mips/mips32r6.decode
index 89a0085fafd..3ec50704cf2 100644
--- a/target/mips/mips32r6.decode
+++ b/target/mips/mips32r6.decode
@@ -20,6 +20,11 @@ REMOVED 010011 - - - - --
# COP1X (COP3)
REMOVED 011100 - - - - -- # SPECIAL2
+REMOVED 01 - - -- 011001 # LWLE
+REMOVED 01 - - -- 011010 # LWRE
+REMOVED 01 - - -- 11 # SWLE
+REMOVED 01 - - -- 100010 # SWRE
+
REMOVED 100010 - - # LWL
REMOVED 100110 - - # LWR
REMOVED 101010 - - # SWL
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 0d729293f6b..73efbd24585 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28122,8 +28122,6 @@ static void decode_opc_special3(CPUMIPSState *env,
DisasContext *ctx)
switch (op1) {
case OPC_LWLE:
case OPC_LWRE:
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
-/* fall through */
case OPC_LBUE:
case OPC_LHUE:
case OPC_LBE:
@@ -28135,8 +28133,6 @@ static void decode_opc_special3(CPUMIPSState *env,
DisasContext *ctx)
return;
case OPC_SWLE:
case OPC_SWRE:
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
-/* fall through */
case OPC_SBE:
case OPC_SHE:
case OPC_SWE:
--
2.26.2
[PULL 59/66] target/mips: Convert Rel6 COP1X opcode to decodetree
COP1x opcode has been removed from the Release 6.
Add a single decodetree entry for it, triggering
Reserved Instruction if ever used.
Remove unreachable check_insn_opc_removed() call.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20201208203704.243704-8-f4...@amsat.org>
---
target/mips/mips32r6.decode | 2 ++
target/mips/translate.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/mips/mips32r6.decode b/target/mips/mips32r6.decode
index 259bac612ab..7b12a1bff25 100644
--- a/target/mips/mips32r6.decode
+++ b/target/mips/mips32r6.decode
@@ -16,4 +16,6 @@
LSA 00 . . . 000 .. 000101 @lsa
+REMOVED 010011 - - - - -- # COP1X (COP3)
+
REMOVED 011100 - - - - -- # SPECIAL2
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 01c1ee546e2..52397bce84b 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28827,7 +28827,6 @@ static bool decode_opc_legacy(CPUMIPSState *env,
DisasContext *ctx)
break;
case OPC_CP3:
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
if (ctx->CP0_Config1 & (1 << CP0C1_FP)) {
check_cp1_enabled(ctx);
op1 = MASK_CP3(ctx->opcode);
--
2.26.2
[PULL 58/66] target/mips: Convert Rel6 Special2 opcode to decodetree
Special2 opcode have been removed from the Release 6.
Add a single decodetree entry for all the opcode class,
triggering Reserved Instruction if ever used.
Remove unreachable check_insn_opc_removed() call.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20201208203704.243704-7-f4...@amsat.org>
---
target/mips/mips32r6.decode | 2 ++
target/mips/rel6_translate.c | 7 +++
target/mips/translate.c | 2 --
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/target/mips/mips32r6.decode b/target/mips/mips32r6.decode
index 027585ee042..259bac612ab 100644
--- a/target/mips/mips32r6.decode
+++ b/target/mips/mips32r6.decode
@@ -15,3 +15,5 @@
@lsa.. rs:5 rt:5 rd:5 ... sa:2 ..
LSA 00 . . . 000 .. 000101 @lsa
+
+REMOVED 011100 - - - - -- # SPECIAL2
diff --git a/target/mips/rel6_translate.c b/target/mips/rel6_translate.c
index 631d0b87748..51264f0ce92 100644
--- a/target/mips/rel6_translate.c
+++ b/target/mips/rel6_translate.c
@@ -18,6 +18,13 @@
#include "decode-mips32r6.c.inc"
#include "decode-mips64r6.c.inc"
+bool trans_REMOVED(DisasContext *ctx, arg_REMOVED *a)
+{
+gen_reserved_instruction(ctx);
+
+return true;
+}
+
static bool trans_LSA(DisasContext *ctx, arg_LSA *a)
{
return gen_LSA(ctx, a->rd, a->rt, a->rs, a->sa);
diff --git a/target/mips/translate.c b/target/mips/translate.c
index f4481afb8de..01c1ee546e2 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -27137,8 +27137,6 @@ static void decode_opc_special2_legacy(CPUMIPSState
*env, DisasContext *ctx)
int rs, rt, rd;
uint32_t op1;
-check_insn_opc_removed(ctx, ISA_MIPS_R6);
-
rs = (ctx->opcode >> 21) & 0x1f;
rt = (ctx->opcode >> 16) & 0x1f;
rd = (ctx->opcode >> 11) & 0x1f;
--
2.26.2
