[PATCH qemu v2] target/riscv: Check ext_zca for misaligned return address of mret/sret.
From: Yu-Ming Chang
We only check RVC to allow 16-bit aligned return addreses. This will
cause issues when only ext_zca is enabled without RVC: 16-bit
instructions are allowed, but 16-bit aligned return address are not.
We should also check ext_zca to permit 16-bit aligned return addresses.
Signed-off-by: Yu-Ming Chang
---
The v2 has been updated to provide more explanation.
target/riscv/op_helper.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index eddedacf4b..891002f954 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -269,8 +269,10 @@ target_ulong helper_sret(CPURISCVState *env)
}
target_ulong retpc = env->sepc;
-if (!riscv_has_ext(env, RVC) && (retpc & 0x3)) {
-riscv_raise_exception(env, RISCV_EXCP_INST_ADDR_MIS, GETPC());
+if (!riscv_has_ext(env, RVC) && !env_archcpu(env)->cfg.ext_zca) {
+if ((retpc & 0x3) != 0) {
+riscv_raise_exception(env, RISCV_EXCP_INST_ADDR_MIS, GETPC());
+}
}
if (get_field(env->mstatus, MSTATUS_TSR) && !(env->priv >= PRV_M)) {
@@ -328,8 +330,10 @@ target_ulong helper_mret(CPURISCVState *env)
}
target_ulong retpc = env->mepc;
-if (!riscv_has_ext(env, RVC) && (retpc & 0x3)) {
-riscv_raise_exception(env, RISCV_EXCP_INST_ADDR_MIS, GETPC());
+if (!riscv_has_ext(env, RVC) && !env_archcpu(env)->cfg.ext_zca) {
+if ((retpc & 0x3) != 0) {
+riscv_raise_exception(env, RISCV_EXCP_INST_ADDR_MIS, GETPC());
+}
}
uint64_t mstatus = env->mstatus;
--
2.45.3
Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation
On 2025/02/03 7:08, Dmitry Osipenko wrote: On 1/27/25 07:57, Akihiko Odaki wrote: On 2025/01/27 3:06, Dmitry Osipenko wrote: On 1/21/25 07:26, Akihiko Odaki wrote: ... I feel the dependency information for virglrenderer and Mesa are more suited for the Mesa documentation as they are not specific to QEMU and potentially useful also for e.g., libkrun and crosvm. I think while everything is in so much flux it doesn't hurt to include in our docs. I don't know if mesa currently has a dedicated page for GPU virtualisation. Mesa has pages for VirGL and Venus, which can be linked from the respective parts of this documentation. gfxstream is not documented but I think most people will use it only for Android anyway. A documentation for DRM native context will be a nice addition for Mesa. I will not object if you put this information to QEMU documentation though. Adding native context doc to Mesa indeed will be a good move, as well as adding links to the Mesa virgl/venus pages in QEMU. RE requirements documentation, it's also a valid point that stuff like build flags should belong to the relevant projects. On the other hand, it's a common headache for a newcoming people to figure everything out from scratch and having more centralized documentation helps. The build requirements aren't cleanly documented anywhere AFAICT, and the requirements also differ based on VMM. I'll update and keep this patch in v6, the requirements info should stay actual for a next couple years IMO. Let's discuss it further in v6 if more objections will arise. I think it's fine to require one click to reach the relevant documentation. How do the requirements described here vary with VMM? Requirements don't vary much. For example virglrenderer minigbm support is mandatory for crosvm, while for QEMU it's not. Is that true? It seems that virglrenderer uses builds without minigbm support to run tests on GitLab CI. Anyway, if there is any variance in the build procedure, that may justify having a separate build instruction in QEMU tree to avoid confusion. Otherwise, it's better to have a documentation shared with other VMMs. I'm not entirely sure the documentation will stay as is for that long. The requirements of Intel native context refer to merge requests that can be merged sooner or later. Asahi may need more updates if you document it too because its DRM ABI is still unstable. The unstable parts of course will need to be updated sooner, but the stable should be solid for years. I expect that about a year later requirements will need to be revisited. It will be some burden in the future. Now you are adding this documentation just for QEMU, but crosvm and libkrun may gain similar documentation. The DRM native context support for Intel and Asahi is in development, and I guess nvk will support it someday. So, a very rough estimation of future documentation updates will be: (number of VMMs) * (number of DRM native contexts in development) = 3 * 3 = 9 That's manageable but suboptimal. Regards, Akihiko Odaki
RE: [PATCH 2/2] hw/arm/aspeed_ast27x0: Avoid hardcoded '256' in IRQ calculation
Hi Philippe
> From: Philippe Mathieu-Daudé
> Sent: Thursday, January 30, 2025 11:03 PM
> To: qemu-...@nongnu.org; qemu-devel@nongnu.org
> Cc: Cédric Le Goater ; Peter Maydell
> ; Steven Lee ; Troy
> Lee ; Jamin Lin ; Andrew
> Jeffery ; Joel Stanley
> Subject: Re: [PATCH 2/2] hw/arm/aspeed_ast27x0: Avoid hardcoded '256' in
> IRQ calculation
>
> On 1/11/24 17:11, Peter Maydell wrote:
> > When calculating the index into the GIC's GPIO array for per-CPU
> > interrupts, we have to start with the number of SPIs. The code
> > currently hard-codes this to 'NUM_IRQS = 256'. However the number of
> > SPIs is set separately and implicitly by the value of AST2700_MAX_IRQ,
> > which is the number of SPIs plus 32 (since it is what we set the GIC
> > num-irq property to).
> >
> > Define AST2700_MAX_IRQ as the total number of SPIs; this brings
> > AST2700 into line with AST2600, which defines AST2600_MAX_IRQ as the
> > number of SPIs not including the 32 internal interrupts. We can then
> > use AST2700_MAX_IRQ instead of the hardcoded 256.
> >
> > Signed-off-by: Peter Maydell
> > ---
> > hw/arm/aspeed_ast27x0.c | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/arm/aspeed_ast27x0.c b/hw/arm/aspeed_ast27x0.c index
> > 5638a7a5781..7b246440952 100644
> > --- a/hw/arm/aspeed_ast27x0.c
> > +++ b/hw/arm/aspeed_ast27x0.c
> > @@ -66,7 +66,7 @@ static const hwaddr aspeed_soc_ast2700_memmap[] =
> {
> > [ASPEED_DEV_GPIO] = 0x14C0B000,
> > };
> >
> > -#define AST2700_MAX_IRQ 288
> > +#define AST2700_MAX_IRQ 256
> >
> > /* Shared Peripheral Interrupt values below are offset by -32 from
> datasheet */
> > static const int aspeed_soc_ast2700_irqmap[] = { @@ -403,7 +403,7 @@
> > static bool aspeed_soc_ast2700_gic_realize(DeviceState *dev, Error **errp)
> > gicdev = DEVICE(&a->gic);
> > qdev_prop_set_uint32(gicdev, "revision", 3);
> > qdev_prop_set_uint32(gicdev, "num-cpu", sc->num_cpus);
> > -qdev_prop_set_uint32(gicdev, "num-irq", AST2700_MAX_IRQ);
> > +qdev_prop_set_uint32(gicdev, "num-irq", AST2700_MAX_IRQ +
> > + GIC_INTERNAL);
>
> Pre-existing, GIC has AST2700_MAX_IRQ + GIC_INTERNAL IRQs, ...
>
> >
> > redist_region_count = qlist_new();
> > qlist_append_int(redist_region_count, sc->num_cpus); @@ -417,8
> > +417,7 @@ static bool aspeed_soc_ast2700_gic_realize(DeviceState *dev,
> > Error **errp)
> >
> > for (i = 0; i < sc->num_cpus; i++) {
> > DeviceState *cpudev = DEVICE(&a->cpu[i]);
> > -int NUM_IRQS = 256;
> > -int intidbase = NUM_IRQS + i * GIC_INTERNAL;
> > +int intidbase = AST2700_MAX_IRQ + i * GIC_INTERNAL;
>
> ... then our base IRQ starts at AST2700_MAX_IRQ + i * GIC_INTERNAL, having i
> = [0..3]. Jamin, is that correct?
>
Correct.
The value of "i" is 0 to 3 and the value of intidbase is 256, 288, 320 and 352.
> >
> > const int timer_irq[] = {
> > [GTIMER_PHYS] = ARCH_TIMER_NS_EL1_IRQ,
Re: [PATCH v7 10/10] docs/system: virtio-gpu: Document host/guest requirements
On 2025/02/03 8:21, Dmitry Osipenko wrote: From: Alex Bennée This attempts to tidy up the VirtIO GPU documentation to make the list of requirements clearer. There are still a lot of moving parts and the distros have some catching up to do before this is all handled automatically. Signed-off-by: Alex Bennée Cc: Sergio Lopez Pascual Signed-off-by: Dmitry Osipenko [dmitry.osipe...@collabora.com: Extended and corrected doc] --- docs/system/devices/virtio-gpu.rst | 92 +- 1 file changed, 91 insertions(+), 1 deletion(-) diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst index ea3eb052df3c..56950a76aa2e 100644 --- a/docs/system/devices/virtio-gpu.rst +++ b/docs/system/devices/virtio-gpu.rst @@ -5,7 +5,9 @@ virtio-gpu == This document explains the setup and usage of the virtio-gpu device. -The virtio-gpu device paravirtualizes the GPU and display controller. +The virtio-gpu device provides a GPU and display controller +paravirtualized using VirtIO. It supports a number of different modes +from simple 2D displays to fully accelerated 3D graphics. Linux kernel support @@ -56,6 +58,17 @@ on typical modern Linux distributions. .. _Mesa: https://www.mesa3d.org/ .. _SwiftShader: https://github.com/google/swiftshader +3D acceleration +--- + +3D acceleration of a virtualized GPU is still an evolving field. +Depending on the 3D mode you are running you may need to override +distribution supplied libraries with more recent versions or enable +build options. There are a number of requirements the host must meet +to be able to be able to support guests. QEMU must be able to access the +host's GPU and for the best performance be able to reliably share GPU +memory with the guest. + What about having a bigger section for "host requirements" that includes the "Linux kernel support" and "3D acceleration" section? Also it's better to note that the details of 3D acceleration requirements are described later as this section only contains an abstract description. virtio-gpu virglrenderer @@ -94,6 +107,61 @@ of virtio-gpu host memory window. This is typically between 256M and 8G. .. _drm: https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm +.. list-table:: Linux Host Requirements + :header-rows: 1 + + * - Mode "Mode" is not a word used elsewhere. Perhaps you may call it "capability". +- Kernel +- libvirglrenderer build flags Just "virglrenderer" for consistency. + * - OpenGL pass-through +- Linux any stable version QEMU's support policy is different from Linux's own idea of stable releases. Perhaps you may refer to any Linux version compatible with QEMU. +- N/A + * - Vulkan pass-through +- Linux 6.13+ +- -Dvenus=true -Drender-server=true + * - AMDGPU DRM native context +- Linux 6.13+ +- -Ddrm-renderers=amdgpu-experimental + * - Freedreno DRM native context +- Linux 6.4+ +- -Ddrm-renderers=msm + * - Intel i915 DRM native context +- Linux 6.13+ +- -Ddrm-renderers=i915-experimental `mr1384`_ + * - Asahi DRM native context +- Linux 6.13+ Asahi does not need patches for virglrenderer but requires patches for the kernel too as the upstream kernel doesn't have the GPU support at all. +- -Ddrm-renderers=asahi-experimental `mr1274`_ + +.. _mr1384: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 +.. _mr1274: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274 + +.. list-table:: Linux Guest Requirements + :header-rows: 1 + + * - Mode +- Mesa Version +- Mesa build flags + * - OpenGL pass-through +- 16.0.0+ +- -Dgallium-drivers=virgl + * - Vulkan pass-through +- 24.2.0+ +- -Dvulkan-drivers=virtio + * - AMDGPU DRM native context +- 25.0.0+ +- -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true + * - Freedreno DRM native context +- 23.1.0+ +- -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno + * - Intel i915 DRM native context +- `mr29870`_ +- -Dgallium-drivers=iris -Dvulkan-drivers=intel -Dintel-virtio-experimental=true + * - Asahi DRM native context +- 24.2.0+ +- -Dgallium-drivers=asahi -Dvulkan-drivers=asahi + +.. _mr29870: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 + virtio-gpu rutabaga --- @@ -133,3 +201,25 @@ Surfaceless is the default if ``wsi`` is not specified. .. _Wayland display passthrough: https://www.youtube.com/watch?v=OZJiHMtIQ2M .. _gfxstream-enabled rutabaga: https://crosvm.dev/book/appendix/rutabaga_gfx.html .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html + +.. list-table:: Linux Host Requirements + :header-rows: 1 + + * - Mode +- Kernel +- Userspace + * - rutabaga-gfxstream This notation is not consistent with the table for vi
Re: [PATCH v7 08/10] docs/system: virtio-gpu: Add link to Mesa VirGL doc
On 2025/02/03 8:21, Dmitry Osipenko wrote: Extend virtio-gpu documentation with a link to the Mesa VirGL documentation. Suggested-by: Akihiko Odaki Signed-off-by: Dmitry Osipenko --- docs/system/devices/virtio-gpu.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst index f20c60016376..f8963c1f13cf 100644 --- a/docs/system/devices/virtio-gpu.rst +++ b/docs/system/devices/virtio-gpu.rst @@ -59,7 +59,7 @@ on typical modern Linux distributions. virtio-gpu virglrenderer -When using virgl accelerated graphics mode in the guest, OpenGL API calls +When using `virgl`_ accelerated graphics mode in the guest, OpenGL API calls are translated into an intermediate representation (see `Gallium3D`_). The intermediate representation is communicated to the host and the `virglrenderer`_ library on the host translates the intermediate @@ -68,6 +68,7 @@ representation back to OpenGL API calls. .. parsed-literal:: -device virtio-gpu-gl +.. _virgl: https://docs.mesa3d.org/drivers/virgl.html .. _Gallium3D: https://www.freedesktop.org/wiki/Software/gallium/ .. _virglrenderer: https://gitlab.freedesktop.org/virgl/virglrenderer/ Reviewed-by: Akihiko Odaki
Re: [PATCH v7 09/10] docs/system: virtio-gpu: Update Venus link
On 2025/02/03 8:21, Dmitry Osipenko wrote: Change virtio-gpu Venus link, pointing it at the Mesa Venus documentation instead of the protocol. The Mesa doc provides more information and also has a link to the protocol. Suggested-by: Akihiko Odaki Signed-off-by: Dmitry Osipenko Reviewed-by: Akihiko Odaki
[PATCH v2 1/1] target/riscv: log guest errors when reserved bits are set in PTEs
For instance, QEMUs newer than b6ecc63c569bb88c0fcadf79fb92bf4b88aefea8
would silently treat this akin to an unmapped page (as required by the
RISC-V spec, admittedly). However, not all hardware platforms do (e.g.
CVA6) which leads to an apparent QEMU bug.
Instead, log a guest error so that in future, incorrectly set up page
tables can be debugged without bisecting QEMU.
Signed-off-by: julia
---
target/riscv/cpu_helper.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index e1dfc4ecbf..3dd8e06044 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1226,14 +1226,27 @@ restart:
ppn = pte >> PTE_PPN_SHIFT;
} else {
if (pte & PTE_RESERVED) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: reserved bits set in PTE: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x" TARGET_FMT_lx
"\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
if (!pbmte && (pte & PTE_PBMT)) {
+/* Reserved without Svpbmt. */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: PBMT bits set in PTE, "
+ "and Svpbmt extension is disabled: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x" TARGET_FMT_lx
"\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
if (!riscv_cpu_cfg(env)->ext_svnapot && (pte & PTE_N)) {
+/* Reserved without Svnapot extension */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: N bit set in PTE, "
+ "and Svnapot extension is disabled: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x" TARGET_FMT_lx
"\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
@@ -1244,14 +1257,19 @@ restart:
/* Invalid PTE */
return TRANSLATE_FAIL;
}
+
if (pte & (PTE_R | PTE_W | PTE_X)) {
goto leaf;
}
-/* Inner PTE, continue walking */
if (pte & (PTE_D | PTE_A | PTE_U | PTE_ATTR)) {
+/* D, A, and U bits are reserved in non-leaf/inner PTEs */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: D, A, or U bits set in
non-leaf PTE: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x" TARGET_FMT_lx
"\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
+/* Inner PTE, continue walking */
base = ppn << PGSHIFT;
}
@@ -1261,10 +1279,17 @@ restart:
leaf:
if (ppn & ((1ULL << ptshift) - 1)) {
/* Misaligned PPN */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: PPN bits in PTE is misaligned: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x" TARGET_FMT_lx "\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
if (!pbmte && (pte & PTE_PBMT)) {
/* Reserved without Svpbmt. */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: PBMT bits set in PTE, "
+ "and Svpbmt extension is disabled: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x" TARGET_FMT_lx "\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
--
2.47.0
Re: [PATCH 20/21] hw/i2c: Import TCA6416 emulation from Xilinx
On 1/2/25 16:28, Bernhard Beschow wrote:
Am 30. Januar 2025 23:05:53 UTC schrieb "Philippe Mathieu-Daudé"
:
Cc'ing AMD folks
Hi Bernhard,
TL;DR; can't you use the PCF8574 which is a more complete model of I/O
expander? (See hw/gpio/pcf8574.c)
If it is software-compatible then I could use it. I'm modeling a real board
whose device tree I'd like to use unchanged, so I don't have much choice. The
only reason I need it is because its absence clogs the i2c bus.
No clue about compatibility. If you unfortunately need to add it,
then please address my comments in the next version.
Best regards,
Bernhard
On 20/1/25 21:37, Bernhard Beschow wrote:
Xilinx QEMU implements a TCA6416 device model which may be useful for the
broader QEMU community, so upstream it. In the Xilinx fork, the device model
gets compiled whenever CONFIG_CADENCE is true, so have it maintained by the
"hw/*/cadence_*" maintainers.
The code is based on Xilinx QEMU version xilinx_v2024.2 plus the following
modifications:
* Use OBJECT_DECLARE_SIMPLE_TYPE()
* Port from DPRINTF() to trace events
* Follow QEMU conventions for naming of state struct
* Rename type to not contain a ','
* Use DEFINE_TYPES() macro
* Implement under hw/gpio since device is i2c client and gpio provider
* Have dedicated Kconfig switch
Signed-off-by: Bernhard Beschow
--
I have a use for TCA6416 emulation. Question: Are Xilinx Zynq maintainers
willing to maintain this device model?
---
MAINTAINERS | 1 +
hw/gpio/tca6416.c| 122 +++
hw/gpio/Kconfig | 5 ++
hw/gpio/meson.build | 1 +
hw/gpio/trace-events | 4 ++
5 files changed, 133 insertions(+)
create mode 100644 hw/gpio/tca6416.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7531d65429..0cac9c90bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1030,6 +1030,7 @@ S: Maintained
F: hw/*/xilinx_*
F: hw/*/cadence_*
F: hw/misc/zynq_slcr.c
+F: hw/gpio/tca6416.c
F: hw/adc/zynq-xadc.c
F: include/hw/misc/zynq_slcr.h
F: include/hw/adc/zynq-xadc.h
diff --git a/hw/gpio/tca6416.c b/hw/gpio/tca6416.c
new file mode 100644
index 00..81ed7a654d
--- /dev/null
+++ b/hw/gpio/tca6416.c
@@ -0,0 +1,122 @@
+/*
+ * QEMU model of TCA6416 16-Bit I/O Expander
Please add datasheet reference.
+ *
+ * Copyright (c) 2018 Xilinx Inc.
+ *
+ * Written by Sai Pavan Boddu
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
Sai/Edgar/Francisco, should we update to AMD here? Remove or update the
email address? Also, can you Ack the replacement of this license by a
SPDX tag?
+ */
+#include "qemu/osdep.h"
+#include "hw/i2c/i2c.h"
+#include "trace.h"
+
+#define TYPE_TCA6416 "tca6416"
+OBJECT_DECLARE_SIMPLE_TYPE(Tca6416State, TCA6416)
+
+#define IN_PORT00
+#define IN_PORT11
+#define OUT_PORT0 2
+#define OUT_PORT1 3
+#define POL_INV04
+#define POL_INV15
+#define CONF_PORT0 6
+#define CONF_PORT1 7
enum up to here?
+#define RMAX (CONF_PORT1 + 1)
+
+enum tca6416_events {
+ ADDR_DONE,
+ ADDRESSING,
+};
+
+struct Tca6416State {
+ I2CSlave i2c;
+
+ uint8_t addr;
+ uint8_t state;
+ uint8_t regs[RMAX];
+};
+
+static uint8_t tca6416_read(I2CSlave *i2c)
+{
+Tca6416State *s = TCA6416(i2c);
+uint8_t ret;
+
+ret = s->regs[s->addr];
+trace_tca6416_read(ret);
+return ret;
+}
+
+static int tca6416_write(I2CSlave *i2c, uint8_t data)
+{
+Tca6416State *s = TCA6416(i2c);
+
+trace_tca6416_write(data);
+if (s->state == ADDRESSING) {
+s->addr = data;
I suppose HW masks here.
s->addr = data & 0xf;
+} else {
+s->regs[s->addr] = data;
(otherwise this could overflow).
So this device isn't doing anything actually (I'd have
expected 1 IRQ and 16 GPIO lines). What is the point,
at least in this state?
+}
+
+return 0;
+}
+
+static void tca6416_realize(DeviceState *dev, Error **errp)
+{
+Tca6416State *s = TCA641
Re: [PATCH v2 37/69] target/arm: Handle FPCR.AH in negation steps in SVE FCADD
On 2/1/25 08:39, Peter Maydell wrote: The negation steps in FCADD must honour FPCR.AH's "don't change the sign of a NaN" semantics. Implement this in the same way we did for the base ASIMD FCADD, by encoding FPCR.AH into the SIMD data field passed to the helper and using that to decide whether to negate the values. The construction of neg_imag and neg_real were done to make it easy to apply both in parallel with two simple logical operations. This changed with FPCR.AH, which is more complex than that. Switch to an approach that follows the pseudocode more closely, by extracting the 'rot=1' parameter from the SIMD data field and changing the sign of the appropriate input value. Note that there was a naming issue with neg_imag and neg_real. They were named backward, with neg_imag being non-zero for rot=1, and vice versa. This was combined with reversed usage within the loop, so that the negation in the end turned out correct. Signed-off-by: Peter Maydell --- v2: Squashed in changes from RTH's patchset --- target/arm/tcg/vec_internal.h | 17 ++ target/arm/tcg/sve_helper.c| 42 -- target/arm/tcg/translate-sve.c | 2 +- 3 files changed, 48 insertions(+), 13 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH 0/2] net: Fix announce_self with vhost
Le 01/02/2025 à 20:36, Michael Tokarev a écrit :
17.01.2025 17:05, Laurent Vivier wrote:
CC: qemu-stable and qemu-trivial.
On 17/01/2025 12:17, Laurent Vivier wrote:
announce_self that sends a RARP packet after migration
or with announce_self QMP/HMP command doesn't work with
vhost because of the vnet headers.
announce_self is the only user of QEMU_NET_PACKET_FLAG_RAW and
this flag is not correctly managed.
This series fix a problem with this flag in filter-dump and in
qemu_deliver_packet_iov().
Laurent Vivier (2):
net: Fix announce_self
net/dump: Correctly compute Ethernet packet offset
Is this one - "Correctly compute Ethernet packet offset" - needed for
older stable series too, like 8.2 and 7.2 (currently active ones)?
Since it doesn't apply without 4b52d63249 (tap: Remove qemu_using_vnet_hdr()).
It fixes 481c52320a26 ("net: Strip virtio-net header when dumping") that is
only in 8.0.
But I'm not sure the bug exists without 4b52d63249 (tap: Remove qemu_using_vnet_hdr()), so it should
be tested first.
Thanks,
Laurent
Re: [PATCH v4 09/33] migration: postcopy_ram_listen_thread() needs to take BQL for some calls
On 2.02.2025 03:06, Dr. David Alan Gilbert wrote: * Maciej S. Szmigiero (m...@maciej.szmigiero.name) wrote: From: "Maciej S. Szmigiero" postcopy_ram_listen_thread() is a free running thread, so it needs to take BQL around function calls to migration methods requiring BQL. qemu_loadvm_state_main() needs BQL held since it ultimately calls "load_state" SaveVMHandlers. migration_incoming_state_destroy() needs BQL held since it ultimately calls "load_cleanup" SaveVMHandlers. Signed-off-by: Maciej S. Szmigiero --- migration/savevm.c | 4 1 file changed, 4 insertions(+) diff --git a/migration/savevm.c b/migration/savevm.c index b0b74140daea..0ceea9638cc1 100644 --- a/migration/savevm.c +++ b/migration/savevm.c @@ -2013,7 +2013,9 @@ static void *postcopy_ram_listen_thread(void *opaque) * in qemu_file, and thus we must be blocking now. */ qemu_file_set_blocking(f, true); +bql_lock(); load_res = qemu_loadvm_state_main(f, mis); +bql_unlock(); Doesn't that leave that held for a heck of a long time? Yes, and it effectively broke "postcopy recover" test but I think the reason for that is qemu_loadvm_state_main() and its children don't drop BQL while waiting for I/O. I've described this case in more detail in my reply to Fabiano here: https://lore.kernel.org/qemu-devel/0a09e627-955e-4f26-8d08-0192ecd25...@maciej.szmigiero.name/ I still think that "load_state" SaveVMHandlers need to be called with BQL held since implementations apparently expect it that way: for example, I think PCI device configuration restore calls address space manipulation methods which abort() if called without BQL held. I have previously even submitted a patch to explicitly document "load_state" SaveVMHandler as requiring BQL (which was also included in the previous version of this patch set) and it received a "Reviewed-by:" tag: https://lore.kernel.org/qemu-devel/6976f129df610c8207da4e531c8c0475ec204fa4.1730203967.git.maciej.szmigi...@oracle.com/ https://lore.kernel.org/qemu-devel/e1949839932efaa531e2fe63ac13324e5787439c.1731773021.git.maciej.szmigi...@oracle.com/ https://lore.kernel.org/qemu-devel/87o732bti7@suse.de/ It's also worth noting that COLO equivalent of postcopy incoming thread (colo_process_incoming_thread()) explicitly takes BQL around qemu_loadvm_state_main(): bql_lock(); cpu_synchronize_all_states(); ret = qemu_loadvm_state_main(mis->from_src_file, mis); bql_unlock(); That RAM loading has to happen in parallel with the loading of devices doesn't it - especially if one of the devices being loaded touches RAM. (I wish this series had a description in the cover letter!) I guess you mean "more detailed description" since there's a paragraph about this patch in this series cover letter change log: * postcopy_ram_listen_thread() now takes BQL around function calls that ultimately call migration methods requiring BQL. This fixes one of QEMU tests failing when explicitly BQL-sensitive code is added later to these methods. Dave Thanks, Maciej
Re: [PATCH v2 3/5] vfio/igd: refactor vfio_probe_igd_bar4_quirk() into pci config quirk
On 1/31/25 17:14, Cédric Le Goater wrote:
> Hello Tomita,
>
> On 1/24/25 20:12, Tomita Moeko wrote:
>> The actual IO BAR4 write quirk in vfio_probe_igd_bar4_quirk() was
>> removed in previous change, leaving the function not matching its name,
>> so move it into the newly introduced vfio_config_quirk_setup(). There
>> is no functional change in this commit. If any failure occurs, the
>> function simply returns and proceeds.
>>
>> Signed-off-by: Tomita Moeko
>> ---
>> hw/vfio/igd.c | 31 +--
>> hw/vfio/pci-quirks.c | 6 +-
>> hw/vfio/pci.h | 2 +-
>> 3 files changed, 23 insertions(+), 16 deletions(-)
>>
>> diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c
>> index ca3a32f4f2..376a26fbae 100644
>> --- a/hw/vfio/igd.c
>> +++ b/hw/vfio/igd.c
>> @@ -359,7 +359,8 @@ void vfio_probe_igd_bar0_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> QLIST_INSERT_HEAD(&vdev->bars[nr].quirks, bdsm_quirk, next);
>> }
>> -void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr)
>> +bool vfio_probe_igd_config_quirk(VFIOPCIDevice *vdev,
>> + Error **errp G_GNUC_UNUSED)
>
> Adding an 'Error **' parameter is in improvement indeed. All the error_report
> of this routine need to be converted too.
Sorry I missed this mail previously.
Originally this function simply return and continue on error, I prefer
keeping current behavior until legacy mode was finally removed, as I
described in my reply to Alex. At that point, this function will
terminate and report on error.
>> {
>> g_autofree struct vfio_region_info *rom = NULL;
>> g_autofree struct vfio_region_info *opregion = NULL;
>> @@ -378,10 +379,10 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev,
>> int nr)
>> * PCI bus address.
>> */
>> if (!vfio_pci_is(vdev, PCI_VENDOR_ID_INTEL, PCI_ANY_ID) ||
>> - !vfio_is_vga(vdev) || nr != 4 ||
>> + !vfio_is_vga(vdev) ||
>> &vdev->pdev != pci_find_device(pci_device_root_bus(&vdev->pdev),
>> 0, PCI_DEVFN(0x2, 0))) {
>> - return;
>> + return true;
>> }
>> /*
>> @@ -395,7 +396,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> "vfio-pci-igd-lpc-bridge")) {
>> error_report("IGD device %s cannot support legacy mode due to
>> existing "
>> "devices at address 1f.0", vdev->vbasedev.name);
>> - return;
>> + return true;
>
> if there is an error_report, why is this returning true ? It should be false.
Please see my comment above
>> }
>> /*
>> @@ -407,7 +408,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> if (gen == -1) {
>> error_report("IGD device %s is unsupported in legacy mode, "
>> "try SandyBridge or newer", vdev->vbasedev.name);
>> - return;
>> + return true;
>
> same here and else where.
>
>> }
>> /*
>> @@ -420,7 +421,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> if ((ret || !rom->size) && !vdev->pdev.romfile) {
>> error_report("IGD device %s has no ROM, legacy mode disabled",
>> vdev->vbasedev.name);
>> - return;
>> + return true;
>> }
>> /*
>> @@ -431,7 +432,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> error_report("IGD device %s hotplugged, ROM disabled, "
>> "legacy mode disabled", vdev->vbasedev.name);
>> vdev->rom_read_failed = true;
>> - return;
>> + return true;
>> }
>> /*
>> @@ -444,7 +445,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> if (ret) {
>> error_report("IGD device %s does not support OpRegion access,"
>> "legacy mode disabled", vdev->vbasedev.name);
>> - return;
>> + return true;
>> }
>> ret = vfio_get_dev_region_info(&vdev->vbasedev,
>> @@ -453,7 +454,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> if (ret) {
>> error_report("IGD device %s does not support host bridge access,"
>> "legacy mode disabled", vdev->vbasedev.name);
>> - return;
>> + return true;
>> }
>> ret = vfio_get_dev_region_info(&vdev->vbasedev,
>> @@ -462,7 +463,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> if (ret) {
>> error_report("IGD device %s does not support LPC bridge access,"
>> "legacy mode disabled", vdev->vbasedev.name);
>> - return;
>> + return true;
>> }
>> gmch = vfio_pci_read_config(&vdev->pdev, IGD_GMCH, 4);
>> @@ -476,7 +477,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int
>> nr)
>> error_reportf_err(err, VFIO_MSG_PREFIX,
[PATCH] linux-user/riscv: Disable unsupported SA_RESTORER
Linux on riscv does not support SA_RESTORER. Currently QEMU thinks there is a field 'sa_restorer' in the middle of 'struct sigaction' which does not actually exist. This leads to corrupted data and out-of-bounds accesses. Signed-off-by: Thomas Weißschuh --- linux-user/riscv/target_signal.h | 1 + 1 file changed, 1 insertion(+) diff --git a/linux-user/riscv/target_signal.h b/linux-user/riscv/target_signal.h index 6c0470f0bc82c6330ce50cb662f2039cf1fab288..258945770b674c0b6b66a94659d9c93fbabffdfb 100644 --- a/linux-user/riscv/target_signal.h +++ b/linux-user/riscv/target_signal.h @@ -4,5 +4,6 @@ #include "../generic/signal.h" #define TARGET_ARCH_HAS_SIGTRAMP_PAGE 1 +#undef TARGET_SA_RESTORER #endif /* RISCV_TARGET_SIGNAL_H */ --- base-commit: 6fccaa2fba391815308a746d68f7fa197bc93586 change-id: 20250202-riscv-sa-restorer-edd3dfa7790f Best regards, -- Thomas Weißschuh
[PATCH v7 00/10] Support virtio-gpu DRM native context
This patchset adds DRM native context support to VirtIO-GPU on Qemu. Contarary to Virgl and Venus contexts that mediates high level GFX APIs, DRM native context [1] mediates lower level kernel driver UAPI, which reflects in a less CPU overhead and less/simpler code needed to support it. DRM context consists of a host and guest parts that have to be implemented for each GPU driver. On a guest side, DRM context presents a virtual GPU as a real/native host GPU device for GL/VK applications. [1] https://www.youtube.com/watch?v=9sFP_yddLLQ Today there are four DRM native context drivers existing in a wild: - Freedreno (Qualcomm SoC GPUs), completely upstreamed - AMDGPU, completely upstreamed - Intel (i915), merge requests are opened - Asahi (Apple SoC GPUs), partially merged upstream # How to try out DRM context: 1. DRM context uses host blobs and on host requires latest 6.13 version of Linux kernel that contains necessary KVM fixes. 2. Use latest Mesa (both guest and host) and libvirglrenderer versions. Use build flags documented in tha patch #10 of this series. 3. On guest, use latest Linux kernel v6.14-rc or newer. Example Qemu cmdline that enables DRM context: qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=on,drm_native_context=on \ -machine q35,accel=kvm,memory-backend=mem1 \ -object memory-backend-memfd,id=mem1,size=8G -m 8G # Note about known performance problem in Qemu: DRM contexts are mapping host blobs extensively and these mapping operations work slowly in Qemu. Exact reason is unknown. Mappings work fast on Crosvm For DRM contexts this problem is more visible than for Venus/Virgl. Changelog: v7: - Added r-b from Alex Bennée to the async fencing patch. - Updated virtio-gpu doc patch with addressed review comments from Akihiko Odaki. v6: - Fixed compilation warning using older version of virglrenderer, which wasn't fixed properly in v5. - Added t-bs from Alex Bennée. - Added patches to improve virgl/venus doc by adding links to the Mesa doc as was suggested by Akihiko Odaki. - Updated patch that documents guest/host requirements. Added links to Asahi nctx and reworked the doc structure by adding requirements to each context-type section instead of having one big blob or requirements, which was objected by Akihiko Odaki. v5: - Added r-bs from Akihiko Odaki. - Added acks from Michael Tsirkin. - Fixed compilation warning using older version of virglrenderer that was reported by Alex Bennée. Noticed that I need to keep old virgl_write_fence() code around for the older virglrenderer in "Support asynchronous fencing" patch, so added it back and verified that old virglrenderer works properly. - Added new patch from Alex Bennée that adds more virtio-gpu documentation with a couple corrections and additions to it from me. - Rebased patches on top of latest staging tree. v4: - Improved SDL2/dmabuf patch by reusing existing Meson X11 config option, better handling EGL error and extending comment telling that it's safe to enable SDL2 EGL preference hint. As was suggested by Akihiko Odaki. - Replaced another QSLIST_FOREACH_SAFE with QSLIST_EMPTY+FIRST in the async-fencing patch for more consistency of the code. As was suggested by Akihiko Odaki. - Added missing braces around if-statement that was spotted by Alex Bennée. - Renamed 'drm=on' option of virtio-gpu-gl device to 'drm_native_context=on' for more clarity as was suggested by Alex Bennée. Haven't added added new context-type option that was also proposed by Alex, might do it with a separate patch. This context-type option will duplicate and depecate existing options, but in a longer run likely will be worthwhile adding it. - Dropped Linux headers-update patch as headers has been updated in the staging tree. v3: - Improved EGL presence-check code on X11 systems for the SDL2 hint that prefers EGL over GLX by using better ifdefs and checking Xlib presence at a build time to avoid build failure if lib SDL2 and system are configured with a disabled X11 support. Also added clarifying comment telling that X11 hint doesn't affect Wayland systems. Suggested by Akihiko Odaki. - Corrected strerror(err) that used negative error where it should be positive and vice versa that was caught by Akihiko Odaki. Added clarifying comment for the case where we get positive error code from virglrenderer that differs from other virglrenderer API functions. - Improved QSLIST usage by dropping mutex protecting the async fence list and using atomic variant of QSLIST helpers instead. Switched away from using FOREACH helper to improve readability of the code, showing that we don't precess list in unoptimal way. Like was suggested by Akihiko Odaki.
[PATCH v7 02/10] ui/sdl2: Implement dpy dmabuf functions
From: Pierre-Eric Pelloux-Prayer
If EGL is used, we can rely on dmabuf to import textures without
doing copies.
To get this working on X11, we use the existing SDL hint:
SDL_HINT_VIDEO_X11_FORCE_EGL (because dmabuf can't be used with GLX).
Reviewed-by: Akihiko Odaki
Acked-by: Michael S. Tsirkin
Tested-by: Alex Bennée
Signed-off-by: Pierre-Eric Pelloux-Prayer
Signed-off-by: Dmitry Osipenko
---
include/ui/sdl2.h | 7 ++
meson.build | 6 ++---
ui/sdl2-gl.c | 64 +++
ui/sdl2.c | 42 +++
4 files changed, 115 insertions(+), 4 deletions(-)
diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h
index dbe6e3d9739b..9daf5ecffae7 100644
--- a/include/ui/sdl2.h
+++ b/include/ui/sdl2.h
@@ -45,6 +45,7 @@ struct sdl2_console {
bool gui_keysym;
SDL_GLContext winctx;
QKbdState *kbd;
+bool has_dmabuf;
#ifdef CONFIG_OPENGL
QemuGLShader *gls;
egl_fb guest_fb;
@@ -96,5 +97,11 @@ void sdl2_gl_scanout_texture(DisplayChangeListener *dcl,
void *d3d_tex2d);
void sdl2_gl_scanout_flush(DisplayChangeListener *dcl,
uint32_t x, uint32_t y, uint32_t w, uint32_t h);
+void sdl2_gl_scanout_dmabuf(DisplayChangeListener *dcl,
+QemuDmaBuf *dmabuf);
+void sdl2_gl_release_dmabuf(DisplayChangeListener *dcl,
+QemuDmaBuf *dmabuf);
+bool sdl2_gl_has_dmabuf(DisplayChangeListener *dcl);
+void sdl2_gl_console_init(struct sdl2_console *scon);
#endif /* SDL2_H */
diff --git a/meson.build b/meson.build
index 2c9ac9cfe1e9..dce01783ccf3 100644
--- a/meson.build
+++ b/meson.build
@@ -1964,10 +1964,8 @@ if get_option('gtk') \
endif
endif
-x11 = not_found
-if gtkx11.found()
- x11 = dependency('x11', method: 'pkg-config', required: gtkx11.found())
-endif
+x11 = dependency('x11', method: 'pkg-config', required: gtkx11.found())
+
png = not_found
if get_option('png').allowed() and have_system
png = dependency('libpng', version: '>=1.6.34', required: get_option('png'),
diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c
index b1fe96d6af22..8d53e340d40d 100644
--- a/ui/sdl2-gl.c
+++ b/ui/sdl2-gl.c
@@ -26,6 +26,8 @@
*/
#include "qemu/osdep.h"
+#include "qemu/main-loop.h"
+#include "qemu/error-report.h"
#include "ui/console.h"
#include "ui/input.h"
#include "ui/sdl2.h"
@@ -249,3 +251,65 @@ void sdl2_gl_scanout_flush(DisplayChangeListener *dcl,
SDL_GL_SwapWindow(scon->real_window);
}
+
+void sdl2_gl_scanout_dmabuf(DisplayChangeListener *dcl,
+QemuDmaBuf *dmabuf)
+{
+struct sdl2_console *scon = container_of(dcl, struct sdl2_console, dcl);
+
+assert(scon->opengl);
+SDL_GL_MakeCurrent(scon->real_window, scon->winctx);
+
+egl_dmabuf_import_texture(dmabuf);
+if (!qemu_dmabuf_get_texture(dmabuf)) {
+error_report("%s: failed fd=%d", __func__, qemu_dmabuf_get_fd(dmabuf));
+return;
+}
+
+sdl2_gl_scanout_texture(dcl, qemu_dmabuf_get_texture(dmabuf), false,
+qemu_dmabuf_get_width(dmabuf),
+qemu_dmabuf_get_height(dmabuf),
+0, 0,
+qemu_dmabuf_get_width(dmabuf),
+qemu_dmabuf_get_height(dmabuf),
+NULL);
+
+if (qemu_dmabuf_get_allow_fences(dmabuf)) {
+scon->guest_fb.dmabuf = dmabuf;
+}
+}
+
+void sdl2_gl_release_dmabuf(DisplayChangeListener *dcl,
+QemuDmaBuf *dmabuf)
+{
+egl_dmabuf_release_texture(dmabuf);
+}
+
+bool sdl2_gl_has_dmabuf(DisplayChangeListener *dcl)
+{
+struct sdl2_console *scon = container_of(dcl, struct sdl2_console, dcl);
+
+return scon->has_dmabuf;
+}
+
+void sdl2_gl_console_init(struct sdl2_console *scon)
+{
+bool hidden = scon->hidden;
+
+scon->hidden = true;
+scon->surface = qemu_create_displaysurface(1, 1);
+sdl2_window_create(scon);
+
+/*
+ * QEMU checks whether console supports dma-buf before switching
+ * to the console. To break this chicken-egg problem we pre-check
+ * dma-buf availability beforehand using a dummy SDL window.
+ */
+scon->has_dmabuf = qemu_egl_has_dmabuf();
+
+sdl2_window_destroy(scon);
+qemu_free_displaysurface(scon->surface);
+
+scon->surface = NULL;
+scon->hidden = hidden;
+}
diff --git a/ui/sdl2.c b/ui/sdl2.c
index 445eb1dd9f9a..3e262b994231 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -36,6 +36,10 @@
#include "qemu/log.h"
#include "qemu-main.h"
+#ifdef CONFIG_X11
+#include
+#endif
+
static int sdl2_num_outputs;
static struct sdl2_console *sdl2_console;
@@ -121,6 +125,9 @@ void sdl2_window_create(struct sdl2_console *scon)
/* The SDL renderer is only used by sdl2-2D, when OpenGL is disabled */
scon->real_renderer = SDL_CreateRenderer(scon->real_window, -1, 0);
}
+
+qemu_egl_display = eglGetCurre
[PATCH v7 09/10] docs/system: virtio-gpu: Update Venus link
Change virtio-gpu Venus link, pointing it at the Mesa Venus
documentation instead of the protocol. The Mesa doc provides more
information and also has a link to the protocol.
Suggested-by: Akihiko Odaki
Signed-off-by: Dmitry Osipenko
---
docs/system/devices/virtio-gpu.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/system/devices/virtio-gpu.rst
b/docs/system/devices/virtio-gpu.rst
index f8963c1f13cf..ea3eb052df3c 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -81,7 +81,7 @@ of virtio-gpu host memory window. This is typically between
256M and 8G.
.. parsed-literal::
-device virtio-gpu-gl,hostmem=8G,blob=true,venus=true
-.. _venus: https://gitlab.freedesktop.org/virgl/venus-protocol/
+.. _venus: https://docs.mesa3d.org/drivers/venus.html
DRM native context is supported since release of `virglrenderer`_ v1.0.0
using `drm`_ protocol. ``DRM`` virtio-gpu capability set ("capset") requires
--
2.47.1
[PATCH v7 01/10] ui/sdl2: Restore original context after new context creation
SDL API changes GL context to a newly created GL context, which differs from other GL providers that don't switch context. Change SDL backend to restore the original GL context. This allows Qemu's virtio-gpu to support new virglrenderer async-fencing feature for Virgl contexts, otherwise virglrenderer's vrend creates a fence-sync context on the Qemu's main-loop thread that erroneously stays in-use by the main-loop after creation, not allowing vrend's fence-sync thread switch to this new context that belongs to it. Reviewed-by: Akihiko Odaki Acked-by: Michael S. Tsirkin Tested-by: Alex Bennée Signed-off-by: Dmitry Osipenko --- ui/sdl2-gl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c index e01d9ab0c7bf..b1fe96d6af22 100644 --- a/ui/sdl2-gl.c +++ b/ui/sdl2-gl.c @@ -168,6 +168,9 @@ QEMUGLContext sdl2_gl_create_context(DisplayGLCtx *dgc, SDL_GL_CONTEXT_PROFILE_ES); ctx = SDL_GL_CreateContext(scon->real_window); } + +SDL_GL_MakeCurrent(scon->real_window, scon->winctx); + return (QEMUGLContext)ctx; } -- 2.47.1
[PATCH v7 08/10] docs/system: virtio-gpu: Add link to Mesa VirGL doc
Extend virtio-gpu documentation with a link to the Mesa VirGL documentation. Suggested-by: Akihiko Odaki Signed-off-by: Dmitry Osipenko --- docs/system/devices/virtio-gpu.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst index f20c60016376..f8963c1f13cf 100644 --- a/docs/system/devices/virtio-gpu.rst +++ b/docs/system/devices/virtio-gpu.rst @@ -59,7 +59,7 @@ on typical modern Linux distributions. virtio-gpu virglrenderer -When using virgl accelerated graphics mode in the guest, OpenGL API calls +When using `virgl`_ accelerated graphics mode in the guest, OpenGL API calls are translated into an intermediate representation (see `Gallium3D`_). The intermediate representation is communicated to the host and the `virglrenderer`_ library on the host translates the intermediate @@ -68,6 +68,7 @@ representation back to OpenGL API calls. .. parsed-literal:: -device virtio-gpu-gl +.. _virgl: https://docs.mesa3d.org/drivers/virgl.html .. _Gallium3D: https://www.freedesktop.org/wiki/Software/gallium/ .. _virglrenderer: https://gitlab.freedesktop.org/virgl/virglrenderer/ -- 2.47.1
[PATCH v7 04/10] virtio-gpu: Support asynchronous fencing
Support asynchronous fencing feature of virglrenderer. It allows Qemu to
handle fence as soon as it's signalled instead of periodically polling
the fence status. This feature is required for enabling DRM context
support in Qemu because legacy fencing mode isn't supported for DRM
contexts in virglrenderer.
Reviewed-by: Akihiko Odaki
Acked-by: Michael S. Tsirkin
Tested-by: Alex Bennée
Reviewed-by: Alex Bennée
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-gl.c | 3 +
hw/display/virtio-gpu-virgl.c | 147 +++--
include/hw/virtio/virtio-gpu.h | 13 +++
3 files changed, 154 insertions(+), 9 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index 683fad3bf8a8..d9bb50ac1d4a 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -169,6 +169,9 @@ static void virtio_gpu_gl_device_unrealize(DeviceState
*qdev)
if (gl->renderer_state >= RS_INITED) {
#if VIRGL_VERSION_MAJOR >= 1
qemu_bh_delete(gl->cmdq_resume_bh);
+
+virtio_gpu_virgl_reset_async_fences(g);
+qemu_bh_delete(gl->async_fence_bh);
#endif
if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
timer_free(gl->print_stats);
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 2eb6aaab4e84..ee896eced67c 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -871,6 +871,7 @@ static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
+VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
bool cmd_suspended = false;
int ret;
@@ -972,15 +973,34 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
-/*
- * Unlike other virglrenderer functions, this one returns a positive
- * error code.
- */
-ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0);
-if (ret) {
-qemu_log_mask(LOG_GUEST_ERROR,
- "%s: virgl_renderer_create_fence error: %s",
- __func__, strerror(ret));
+if (gl->context_fence_enabled &&
+(cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX)) {
+#if VIRGL_VERSION_MAJOR >= 1
+uint32_t flags = 0;
+
+ret = virgl_renderer_context_create_fence(cmd->cmd_hdr.ctx_id, flags,
+ cmd->cmd_hdr.ring_idx,
+ cmd->cmd_hdr.fence_id);
+if (ret) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: virgl_renderer_context_create_fence error: %s",
+ __func__, strerror(-ret));
+}
+#else
+/* gl->context_fence_enabled cannot be set with older virglrenderer */
+g_assert_not_reached();
+#endif
+} else {
+/*
+ * Unlike other virglrenderer functions, this one returns a positive
+ * error code.
+ */
+ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0);
+if (ret) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: virgl_renderer_create_fence error: %s",
+ __func__, strerror(ret));
+}
}
}
@@ -1008,6 +1028,102 @@ static void virgl_write_fence(void *opaque, uint32_t
fence)
}
}
+void virtio_gpu_virgl_reset_async_fences(VirtIOGPU *g)
+{
+struct virtio_gpu_virgl_context_fence *f;
+VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
+
+while (!QSLIST_EMPTY(&gl->async_fenceq)) {
+f = QSLIST_FIRST(&gl->async_fenceq);
+
+QSLIST_REMOVE_HEAD(&gl->async_fenceq, next);
+
+g_free(f);
+}
+}
+
+#if VIRGL_VERSION_MAJOR >= 1
+static void virtio_gpu_virgl_async_fence_bh(void *opaque)
+{
+QSLIST_HEAD(, virtio_gpu_virgl_context_fence) async_fenceq;
+struct virtio_gpu_ctrl_command *cmd, *tmp;
+struct virtio_gpu_virgl_context_fence *f;
+VirtIOGPU *g = opaque;
+VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
+
+QSLIST_MOVE_ATOMIC(&async_fenceq, &gl->async_fenceq);
+
+while (!QSLIST_EMPTY(&async_fenceq)) {
+f = QSLIST_FIRST(&async_fenceq);
+
+QSLIST_REMOVE_HEAD(&async_fenceq, next);
+
+QTAILQ_FOREACH_SAFE(cmd, &g->fenceq, next, tmp) {
+/*
+ * the guest can end up emitting fences out of order
+ * so we should check all fenced cmds not just the first one.
+ */
+if (cmd->cmd_hdr.fence_id > f->fence_id) {
+continue;
+}
+if (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX) {
+if (cmd->cmd_hdr.ring_idx != f->ring_idx) {
+continue;
+}
+if (cmd->cmd_hdr.ctx_id != f->ctx_id) {
+continue;
+}
+} else if (f->ring_idx >= 0) {
+
[PATCH v7 07/10] ui/gtk: Don't disable scanout when display is refreshed
Display refreshment is invoked by a timer and it erroneously disables
the active scanout if it happens to be invoked after scanout has been
enabled. This offending scanout-disable race condition with a timer
can be easily hit when Qemu runs with a disabled vsync by using SDL or
GTK displays (with vblank_mode=0 for GTK). Refreshment of display's
content shouldn't disable the active display. Fix it by keeping the
scanout's state unchanged when display is redrawn.
Reviewed-by: Akihiko Odaki
Acked-by: Michael S. Tsirkin
Tested-by: Alex Bennée
Signed-off-by: Dmitry Osipenko
---
ui/gtk-egl.c | 1 -
ui/gtk-gl-area.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index f7a428c86a8d..0d1547d63ad0 100644
--- a/ui/gtk-egl.c
+++ b/ui/gtk-egl.c
@@ -179,7 +179,6 @@ void gd_egl_refresh(DisplayChangeListener *dcl)
if (vc->gfx.glupdates) {
vc->gfx.glupdates = 0;
-gtk_egl_set_scanout_mode(vc, false);
gd_egl_draw(vc);
}
}
diff --git a/ui/gtk-gl-area.c b/ui/gtk-gl-area.c
index 2c9a0db42571..53d81124f211 100644
--- a/ui/gtk-gl-area.c
+++ b/ui/gtk-gl-area.c
@@ -148,7 +148,6 @@ void gd_gl_area_refresh(DisplayChangeListener *dcl)
if (vc->gfx.glupdates) {
vc->gfx.glupdates = 0;
-gtk_gl_area_set_scanout_mode(vc, false);
gtk_gl_area_queue_render(GTK_GL_AREA(vc->gfx.drawing_area));
}
}
--
2.47.1
[PATCH v7 05/10] virtio-gpu: Support DRM native context
Add support for DRM native contexts to VirtIO-GPU. DRM context is enabled
using a new virtio-gpu-gl device option "drm_native_context=on".
Unlike Virgl and Venus contexts that operate on application API level,
DRM native contexts work on a kernel UAPI level. This lower level results
in a lightweight context implementations that yield better performance.
Reviewed-by: Akihiko Odaki
Acked-by: Michael S. Tsirkin
Tested-by: Alex Bennée
Signed-off-by: Dmitry Osipenko
---
docs/system/devices/virtio-gpu.rst | 11 +++
hw/display/virtio-gpu-gl.c | 2 ++
hw/display/virtio-gpu-virgl.c | 22 ++
hw/display/virtio-gpu.c| 15 +++
include/hw/virtio/virtio-gpu.h | 3 +++
5 files changed, 53 insertions(+)
diff --git a/docs/system/devices/virtio-gpu.rst
b/docs/system/devices/virtio-gpu.rst
index b7eb0fc0e727..f20c60016376 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -82,6 +82,17 @@ of virtio-gpu host memory window. This is typically between
256M and 8G.
.. _venus: https://gitlab.freedesktop.org/virgl/venus-protocol/
+DRM native context is supported since release of `virglrenderer`_ v1.0.0
+using `drm`_ protocol. ``DRM`` virtio-gpu capability set ("capset") requires
+host blob support (``hostmem`` and ``blob`` fields) and should be enabled
+using ``drm_native_context`` field. The ``hostmem`` field specifies the size
+of virtio-gpu host memory window. This is typically between 256M and 8G.
+
+.. parsed-literal::
+-device virtio-gpu-gl,hostmem=8G,blob=on,drm_native_context=on
+
+.. _drm: https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm
+
virtio-gpu rutabaga
---
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index d9bb50ac1d4a..5f374ad56396 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -159,6 +159,8 @@ static const Property virtio_gpu_gl_properties[] = {
VIRTIO_GPU_FLAG_STATS_ENABLED, false),
DEFINE_PROP_BIT("venus", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_VENUS_ENABLED, false),
+DEFINE_PROP_BIT("drm_native_context", VirtIOGPU, parent_obj.conf.flags,
+VIRTIO_GPU_FLAG_DRM_ENABLED, false),
};
static void virtio_gpu_gl_device_unrealize(DeviceState *qdev)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index ee896eced67c..184ad2c588f7 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -1248,6 +1248,19 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
}
+if (virtio_gpu_drm_enabled(g->parent_obj.conf)) {
+flags |= VIRGL_RENDERER_DRM;
+
+if (!gl->context_fence_enabled) {
+/*
+ * Virglrenderer skips enabling DRM context support without
+ * enabled async-fence feature. VirtIO-GPU will initialize
+ * successfully, but DRM context won't be available in guest.
+ */
+error_report("DRM native context requires EGL display");
+return -EINVAL;
+}
+}
#endif
ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
@@ -1310,5 +1323,14 @@ GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g)
}
}
+if (virtio_gpu_drm_enabled(g->parent_obj.conf)) {
+virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_DRM,
+ &capset_max_ver,
+ &capset_max_size);
+if (capset_max_size) {
+virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_DRM);
+}
+}
+
return capset_ids;
}
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 11a7a8575027..165a0976480d 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1505,6 +1505,21 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
#endif
}
+if (virtio_gpu_drm_enabled(g->parent_obj.conf)) {
+#ifdef VIRGL_VERSION_MAJOR
+#if VIRGL_VERSION_MAJOR >= 1
+if (!virtio_gpu_blob_enabled(g->parent_obj.conf) ||
+!virtio_gpu_hostmem_enabled(g->parent_obj.conf)) {
+error_setg(errp, "drm requires enabled blob and hostmem options");
+return;
+}
+#else
+error_setg(errp, "old virglrenderer, drm unsupported");
+return;
+#endif
+#endif
+}
+
if (!virtio_gpu_base_device_realize(qdev,
virtio_gpu_handle_ctrl_cb,
virtio_gpu_handle_cursor_cb,
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index bd2cccdc60d7..dcdf52b192b5 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -99,6 +99,7 @@ enum virtio_gpu_base_conf_flags {
VIR
[PATCH v7 06/10] ui/sdl2: Don't disable scanout when display is refreshed
Display refreshment is invoked by a timer and it erroneously disables the active scanout if it happens to be invoked after scanout has been enabled. This offending scanout-disable race condition with a timer can be easily hit when Qemu runs with a disabled vsync by using SDL or GTK displays (with vblank_mode=0 for GTK). Refreshment of display's content shouldn't disable the active display. Fix it by keeping the scanout's state unchanged when display is redrawn. Reviewed-by: Akihiko Odaki Acked-by: Michael S. Tsirkin Tested-by: Alex Bennée Signed-off-by: Dmitry Osipenko --- ui/sdl2-gl.c | 1 - 1 file changed, 1 deletion(-) diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c index 8d53e340d40d..31f8fbe03286 100644 --- a/ui/sdl2-gl.c +++ b/ui/sdl2-gl.c @@ -53,7 +53,6 @@ static void sdl2_gl_render_surface(struct sdl2_console *scon) int ww, wh; SDL_GL_MakeCurrent(scon->real_window, scon->winctx); -sdl2_set_scanout_mode(scon, false); SDL_GetWindowSize(scon->real_window, &ww, &wh); surface_gl_setup_viewport(scon->gls, scon->surface, ww, wh); -- 2.47.1
[PATCH v7 10/10] docs/system: virtio-gpu: Document host/guest requirements
From: Alex Bennée This attempts to tidy up the VirtIO GPU documentation to make the list of requirements clearer. There are still a lot of moving parts and the distros have some catching up to do before this is all handled automatically. Signed-off-by: Alex Bennée Cc: Sergio Lopez Pascual Signed-off-by: Dmitry Osipenko [dmitry.osipe...@collabora.com: Extended and corrected doc] --- docs/system/devices/virtio-gpu.rst | 92 +- 1 file changed, 91 insertions(+), 1 deletion(-) diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst index ea3eb052df3c..56950a76aa2e 100644 --- a/docs/system/devices/virtio-gpu.rst +++ b/docs/system/devices/virtio-gpu.rst @@ -5,7 +5,9 @@ virtio-gpu == This document explains the setup and usage of the virtio-gpu device. -The virtio-gpu device paravirtualizes the GPU and display controller. +The virtio-gpu device provides a GPU and display controller +paravirtualized using VirtIO. It supports a number of different modes +from simple 2D displays to fully accelerated 3D graphics. Linux kernel support @@ -56,6 +58,17 @@ on typical modern Linux distributions. .. _Mesa: https://www.mesa3d.org/ .. _SwiftShader: https://github.com/google/swiftshader +3D acceleration +--- + +3D acceleration of a virtualized GPU is still an evolving field. +Depending on the 3D mode you are running you may need to override +distribution supplied libraries with more recent versions or enable +build options. There are a number of requirements the host must meet +to be able to be able to support guests. QEMU must be able to access the +host's GPU and for the best performance be able to reliably share GPU +memory with the guest. + virtio-gpu virglrenderer @@ -94,6 +107,61 @@ of virtio-gpu host memory window. This is typically between 256M and 8G. .. _drm: https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm +.. list-table:: Linux Host Requirements + :header-rows: 1 + + * - Mode +- Kernel +- libvirglrenderer build flags + * - OpenGL pass-through +- Linux any stable version +- N/A + * - Vulkan pass-through +- Linux 6.13+ +- -Dvenus=true -Drender-server=true + * - AMDGPU DRM native context +- Linux 6.13+ +- -Ddrm-renderers=amdgpu-experimental + * - Freedreno DRM native context +- Linux 6.4+ +- -Ddrm-renderers=msm + * - Intel i915 DRM native context +- Linux 6.13+ +- -Ddrm-renderers=i915-experimental `mr1384`_ + * - Asahi DRM native context +- Linux 6.13+ +- -Ddrm-renderers=asahi-experimental `mr1274`_ + +.. _mr1384: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 +.. _mr1274: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274 + +.. list-table:: Linux Guest Requirements + :header-rows: 1 + + * - Mode +- Mesa Version +- Mesa build flags + * - OpenGL pass-through +- 16.0.0+ +- -Dgallium-drivers=virgl + * - Vulkan pass-through +- 24.2.0+ +- -Dvulkan-drivers=virtio + * - AMDGPU DRM native context +- 25.0.0+ +- -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true + * - Freedreno DRM native context +- 23.1.0+ +- -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno + * - Intel i915 DRM native context +- `mr29870`_ +- -Dgallium-drivers=iris -Dvulkan-drivers=intel -Dintel-virtio-experimental=true + * - Asahi DRM native context +- 24.2.0+ +- -Dgallium-drivers=asahi -Dvulkan-drivers=asahi + +.. _mr29870: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 + virtio-gpu rutabaga --- @@ -133,3 +201,25 @@ Surfaceless is the default if ``wsi`` is not specified. .. _Wayland display passthrough: https://www.youtube.com/watch?v=OZJiHMtIQ2M .. _gfxstream-enabled rutabaga: https://crosvm.dev/book/appendix/rutabaga_gfx.html .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html + +.. list-table:: Linux Host Requirements + :header-rows: 1 + + * - Mode +- Kernel +- Userspace + * - rutabaga-gfxstream +- Linux 6.13+ +- rutabaga_gfx_ffi or vhost-user client with `gfxstream support`_ + +.. _gfxstream support: https://github.com/rust-vmm/vhost-device/tree/main/staging/vhost-device-gpu + +.. list-table:: Linux Guest Requirements + :header-rows: 1 + + * - Mode +- Mesa Version +- Mesa build flags + * - rutabaga-gfxstream +- 24.3.0+ +- -Dvulkan-drivers=gfxstream -- 2.47.1
Re: [PATCH v5 6/7] target/riscv: Add support to access ctrsource, ctrtarget, ctrdata regs.
On Thu, Dec 5, 2024 at 9:36 PM Rajnesh Kanwal wrote:
>
> CTR entries are accessed using ctrsource, ctrtarget and ctrdata
> registers using smcsrind/sscsrind extension. This commits extends
> the csrind extension to support CTR registers.
>
> ctrsource is accessible through xireg CSR, ctrtarget is accessible
> through xireg1 and ctrdata is accessible through xireg2 CSR.
>
> CTR supports maximum depth of 256 entries which are accessed using
> xiselect range 0x200 to 0x2ff.
>
> This commits also adds properties to enable CTR extension. CTR can be
> enabled using smctr=true and ssctr=true now.
>
> Signed-off-by: Rajnesh Kanwal
> ---
> target/riscv/cpu.c | 26 +++-
> target/riscv/csr.c | 150
> -
> target/riscv/tcg/tcg-cpu.c | 11
> 3 files changed, 185 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index
> 2a4f285a974ffc62e7f3e938691dbffe376a7e46..751029e924d4690aaa5de65456fd5a5ec25b916a
> 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -199,6 +199,8 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(sstvala, PRIV_VERSION_1_12_0, has_priv_1_12),
> ISA_EXT_DATA_ENTRY(sstvecd, PRIV_VERSION_1_12_0, has_priv_1_12),
> ISA_EXT_DATA_ENTRY(svade, PRIV_VERSION_1_11_0, ext_svade),
> +ISA_EXT_DATA_ENTRY(smctr, PRIV_VERSION_1_12_0, ext_smctr),
> +ISA_EXT_DATA_ENTRY(ssctr, PRIV_VERSION_1_12_0, ext_ssctr),
> ISA_EXT_DATA_ENTRY(svadu, PRIV_VERSION_1_12_0, ext_svadu),
> ISA_EXT_DATA_ENTRY(svinval, PRIV_VERSION_1_12_0, ext_svinval),
> ISA_EXT_DATA_ENTRY(svnapot, PRIV_VERSION_1_12_0, ext_svnapot),
> @@ -1481,6 +1483,8 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> MULTI_EXT_CFG_BOOL("smcdeleg", ext_smcdeleg, false),
> MULTI_EXT_CFG_BOOL("sscsrind", ext_sscsrind, false),
> MULTI_EXT_CFG_BOOL("ssccfg", ext_ssccfg, false),
> +MULTI_EXT_CFG_BOOL("smctr", ext_smctr, false),
> +MULTI_EXT_CFG_BOOL("ssctr", ext_ssctr, false),
This should be the very last patch (once everything is supported)
Otherwise
Acked-by: Alistair Francis
Alistair
> MULTI_EXT_CFG_BOOL("zifencei", ext_zifencei, true),
> MULTI_EXT_CFG_BOOL("zicfilp", ext_zicfilp, false),
> MULTI_EXT_CFG_BOOL("zicfiss", ext_zicfiss, false),
> @@ -2656,6 +2660,26 @@ static RISCVCPUImpliedExtsRule SSCFG_IMPLIED = {
> },
> };
>
> +static RISCVCPUImpliedExtsRule SMCTR_IMPLIED = {
> +.ext = CPU_CFG_OFFSET(ext_smctr),
> +.implied_misa_exts = RVS,
> +.implied_multi_exts = {
> +CPU_CFG_OFFSET(ext_sscsrind),
> +
> +RISCV_IMPLIED_EXTS_RULE_END
> +},
> +};
> +
> +static RISCVCPUImpliedExtsRule SSCTR_IMPLIED = {
> +.ext = CPU_CFG_OFFSET(ext_ssctr),
> +.implied_misa_exts = RVS,
> +.implied_multi_exts = {
> +CPU_CFG_OFFSET(ext_sscsrind),
> +
> +RISCV_IMPLIED_EXTS_RULE_END
> +},
> +};
> +
> RISCVCPUImpliedExtsRule *riscv_misa_ext_implied_rules[] = {
> &RVA_IMPLIED, &RVD_IMPLIED, &RVF_IMPLIED,
> &RVM_IMPLIED, &RVV_IMPLIED, NULL
> @@ -2674,7 +2698,7 @@ RISCVCPUImpliedExtsRule
> *riscv_multi_ext_implied_rules[] = {
> &ZVFH_IMPLIED, &ZVFHMIN_IMPLIED, &ZVKN_IMPLIED,
> &ZVKNC_IMPLIED, &ZVKNG_IMPLIED, &ZVKNHB_IMPLIED,
> &ZVKS_IMPLIED, &ZVKSC_IMPLIED, &ZVKSG_IMPLIED, &SSCFG_IMPLIED,
> -NULL
> +&SMCTR_IMPLIED, &SSCTR_IMPLIED, NULL
> };
>
> static Property riscv_cpu_properties[] = {
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index
> a399d55740c7259cd1c1d893687541e23ea3ce52..d7b520099563d3a680c5b75dc987881caab95407
> 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -2399,6 +2399,13 @@ static bool xiselect_cd_range(target_ulong isel)
> return (ISELECT_CD_FIRST <= isel && isel <= ISELECT_CD_LAST);
> }
>
> +static bool xiselect_ctr_range(int csrno, target_ulong isel)
> +{
> +/* MIREG-MIREG6 for the range 0x200-0x2ff are not used by CTR. */
> +return CTR_ENTRIES_FIRST <= isel && isel <= CTR_ENTRIES_LAST &&
> + csrno < CSR_MIREG;
> +}
> +
> static int rmw_iprio(target_ulong xlen,
> target_ulong iselect, uint8_t *iprio,
> target_ulong *val, target_ulong new_val,
> @@ -2444,6 +2451,124 @@ static int rmw_iprio(target_ulong xlen,
> return 0;
> }
>
> +static int rmw_ctrsource(CPURISCVState *env, int isel, target_ulong *val,
> + target_ulong new_val, target_ulong wr_mask)
> +{
> +/*
> + * CTR arrays are treated as circular buffers and TOS always points to
> next
> + * empty slot, keeping TOS - 1 always pointing to latest entry. Given
> entry
> + * 0 is always the latest one, traversal is a bit different here. See the
> + * below example.
> + *
> + * Depth = 16.
> + *
> + * idx[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [A] [B] [C] [D] [E] [F]
> + * TOS H
> + * ent
Re: [PATCH v5 7/7] target/riscv: machine: Add Control Transfer Record state description
On Thu, Dec 5, 2024 at 9:36 PM Rajnesh Kanwal wrote:
>
> Add a subsection to machine.c to migrate CTR CSR state
>
> Signed-off-by: Rajnesh Kanwal
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/machine.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/target/riscv/machine.c b/target/riscv/machine.c
> index
> e1bdc31c7c53a8a4f539113d501c8e46f7a914e9..b67e660ef03b6053fa00d5a79e2ab20ecf3331b8
> 100644
> --- a/target/riscv/machine.c
> +++ b/target/riscv/machine.c
> @@ -311,6 +311,30 @@ static const VMStateDescription vmstate_envcfg = {
> }
> };
>
> +static bool ctr_needed(void *opaque)
> +{
> +RISCVCPU *cpu = opaque;
> +
> +return cpu->cfg.ext_smctr || cpu->cfg.ext_ssctr;
> +}
> +
> +static const VMStateDescription vmstate_ctr = {
> +.name = "cpu/ctr",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.needed = ctr_needed,
> +.fields = (const VMStateField[]) {
> +VMSTATE_UINT64(env.mctrctl, RISCVCPU),
> +VMSTATE_UINT32(env.sctrdepth, RISCVCPU),
> +VMSTATE_UINT32(env.sctrstatus, RISCVCPU),
> +VMSTATE_UINT64(env.vsctrctl, RISCVCPU),
> +VMSTATE_UINT64_ARRAY(env.ctr_src, RISCVCPU, 16 << SCTRDEPTH_MAX),
> +VMSTATE_UINT64_ARRAY(env.ctr_dst, RISCVCPU, 16 << SCTRDEPTH_MAX),
> +VMSTATE_UINT64_ARRAY(env.ctr_data, RISCVCPU, 16 << SCTRDEPTH_MAX),
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> static bool pmu_needed(void *opaque)
> {
> RISCVCPU *cpu = opaque;
> @@ -461,6 +485,7 @@ const VMStateDescription vmstate_riscv_cpu = {
> &vmstate_jvt,
> &vmstate_elp,
> &vmstate_ssp,
> +&vmstate_ctr,
> NULL
> }
> };
>
> --
> 2.34.1
>
>
Re: [PATCH v5 4/7] target/riscv: Add support to record CTR entries.
On Thu, Dec 5, 2024 at 9:35 PM Rajnesh Kanwal wrote:
>
> This commit adds logic to records CTR entries of different types
> and adds required hooks in TCG and interrupt/Exception logic to
> record events.
>
> This commit also adds support to invoke freeze CTR logic for breakpoint
> exceptions and counter overflow interrupts.
>
> Signed-off-by: Rajnesh Kanwal
Acked-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu.h | 7 +
> target/riscv/cpu_helper.c | 259
> +
> target/riscv/helper.h | 1 +
> target/riscv/insn_trans/trans_privileged.c.inc | 2 +
> target/riscv/insn_trans/trans_rvi.c.inc| 75 +++
> target/riscv/insn_trans/trans_rvzce.c.inc | 21 ++
> target/riscv/op_helper.c | 19 ++
> target/riscv/translate.c | 46 +
> 8 files changed, 430 insertions(+)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index
> da14ac2f874b81d3f01bc31b0064d020f2dbdf61..f39ca48d37332c4e5907ca87040de420f78df2e4
> 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -310,6 +310,10 @@ struct CPUArchState {
> uint32_t sctrstatus;
> uint64_t vsctrctl;
>
> +uint64_t ctr_src[16 << SCTRDEPTH_MAX];
> +uint64_t ctr_dst[16 << SCTRDEPTH_MAX];
> +uint64_t ctr_data[16 << SCTRDEPTH_MAX];
> +
> /* Machine and Supervisor interrupt priorities */
> uint8_t miprio[64];
> uint8_t siprio[64];
> @@ -607,6 +611,9 @@ RISCVException smstateen_acc_ok(CPURISCVState *env, int
> index, uint64_t bit);
>
> void riscv_cpu_set_mode(CPURISCVState *env, target_ulong newpriv, bool
> virt_en);
>
> +void riscv_ctr_add_entry(CPURISCVState *env, target_long src, target_long
> dst,
> +enum CTRType type, target_ulong prev_priv, bool prev_virt);
> +
> void riscv_translate_init(void);
> G_NORETURN void riscv_raise_exception(CPURISCVState *env,
>uint32_t exception, uintptr_t pc);
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index
> 0a3ead69eabaf0e395fc7c78868640a4216573ee..dbdad4e29d7de0713f7530c46e9fab03d3c459a4
> 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -771,6 +771,247 @@ void riscv_cpu_set_aia_ireg_rmw_fn(CPURISCVState *env,
> uint32_t priv,
> }
> }
>
> +static void riscv_ctr_freeze(CPURISCVState *env, uint64_t freeze_mask,
> + bool virt)
> +{
> +uint64_t ctl = virt ? env->vsctrctl : env->mctrctl;
> +
> +assert((freeze_mask & (~(XCTRCTL_BPFRZ | XCTRCTL_LCOFIFRZ))) == 0);
> +
> +if (ctl & freeze_mask) {
> +env->sctrstatus |= SCTRSTATUS_FROZEN;
> +}
> +}
> +
> +static uint64_t riscv_ctr_priv_to_mask(target_ulong priv, bool virt)
> +{
> +switch (priv) {
> +case PRV_M:
> +return MCTRCTL_M;
> +case PRV_S:
> +if (virt) {
> +return XCTRCTL_S;
> +}
> +return XCTRCTL_S;
> +case PRV_U:
> +if (virt) {
> +return XCTRCTL_U;
> +}
> +return XCTRCTL_U;
> +}
> +
> +g_assert_not_reached();
> +}
> +
> +static uint64_t riscv_ctr_get_control(CPURISCVState *env, target_long priv,
> + bool virt)
> +{
> +switch (priv) {
> +case PRV_M:
> +return env->mctrctl;
> +case PRV_S:
> +case PRV_U:
> +if (virt) {
> +return env->vsctrctl;
> +}
> +return env->mctrctl;
> +}
> +
> +g_assert_not_reached();
> +}
> +
> +/*
> + * This function assumes that src privilege and target privilege are not same
> + * and src privilege is less than target privilege. This includes the virtual
> + * state as well.
> + */
> +static bool riscv_ctr_check_xte(CPURISCVState *env, target_long src_prv,
> +bool src_virt)
> +{
> +target_long tgt_prv = env->priv;
> +bool res = true;
> +
> +/*
> + * VS and U mode are same in terms of xTE bits required to record an
> + * external trap. See 6.1.2. External Traps, table 8 External Trap Enable
> + * Requirements. This changes VS to U to simplify the logic a bit.
> + */
> +if (src_virt && src_prv == PRV_S) {
> +src_prv = PRV_U;
> +} else if (env->virt_enabled && tgt_prv == PRV_S) {
> +tgt_prv = PRV_U;
> +}
> +
> +/* VU mode is an outlier here. */
> +if (src_virt && src_prv == PRV_U) {
> +res &= !!(env->vsctrctl & XCTRCTL_STE);
> +}
> +
> +switch (src_prv) {
> +case PRV_U:
> +if (tgt_prv == PRV_U) {
> +break;
> +}
> +res &= !!(env->mctrctl & XCTRCTL_STE);
> +/* fall-through */
> +case PRV_S:
> +if (tgt_prv == PRV_S) {
> +break;
> +}
> +res &= !!(env->mctrctl & MCTRCTL_MTE);
> +/* fall-through */
> +case PRV_M:
> +break;
> +}
> +
> +return res;
Re: [PATCH v5 5/7] target/riscv: Add CTR sctrclr instruction.
On Thu, Dec 5, 2024 at 9:35 PM Rajnesh Kanwal wrote:
>
> CTR extension adds a new instruction sctrclr to quickly
> clear the recorded entries buffer.
>
> Signed-off-by: Rajnesh Kanwal
Acked-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu.h | 1 +
> target/riscv/cpu_helper.c | 7 +++
> target/riscv/helper.h | 1 +
> target/riscv/insn32.decode | 1 +
> target/riscv/insn_trans/trans_privileged.c.inc | 11 ++
> target/riscv/op_helper.c | 29
> ++
> 6 files changed, 50 insertions(+)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index
> f39ca48d37332c4e5907ca87040de420f78df2e4..85ca2bfe435d0c9d245f2690fe3bde3e076d3b2f
> 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -613,6 +613,7 @@ void riscv_cpu_set_mode(CPURISCVState *env, target_ulong
> newpriv, bool virt_en);
>
> void riscv_ctr_add_entry(CPURISCVState *env, target_long src, target_long
> dst,
> enum CTRType type, target_ulong prev_priv, bool prev_virt);
> +void riscv_ctr_clear(CPURISCVState *env);
>
> void riscv_translate_init(void);
> G_NORETURN void riscv_raise_exception(CPURISCVState *env,
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index
> dbdad4e29d7de0713f7530c46e9fab03d3c459a4..b1130180710b0e01e8ebe33f0974edd8d5abe56d
> 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -783,6 +783,13 @@ static void riscv_ctr_freeze(CPURISCVState *env,
> uint64_t freeze_mask,
> }
> }
>
> +void riscv_ctr_clear(CPURISCVState *env)
> +{
> +memset(env->ctr_src, 0x0, sizeof(env->ctr_src));
> +memset(env->ctr_dst, 0x0, sizeof(env->ctr_dst));
> +memset(env->ctr_data, 0x0, sizeof(env->ctr_data));
> +}
> +
> static uint64_t riscv_ctr_priv_to_mask(target_ulong priv, bool virt)
> {
> switch (priv) {
> diff --git a/target/riscv/helper.h b/target/riscv/helper.h
> index
> 820ddccf92ab07cbe80ae03b3d2d2ccc4f8e4765..011ee628f81333e30cfa7a375788e546965e4b30
> 100644
> --- a/target/riscv/helper.h
> +++ b/target/riscv/helper.h
> @@ -131,6 +131,7 @@ DEF_HELPER_6(csrrw_i128, tl, env, int, tl, tl, tl, tl)
> #ifndef CONFIG_USER_ONLY
> DEF_HELPER_1(sret, tl, env)
> DEF_HELPER_1(mret, tl, env)
> +DEF_HELPER_1(ctr_clear, void, env)
> DEF_HELPER_1(wfi, void, env)
> DEF_HELPER_1(wrs_nto, void, env)
> DEF_HELPER_1(tlb_flush, void, env)
> diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
> index
> a2b4c0ddd47ad9464b4b180fb19e6a3b64dbe4e5..8188113bcc90482733f676227858829bac5c5462
> 100644
> --- a/target/riscv/insn32.decode
> +++ b/target/riscv/insn32.decode
> @@ -114,6 +114,7 @@
> # *** Privileged Instructions ***
> ecall 0 000 0 1110011
> ebreak 0001 0 000 0 1110011
> +sctrclr 00010100 0 000 0 1110011
> uret00000010 0 000 0 1110011
> sret000100000010 0 000 0 1110011
> mret001100000010 0 000 0 1110011
> diff --git a/target/riscv/insn_trans/trans_privileged.c.inc
> b/target/riscv/insn_trans/trans_privileged.c.inc
> index
> b19d692c22dc74c41df72dae99448c37a0216980..a67088d25bade5cb3be62647e411045894bffe33
> 100644
> --- a/target/riscv/insn_trans/trans_privileged.c.inc
> +++ b/target/riscv/insn_trans/trans_privileged.c.inc
> @@ -69,6 +69,17 @@ static bool trans_ebreak(DisasContext *ctx, arg_ebreak *a)
> return true;
> }
>
> +static bool trans_sctrclr(DisasContext *ctx, arg_sctrclr *a)
> +{
> +#ifndef CONFIG_USER_ONLY
> +if (ctx->cfg_ptr->ext_smctr || ctx->cfg_ptr->ext_ssctr) {
> +gen_helper_ctr_clear(tcg_env);
> +return true;
> +}
> +#endif
> +return false;
> +}
> +
> static bool trans_uret(DisasContext *ctx, arg_uret *a)
> {
> return false;
> diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
> index
> 0684a27bfdb72f6fc5945f30500c2e3a95e85e2f..e7301ee8ca2e3145396a274126e591921b6d9e01
> 100644
> --- a/target/riscv/op_helper.c
> +++ b/target/riscv/op_helper.c
> @@ -389,6 +389,35 @@ void helper_ctr_add_entry(CPURISCVState *env,
> target_ulong src,
> env->priv, env->virt_enabled);
> }
>
> +void helper_ctr_clear(CPURISCVState *env)
> +{
> +/*
> + * It's safe to call smstateen_acc_ok() for umode access regardless of
> the
> + * state of bit 54 (CTR bit in case of m/hstateen) of sstateen. If the
> bit
> + * is zero, smstateen_acc_ok() will return the correct exception code and
> + * if it's one, smstateen_acc_ok() will return RISCV_EXCP_NONE. In that
> + * scenario the U-mode check below will handle that case.
> + */
> +RISCVException ret = smstateen_acc_ok(env, 0, SMSTATEEN0_CTR);
> +if (ret != RISCV_EXCP_NONE) {
> +riscv_raise_exception(env, ret, GETPC());
> +}
> +
> +if (env->priv == PRV_U) {
> +
[PATCH v2 00/14] meson: Deprecate 32-bit host support
v1: 20250128004254.33442-1-richard.hender...@linaro.org For v2, immediately disable 64-on-32 TCG. I *suspect* that we should disable 64-on-32 for *all* accelerators. The idea that an i686 binary on an x86_64 host may be used to spawn an x86_64 guest via kvm is silly and a bit more than niche. Similarly for mips32 spawning mips64 and ppc32 spawning ppc64. But in the meantime, jump through a couple of hoops to keep these kvm and xen cases building, while disabling tcg in the same binaries. Richard Henderson (14): meson: Drop tcg as a module tcg: Move stubs in tcg/perf.h to tcg/perf-stubs.c plugins: Uninline qemu_plugin_add_opts meson: Introduce CONFIG_TCG_TARGET tcg: Link only when required in system mode plugins: Link only when required in system mode accel/stubs: Expand stubs for TCG target/mips: Protect objects with CONFIG_TCG gitlab: Replace aarch64 with arm in cross-i686-tci build configure: Define TARGET_LONG_BITS in configs/targets/*.mak target/*: Remove TARGET_LONG_BITS from cpu-param.h meson: Disallow 64-bit on 32-bit TCG emulation meson: Deprecate 32-bit host support tcg: Remove TCG_OVERSIZED_GUEST include/qemu/atomic.h | 18 ++-- include/qemu/osdep.h| 7 +++ include/qemu/plugin.h | 9 +--- include/tcg/oversized-guest.h | 23 -- include/tcg/perf.h | 23 -- target/alpha/cpu-param.h| 2 - target/arm/cpu-param.h | 2 - target/avr/cpu-param.h | 1 - target/hexagon/cpu-param.h | 1 - target/hppa/cpu-param.h | 2 - target/i386/cpu-param.h | 2 - target/loongarch/cpu-param.h| 1 - target/m68k/cpu-param.h | 1 - target/microblaze/cpu-param.h | 2 - target/mips/cpu-param.h | 5 --- target/openrisc/cpu-param.h | 1 - target/ppc/cpu-param.h | 2 - target/riscv/cpu-param.h| 2 - target/rx/cpu-param.h | 1 - target/s390x/cpu-param.h| 1 - target/sh4/cpu-param.h | 1 - target/sparc/cpu-param.h| 2 - target/tricore/cpu-param.h | 1 - target/xtensa/cpu-param.h | 1 - accel/stubs/tcg-stub.c | 24 ++ accel/tcg/cputlb.c | 7 --- accel/tcg/tcg-all.c | 9 ++-- plugins/loader.c| 7 ++- plugins/stubs.c | 49 + target/arm/ptw.c| 34 -- target/riscv/cpu_helper.c | 13 +- tcg/perf-stubs.c| 26 +++ .gitlab-ci.d/crossbuilds.yml| 2 +- accel/tcg/meson.build | 11 ++--- configs/targets/aarch64-bsd-user.mak| 1 + configs/targets/aarch64-linux-user.mak | 1 + configs/targets/aarch64-softmmu.mak | 1 + configs/targets/aarch64_be-linux-user.mak | 1 + configs/targets/alpha-linux-user.mak| 1 + configs/targets/alpha-softmmu.mak | 1 + configs/targets/arm-bsd-user.mak| 1 + configs/targets/arm-linux-user.mak | 1 + configs/targets/arm-softmmu.mak | 1 + configs/targets/armeb-linux-user.mak| 1 + configs/targets/avr-softmmu.mak | 1 + configs/targets/hexagon-linux-user.mak | 1 + configs/targets/hppa-linux-user.mak | 2 + configs/targets/hppa-softmmu.mak| 1 + configs/targets/i386-bsd-user.mak | 1 + configs/targets/i386-linux-user.mak | 1 + configs/targets/i386-softmmu.mak| 1 + configs/targets/loongarch64-linux-user.mak | 1 + configs/targets/loongarch64-softmmu.mak | 1 + configs/targets/m68k-linux-user.mak | 1 + configs/targets/m68k-softmmu.mak| 1 + configs/targets/microblaze-linux-user.mak | 1 + configs/targets/microblaze-softmmu.mak | 3 ++ configs/targets/microblazeel-linux-user.mak | 1 + configs/targets/microblazeel-softmmu.mak| 3 ++ configs/targets/mips-linux-user.mak | 1 + configs/targets/mips-softmmu.mak| 1 + configs/targets/mips64-linux-user.mak | 1 + configs/targets/mips64-softmmu.mak | 1 + configs/targets/mips64el-linux-user.mak | 1 + configs/targets/mips64el-softmmu.mak| 1 + configs/targets/mipsel-linux-user.mak | 1 + configs/targets/mipsel-softmmu.mak | 1 + configs/targets/mipsn32-linux-user.mak | 1 + configs/targets/mipsn32el-linux-user.mak| 1 + configs/targets/or1k-linux-user.mak | 1 + configs/targets/or1k-softmmu.mak| 1 + configs/targets/ppc-linux-user.mak |
[PATCH v2 06/14] plugins: Link only when required in system mode
Provide out-of-line versions of some of the qemu/plugin.h API.
These will be referenced with --enable-plugin, but CONFIG_TCG
is disabled for a specific target.
Signed-off-by: Richard Henderson
---
plugins/stubs.c | 49 +
plugins/meson.build | 5 -
2 files changed, 53 insertions(+), 1 deletion(-)
create mode 100644 plugins/stubs.c
diff --git a/plugins/stubs.c b/plugins/stubs.c
new file mode 100644
index 00..57af8357e4
--- /dev/null
+++ b/plugins/stubs.c
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Stubs for when CONFIG_PLUGIN is enabled generally, but
+ * CONFIG_TCG_TARGET is disabled for a specific target.
+ * This will only be the case for 64-bit guests on 32-bit hosts
+ * when an alternate accelerator is enabled.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/plugin.h"
+#include "qapi/error.h"
+
+
+void qemu_plugin_add_opts(void)
+{
+}
+
+void qemu_plugin_opt_parse(const char *optstr, QemuPluginList *head)
+{
+error_report("plugin interface not enabled in this build");
+exit(1);
+}
+
+int qemu_plugin_load_list(QemuPluginList *head, Error **errp)
+{
+return 0;
+}
+
+void qemu_plugin_vcpu_init_hook(CPUState *cpu)
+{
+}
+
+void qemu_plugin_vcpu_exit_hook(CPUState *cpu)
+{
+}
+
+void qemu_plugin_vcpu_idle_cb(CPUState *cpu)
+{
+}
+
+void qemu_plugin_vcpu_resume_cb(CPUState *cpu)
+{
+}
+
+CPUPluginState *qemu_plugin_create_vcpu_state(void)
+{
+/* Protected by tcg_enabled() */
+g_assert_not_reached();
+}
diff --git a/plugins/meson.build b/plugins/meson.build
index d60be2a4d6..42442fe22b 100644
--- a/plugins/meson.build
+++ b/plugins/meson.build
@@ -57,8 +57,11 @@ if host_os == 'windows'
command: dlltool_cmd
)
endif
-specific_ss.add(files(
+
+specific_ss.add(when: 'CONFIG_TCG', if_true: files(
'loader.c',
'core.c',
'api.c',
+), if_false: files(
+ 'stubs.c'
))
--
2.43.0
[PATCH v2 08/14] target/mips: Protect objects with CONFIG_TCG
Hack around mips32 host allowing kvm acceleration
of mips64 guest, but tcg is disabled.
Signed-off-by: Richard Henderson
---
target/mips/tcg/meson.build| 4 ++--
target/mips/tcg/system/meson.build | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/target/mips/tcg/meson.build b/target/mips/tcg/meson.build
index fff9cd6c7f..e5574f177b 100644
--- a/target/mips/tcg/meson.build
+++ b/target/mips/tcg/meson.build
@@ -10,7 +10,7 @@ gen = [
]
mips_ss.add(gen)
-mips_ss.add(files(
+mips_ss.add(when: 'CONFIG_TCG', if_true: files(
'dsp_helper.c',
'exception.c',
'fpu_helper.c',
@@ -26,7 +26,7 @@ mips_ss.add(files(
'vr54xx_helper.c',
'vr54xx_translate.c',
))
-mips_ss.add(when: 'TARGET_MIPS64', if_true: files(
+mips_ss.add(when: ['CONFIG_TCG', 'TARGET_MIPS64'], if_true: files(
'tx79_translate.c',
'octeon_translate.c',
'lcsr_translate.c',
diff --git a/target/mips/tcg/system/meson.build
b/target/mips/tcg/system/meson.build
index 911341ac37..606ccacebc 100644
--- a/target/mips/tcg/system/meson.build
+++ b/target/mips/tcg/system/meson.build
@@ -1,12 +1,12 @@
-mips_system_ss.add(files(
+mips_system_ss.add(when: 'CONFIG_TCG', if_true: files(
'cp0_helper.c',
'special_helper.c',
'tlb_helper.c',
))
-mips_system_ss.add(when: ['CONFIG_SEMIHOSTING'],
+mips_system_ss.add(when: ['CONFIG_TCG', 'CONFIG_SEMIHOSTING'],
if_true: files('mips-semi.c'),
if_false: files('semihosting-stub.c')
)
-mips_system_ss.add(when: 'TARGET_MIPS64', if_true: files(
+mips_system_ss.add(when: ['CONFIG_TCG', 'TARGET_MIPS64'], if_true: files(
'lcsr_helper.c',
))
--
2.43.0
[PATCH v2 03/14] plugins: Uninline qemu_plugin_add_opts
No need to expand this function inline.
Unexport qemu_plugin_opts to match.
Signed-off-by: Richard Henderson
---
include/qemu/plugin.h | 9 +
plugins/loader.c | 7 ++-
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/include/qemu/plugin.h b/include/qemu/plugin.h
index 9726a9ebf3..3efded6a3e 100644
--- a/include/qemu/plugin.h
+++ b/include/qemu/plugin.h
@@ -11,7 +11,6 @@
#include "qemu/qemu-plugin.h"
#include "qemu/error-report.h"
#include "qemu/queue.h"
-#include "qemu/option.h"
#include "qemu/plugin-event.h"
#include "qemu/bitmap.h"
#include "exec/memopidx.h"
@@ -44,13 +43,7 @@ get_plugin_meminfo_rw(qemu_plugin_meminfo_t i)
}
#ifdef CONFIG_PLUGIN
-extern QemuOptsList qemu_plugin_opts;
-
-static inline void qemu_plugin_add_opts(void)
-{
-qemu_add_opts(&qemu_plugin_opts);
-}
-
+void qemu_plugin_add_opts(void);
void qemu_plugin_opt_parse(const char *optstr, QemuPluginList *head);
int qemu_plugin_load_list(QemuPluginList *head, Error **errp);
diff --git a/plugins/loader.c b/plugins/loader.c
index ebc01da9c6..35680bfc13 100644
--- a/plugins/loader.c
+++ b/plugins/loader.c
@@ -55,7 +55,7 @@ struct qemu_plugin_parse_arg {
struct qemu_plugin_desc *curr;
};
-QemuOptsList qemu_plugin_opts = {
+static QemuOptsList qemu_plugin_opts = {
.name = "plugin",
.implied_opt_name = "file",
.head = QTAILQ_HEAD_INITIALIZER(qemu_plugin_opts.head),
@@ -65,6 +65,11 @@ QemuOptsList qemu_plugin_opts = {
},
};
+void qemu_plugin_add_opts(void)
+{
+qemu_add_opts(&qemu_plugin_opts);
+}
+
typedef int (*qemu_plugin_install_func_t)(qemu_plugin_id_t, const qemu_info_t
*, int, char **);
extern struct qemu_plugin_state plugin;
--
2.43.0
[PATCH v2 14/14] tcg: Remove TCG_OVERSIZED_GUEST
This is now prohibited in configuration.
Signed-off-by: Richard Henderson
---
include/qemu/atomic.h | 18 +++--
include/tcg/oversized-guest.h | 23 --
accel/tcg/cputlb.c | 7 ---
accel/tcg/tcg-all.c | 9 -
target/arm/ptw.c| 34 -
target/riscv/cpu_helper.c | 13 +
docs/devel/multi-thread-tcg.rst | 1 -
7 files changed, 8 insertions(+), 97 deletions(-)
delete mode 100644 include/tcg/oversized-guest.h
diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index 7a3f2e6576..f80cba24cf 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -56,25 +56,13 @@
*/
#define signal_barrier()__atomic_signal_fence(__ATOMIC_SEQ_CST)
-/* Sanity check that the size of an atomic operation isn't "overly large".
+/*
+ * Sanity check that the size of an atomic operation isn't "overly large".
* Despite the fact that e.g. i686 has 64-bit atomic operations, we do not
* want to use them because we ought not need them, and this lets us do a
* bit of sanity checking that other 32-bit hosts might build.
- *
- * That said, we have a problem on 64-bit ILP32 hosts in that in order to
- * sync with TCG_OVERSIZED_GUEST, this must match TCG_TARGET_REG_BITS.
- * We'd prefer not want to pull in everything else TCG related, so handle
- * those few cases by hand.
- *
- * Note that x32 is fully detected with __x86_64__ + _ILP32, and that for
- * Sparc we always force the use of sparcv9 in configure. MIPS n32 (ILP32) &
- * n64 (LP64) ABIs are both detected using __mips64.
*/
-#if defined(__x86_64__) || defined(__sparc__) || defined(__mips64)
-# define ATOMIC_REG_SIZE 8
-#else
-# define ATOMIC_REG_SIZE sizeof(void *)
-#endif
+#define ATOMIC_REG_SIZE sizeof(void *)
/* Weak atomic operations prevent the compiler moving other
* loads/stores past the atomic operation load/store. However there is
diff --git a/include/tcg/oversized-guest.h b/include/tcg/oversized-guest.h
deleted file mode 100644
index 641b9749ff..00
--- a/include/tcg/oversized-guest.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-/*
- * Define TCG_OVERSIZED_GUEST
- * Copyright (c) 2008 Fabrice Bellard
- */
-
-#ifndef EXEC_TCG_OVERSIZED_GUEST_H
-#define EXEC_TCG_OVERSIZED_GUEST_H
-
-#include "tcg-target-reg-bits.h"
-#include "cpu-param.h"
-
-/*
- * Oversized TCG guests make things like MTTCG hard
- * as we can't use atomics for cputlb updates.
- */
-#if TARGET_LONG_BITS > TCG_TARGET_REG_BITS
-#define TCG_OVERSIZED_GUEST 1
-#else
-#define TCG_OVERSIZED_GUEST 0
-#endif
-
-#endif
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index b4ccf0cdcb..17e2251695 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -47,7 +47,6 @@
#include "qemu/plugin-memory.h"
#endif
#include "tcg/tcg-ldst.h"
-#include "tcg/oversized-guest.h"
/* DEBUG defines, enable DEBUG_TLB_LOG to log to the CPU_LOG_MMU target */
/* #define DEBUG_TLB */
@@ -118,12 +117,8 @@ static inline uint64_t tlb_read_idx(const CPUTLBEntry
*entry,
return qatomic_read(ptr);
#else
const uint64_t *ptr = &entry->addr_idx[access_type];
-# if TCG_OVERSIZED_GUEST
-return *ptr;
-# else
/* ofs might correspond to .addr_write, so use qatomic_read */
return qatomic_read(ptr);
-# endif
#endif
}
@@ -908,8 +903,6 @@ static void tlb_reset_dirty_range_locked(CPUTLBEntry
*tlb_entry,
uint32_t *ptr_write = (uint32_t *)&tlb_entry->addr_write;
ptr_write += HOST_BIG_ENDIAN;
qatomic_set(ptr_write, *ptr_write | TLB_NOTDIRTY);
-#elif TCG_OVERSIZED_GUEST
-tlb_entry->addr_write |= TLB_NOTDIRTY;
#else
qatomic_set(&tlb_entry->addr_write,
tlb_entry->addr_write | TLB_NOTDIRTY);
diff --git a/accel/tcg/tcg-all.c b/accel/tcg/tcg-all.c
index 95adaacee8..c1a30b0121 100644
--- a/accel/tcg/tcg-all.c
+++ b/accel/tcg/tcg-all.c
@@ -28,7 +28,6 @@
#include "exec/replay-core.h"
#include "system/cpu-timers.h"
#include "tcg/startup.h"
-#include "tcg/oversized-guest.h"
#include "qapi/error.h"
#include "qemu/error-report.h"
#include "qemu/accel.h"
@@ -41,6 +40,8 @@
#include "hw/boards.h"
#endif
#include "internal-common.h"
+#include "cpu-param.h"
+
struct TCGState {
AccelState parent_obj;
@@ -72,7 +73,7 @@ DECLARE_INSTANCE_CHECKER(TCGState, TCG_STATE,
static bool default_mttcg_enabled(void)
{
-if (icount_enabled() || TCG_OVERSIZED_GUEST) {
+if (icount_enabled()) {
return false;
}
#ifdef TARGET_SUPPORTS_MTTCG
@@ -145,9 +146,7 @@ static void tcg_set_thread(Object *obj, const char *value,
Error **errp)
TCGState *s = TCG_STATE(obj);
if (strcmp(value, "multi") == 0) {
-if (TCG_OVERSIZED_GUEST) {
-error_setg(errp, "No MTTCG when guest word size > hosts");
-} else if (icount_enabled()) {
+if (icount_enabled()) {
error_setg(errp, "No
[PATCH v2 01/14] meson: Drop tcg as a module
The fact that this is only enabled for x86 probably means it
was done incorrectly. Certainly the set of files selected to
go into the module is woefully incomplete. Drop it for now.
Signed-off-by: Richard Henderson
---
accel/tcg/meson.build | 11 ---
meson.build | 18 +-
2 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/accel/tcg/meson.build b/accel/tcg/meson.build
index aef80de967..69f4808ac4 100644
--- a/accel/tcg/meson.build
+++ b/accel/tcg/meson.build
@@ -21,16 +21,13 @@ specific_ss.add_all(when: 'CONFIG_TCG', if_true:
tcg_specific_ss)
specific_ss.add(when: ['CONFIG_SYSTEM_ONLY', 'CONFIG_TCG'], if_true: files(
'cputlb.c',
'watchpoint.c',
+ 'tcg-accel-ops.c',
+ 'tcg-accel-ops-mttcg.c',
+ 'tcg-accel-ops-icount.c',
+ 'tcg-accel-ops-rr.c',
))
system_ss.add(when: ['CONFIG_TCG'], if_true: files(
'icount-common.c',
'monitor.c',
))
-
-tcg_module_ss.add(when: ['CONFIG_SYSTEM_ONLY', 'CONFIG_TCG'], if_true: files(
- 'tcg-accel-ops.c',
- 'tcg-accel-ops-mttcg.c',
- 'tcg-accel-ops-icount.c',
- 'tcg-accel-ops-rr.c',
-))
diff --git a/meson.build b/meson.build
index 2c9ac9cfe1..b72114819b 100644
--- a/meson.build
+++ b/meson.build
@@ -322,12 +322,6 @@ if cpu in ['x86', 'x86_64']
}
endif
-modular_tcg = []
-# Darwin does not support references to thread-local variables in modules
-if host_os != 'darwin'
- modular_tcg = ['i386-softmmu', 'x86_64-softmmu']
-endif
-
##
# Compiler flags #
##
@@ -3279,11 +3273,6 @@ foreach target : target_dirs
if sym == 'CONFIG_TCG' or target in accelerator_targets.get(sym, [])
config_target += { sym: 'y' }
config_all_accel += { sym: 'y' }
- if target in modular_tcg
-config_target += { 'CONFIG_TCG_MODULAR': 'y' }
- else
-config_target += { 'CONFIG_TCG_BUILTIN': 'y' }
- endif
target_kconfig += [ sym + '=y' ]
endif
endforeach
@@ -3642,7 +3631,6 @@ util_ss = ss.source_set()
# accel modules
qtest_module_ss = ss.source_set()
-tcg_module_ss = ss.source_set()
modules = {}
target_modules = {}
@@ -3803,11 +3791,7 @@ subdir('tests/qtest/libqos')
subdir('tests/qtest/fuzz')
# accel modules
-tcg_real_module_ss = ss.source_set()
-tcg_real_module_ss.add_all(when: 'CONFIG_TCG_MODULAR', if_true: tcg_module_ss)
-specific_ss.add_all(when: 'CONFIG_TCG_BUILTIN', if_true: tcg_module_ss)
-target_modules += { 'accel' : { 'qtest': qtest_module_ss,
-'tcg': tcg_real_module_ss }}
+target_modules += { 'accel' : { 'qtest': qtest_module_ss }}
##
# Internal static_libraries and dependencies #
--
2.43.0
[PATCH v2 07/14] accel/stubs: Expand stubs for TCG
Add tcg_allowed, qmp_x_query_jit, qmp_x_query_opcount.
These are referenced when CONFIG_TCG is enabled globally,
but not for a specific target.
Signed-off-by: Richard Henderson
---
accel/stubs/tcg-stub.c | 24
1 file changed, 24 insertions(+)
diff --git a/accel/stubs/tcg-stub.c b/accel/stubs/tcg-stub.c
index 7f4208fddf..9c2e2dc6e1 100644
--- a/accel/stubs/tcg-stub.c
+++ b/accel/stubs/tcg-stub.c
@@ -13,6 +13,18 @@
#include "qemu/osdep.h"
#include "exec/tb-flush.h"
#include "exec/exec-all.h"
+#include "qapi/error.h"
+
+/*
+ * This file *ought* to be built once and linked only when required.
+ * However, it is built per-target, which means qemu/osdep.h has already
+ * undef'ed CONFIG_TCG, which hides the auto-generated declaration.
+ */
+#define CONFIG_TCG
+#include "qapi/qapi-commands-machine.h"
+
+
+const bool tcg_allowed = false;
void tb_flush(CPUState *cpu)
{
@@ -27,3 +39,15 @@ G_NORETURN void cpu_loop_exit_restore(CPUState *cpu,
uintptr_t pc)
{
g_assert_not_reached();
}
+
+HumanReadableText *qmp_x_query_jit(Error **errp)
+{
+error_setg(errp, "JIT information is only available with accel=tcg");
+return NULL;
+}
+
+HumanReadableText *qmp_x_query_opcount(Error **errp)
+{
+error_setg(errp, "Opcode count information is only available with
accel=tcg");
+return NULL;
+}
--
2.43.0
[PATCH v2 11/14] target/*: Remove TARGET_LONG_BITS from cpu-param.h
This is now handled by the configs/targets/*.mak fragment. Signed-off-by: Richard Henderson --- target/alpha/cpu-param.h | 2 -- target/arm/cpu-param.h| 2 -- target/avr/cpu-param.h| 1 - target/hexagon/cpu-param.h| 1 - target/hppa/cpu-param.h | 2 -- target/i386/cpu-param.h | 2 -- target/loongarch/cpu-param.h | 1 - target/m68k/cpu-param.h | 1 - target/microblaze/cpu-param.h | 2 -- target/mips/cpu-param.h | 5 - target/openrisc/cpu-param.h | 1 - target/ppc/cpu-param.h| 2 -- target/riscv/cpu-param.h | 2 -- target/rx/cpu-param.h | 1 - target/s390x/cpu-param.h | 1 - target/sh4/cpu-param.h| 1 - target/sparc/cpu-param.h | 2 -- target/tricore/cpu-param.h| 1 - target/xtensa/cpu-param.h | 1 - 19 files changed, 31 deletions(-) diff --git a/target/alpha/cpu-param.h b/target/alpha/cpu-param.h index c21ddf1afd..ff06e41497 100644 --- a/target/alpha/cpu-param.h +++ b/target/alpha/cpu-param.h @@ -8,8 +8,6 @@ #ifndef ALPHA_CPU_PARAM_H #define ALPHA_CPU_PARAM_H -#define TARGET_LONG_BITS 64 - /* ??? EV4 has 34 phys addr bits, EV5 has 40, EV6 has 44. */ #define TARGET_PHYS_ADDR_SPACE_BITS 44 diff --git a/target/arm/cpu-param.h b/target/arm/cpu-param.h index bed29613c8..896b35bd6d 100644 --- a/target/arm/cpu-param.h +++ b/target/arm/cpu-param.h @@ -9,11 +9,9 @@ #define ARM_CPU_PARAM_H #ifdef TARGET_AARCH64 -# define TARGET_LONG_BITS 64 # define TARGET_PHYS_ADDR_SPACE_BITS 52 # define TARGET_VIRT_ADDR_SPACE_BITS 52 #else -# define TARGET_LONG_BITS 32 # define TARGET_PHYS_ADDR_SPACE_BITS 40 # define TARGET_VIRT_ADDR_SPACE_BITS 32 #endif diff --git a/target/avr/cpu-param.h b/target/avr/cpu-param.h index 93c2f470d0..81f3f49ee1 100644 --- a/target/avr/cpu-param.h +++ b/target/avr/cpu-param.h @@ -21,7 +21,6 @@ #ifndef AVR_CPU_PARAM_H #define AVR_CPU_PARAM_H -#define TARGET_LONG_BITS 32 /* * TARGET_PAGE_BITS cannot be more than 8 bits because * 1. all IO registers occupy [0x .. 0x00ff] address range, and they diff --git a/target/hexagon/cpu-param.h b/target/hexagon/cpu-param.h index 71b4a9b83e..45ee7b4640 100644 --- a/target/hexagon/cpu-param.h +++ b/target/hexagon/cpu-param.h @@ -19,7 +19,6 @@ #define HEXAGON_CPU_PARAM_H #define TARGET_PAGE_BITS 16 /* 64K pages */ -#define TARGET_LONG_BITS 32 #define TARGET_PHYS_ADDR_SPACE_BITS 36 #define TARGET_VIRT_ADDR_SPACE_BITS 32 diff --git a/target/hppa/cpu-param.h b/target/hppa/cpu-param.h index ef3200f0f3..7ed6b5741e 100644 --- a/target/hppa/cpu-param.h +++ b/target/hppa/cpu-param.h @@ -8,8 +8,6 @@ #ifndef HPPA_CPU_PARAM_H #define HPPA_CPU_PARAM_H -#define TARGET_LONG_BITS 64 - #if defined(CONFIG_USER_ONLY) && defined(TARGET_ABI32) # define TARGET_PHYS_ADDR_SPACE_BITS 32 # define TARGET_VIRT_ADDR_SPACE_BITS 32 diff --git a/target/i386/cpu-param.h b/target/i386/cpu-param.h index 8c75abe141..b0e884c5d7 100644 --- a/target/i386/cpu-param.h +++ b/target/i386/cpu-param.h @@ -9,7 +9,6 @@ #define I386_CPU_PARAM_H #ifdef TARGET_X86_64 -# define TARGET_LONG_BITS 64 # define TARGET_PHYS_ADDR_SPACE_BITS 52 /* * ??? This is really 48 bits, sign-extended, but the only thing @@ -18,7 +17,6 @@ */ # define TARGET_VIRT_ADDR_SPACE_BITS 47 #else -# define TARGET_LONG_BITS 32 # define TARGET_PHYS_ADDR_SPACE_BITS 36 # define TARGET_VIRT_ADDR_SPACE_BITS 32 #endif diff --git a/target/loongarch/cpu-param.h b/target/loongarch/cpu-param.h index db5ad1c69f..52437946e5 100644 --- a/target/loongarch/cpu-param.h +++ b/target/loongarch/cpu-param.h @@ -8,7 +8,6 @@ #ifndef LOONGARCH_CPU_PARAM_H #define LOONGARCH_CPU_PARAM_H -#define TARGET_LONG_BITS 64 #define TARGET_PHYS_ADDR_SPACE_BITS 48 #define TARGET_VIRT_ADDR_SPACE_BITS 48 diff --git a/target/m68k/cpu-param.h b/target/m68k/cpu-param.h index 5bbe623ba7..7afbf6d302 100644 --- a/target/m68k/cpu-param.h +++ b/target/m68k/cpu-param.h @@ -8,7 +8,6 @@ #ifndef M68K_CPU_PARAM_H #define M68K_CPU_PARAM_H -#define TARGET_LONG_BITS 32 /* * Coldfire Linux uses 8k pages * and m68k linux uses 4k pages diff --git a/target/microblaze/cpu-param.h b/target/microblaze/cpu-param.h index 00efb509e3..c866ec6c14 100644 --- a/target/microblaze/cpu-param.h +++ b/target/microblaze/cpu-param.h @@ -17,11 +17,9 @@ * of address space. */ #ifdef CONFIG_USER_ONLY -#define TARGET_LONG_BITS 32 #define TARGET_PHYS_ADDR_SPACE_BITS 32 #define TARGET_VIRT_ADDR_SPACE_BITS 32 #else -#define TARGET_LONG_BITS 64 #define TARGET_PHYS_ADDR_SPACE_BITS 64 #define TARGET_VIRT_ADDR_SPACE_BITS 64 #endif diff --git a/target/mips/cpu-param.h b/target/mips/cpu-param.h index f3a37e2dbe..11b3ac0ac6 100644 --- a/target/mips/cpu-param.h +++ b/target/mips/cpu-param.h @@ -7,11 +7,6 @@ #ifndef MIPS_CPU_PARAM_H #define MIPS_CPU_PARAM_H -#ifdef TARGET_MIPS64 -# define TARGET_LONG_BITS 64 -#else -# define TARGET_LONG_BITS 32 -#endif #ifdef TA
[PATCH v2 13/14] meson: Deprecate 32-bit host support
We deprecated i686 system mode support for qemu 8.0. However, to
make real cleanups to TCG we need to deprecate all 32-bit hosts.
Signed-off-by: Richard Henderson
---
docs/about/deprecated.rst | 7 +++
meson.build | 6 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 4a3c302962..7c61d0ba16 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -204,6 +204,13 @@ is going to be so much slower it wouldn't make sense for
any serious
instrumentation. Due to implementation differences there will also be
anomalies in things like memory instrumentation.
+32-bit host operating systems (since 10.0)
+''
+
+Keeping 32-bit host support alive is a substantial burden for the
+QEMU project. Thus QEMU will in future drop the support for all
+32-bit host systems.
+
System emulator CPUs
diff --git a/meson.build b/meson.build
index 866b8ce477..0dae54da0d 100644
--- a/meson.build
+++ b/meson.build
@@ -4833,14 +4833,12 @@ if host_arch == 'unknown'
message('configure has succeeded and you can continue to build, but')
message('QEMU will use a slow interpreter to emulate the target CPU.')
endif
-elif host_arch == 'mips'
+elif host_long_bits < 64
message()
warning('DEPRECATED HOST CPU')
message()
message('Support for CPU host architecture ' + cpu + ' is going to be')
- message('dropped as soon as the QEMU project stops supporting Debian 12')
- message('("Bookworm"). Going forward, the QEMU project will not guarantee')
- message('that QEMU will compile or work on this host CPU.')
+ message('dropped in a future QEMU release.')
endif
if not supported_oses.contains(host_os)
--
2.43.0
[PATCH v2 02/14] tcg: Move stubs in tcg/perf.h to tcg/perf-stubs.c
These are not called so frequently as to be
performance sensitive.
Signed-off-by: Richard Henderson
---
include/tcg/perf.h | 23 ---
tcg/perf-stubs.c | 26 ++
tcg/meson.build| 2 ++
3 files changed, 28 insertions(+), 23 deletions(-)
create mode 100644 tcg/perf-stubs.c
diff --git a/include/tcg/perf.h b/include/tcg/perf.h
index c96b5920a3..050ba855ab 100644
--- a/include/tcg/perf.h
+++ b/include/tcg/perf.h
@@ -7,7 +7,6 @@
#ifndef TCG_PERF_H
#define TCG_PERF_H
-#if defined(CONFIG_TCG) && defined(CONFIG_LINUX)
/* Start writing perf-.map. */
void perf_enable_perfmap(void);
@@ -23,27 +22,5 @@ void perf_report_code(uint64_t guest_pc, TranslationBlock
*tb,
/* Stop writing perf-.map and/or jit-.dump. */
void perf_exit(void);
-#else
-static inline void perf_enable_perfmap(void)
-{
-}
-
-static inline void perf_enable_jitdump(void)
-{
-}
-
-static inline void perf_report_prologue(const void *start, size_t size)
-{
-}
-
-static inline void perf_report_code(uint64_t guest_pc, TranslationBlock *tb,
-const void *start)
-{
-}
-
-static inline void perf_exit(void)
-{
-}
-#endif
#endif
diff --git a/tcg/perf-stubs.c b/tcg/perf-stubs.c
new file mode 100644
index 00..ce2dd1a4b7
--- /dev/null
+++ b/tcg/perf-stubs.c
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* TCG perf stubs */
+
+#include "qemu/osdep.h"
+#include "tcg/perf.h"
+
+void perf_enable_perfmap(void)
+{
+}
+
+void perf_enable_jitdump(void)
+{
+}
+
+void perf_report_prologue(const void *start, size_t size)
+{
+}
+
+void perf_report_code(uint64_t guest_pc, TranslationBlock *tb,
+const void *start)
+{
+}
+
+void perf_exit(void)
+{
+}
diff --git a/tcg/meson.build b/tcg/meson.build
index 69ebb4908a..2977df5862 100644
--- a/tcg/meson.build
+++ b/tcg/meson.build
@@ -25,6 +25,8 @@ endif
tcg_ss.add(when: libdw, if_true: files('debuginfo.c'))
if host_os == 'linux'
tcg_ss.add(files('perf.c'))
+else
+ tcg_ss.add(files('perf-stubs.c'))
endif
tcg_ss = tcg_ss.apply({})
--
2.43.0
[PATCH v2 12/14] meson: Disallow 64-bit on 32-bit TCG emulation
For system mode, we can rarely support the amount of RAM that
the guest requires. Emulation is restricted to round-robin
mode, which solves many of the atomicity issues, but not those
associated with virtio. In any case, round-robin does nothing
to help the speed of emulation.
For user mode, most emulation does not succeed at all. Most
of the time we cannot even load 64-bit non-PIE binaries due
to lack of a 64-bit address space. Threads are run in
parallel, not round-robin, which means that atomicity
is not handled.
Signed-off-by: Richard Henderson
---
meson.build | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build
index 5ca3cc3f34..866b8ce477 100644
--- a/meson.build
+++ b/meson.build
@@ -3176,6 +3176,9 @@ if host_os == 'windows'
endif
endif
+# Detect host pointer size for the target configuration loop.
+host_long_bits = cc.sizeof('void *') * 8
+
# Target configuration #
@@ -3268,11 +3271,18 @@ foreach target : target_dirs
}
endif
+ config_target += keyval.load('configs/targets' / target + '.mak')
+
target_kconfig = []
foreach sym: accelerators
if sym == 'CONFIG_TCG'
+ # Disallow 64-bit on 32-bit TCG emulation.
+ if host_long_bits < config_target['TARGET_LONG_BITS'].to_int()
+continue
+ endif
config_target += { 'CONFIG_TCG_TARGET': 'y' }
elif target not in accelerator_targets.get(sym, [])
+ # Other accelerators are handled by accelerator_targets.
continue
endif
config_target += { sym: 'y' }
@@ -3286,9 +3296,6 @@ foreach target : target_dirs
error('No accelerator available for target @0@'.format(target))
endif
- config_target += keyval.load('configs/targets' / target + '.mak')
- config_target += { 'TARGET_' + config_target['TARGET_ARCH'].to_upper(): 'y' }
-
if 'TARGET_NEED_FDT' in config_target and not fdt.found()
if default_targets
warning('Disabling ' + target + ' due to missing libfdt')
@@ -3301,6 +3308,7 @@ foreach target : target_dirs
actual_target_dirs += target
# Add default keys
+ config_target += { 'TARGET_' + config_target['TARGET_ARCH'].to_upper(): 'y' }
if 'TARGET_BASE_ARCH' not in config_target
config_target += {'TARGET_BASE_ARCH': config_target['TARGET_ARCH']}
endif
--
2.43.0
[PATCH v2 09/14] gitlab: Replace aarch64 with arm in cross-i686-tci build
Configuration of 64-bit host on 32-bit guest will shortly be denied. Use a 32-bit guest instead. Signed-off-by: Richard Henderson --- .gitlab-ci.d/crossbuilds.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index 95dfc39224..7ae0f966f1 100644 --- a/.gitlab-ci.d/crossbuilds.yml +++ b/.gitlab-ci.d/crossbuilds.yml @@ -61,7 +61,7 @@ cross-i686-tci: variables: IMAGE: debian-i686-cross ACCEL: tcg-interpreter -EXTRA_CONFIGURE_OPTS: --target-list=i386-softmmu,i386-linux-user,aarch64-softmmu,aarch64-linux-user,ppc-softmmu,ppc-linux-user --disable-plugins --disable-kvm +EXTRA_CONFIGURE_OPTS: --target-list=i386-softmmu,i386-linux-user,arm-softmmu,arm-linux-user,ppc-softmmu,ppc-linux-user --disable-plugins --disable-kvm # Force tests to run with reduced parallelism, to see whether this # reduces the flakiness of this CI job. The CI # environment by default shows us 8 CPUs and so we -- 2.43.0
[PATCH v2 05/14] tcg: Link only when required in system mode
Rather than unconditional linkage via system_ss, conditinally
include the static library via specific_ss. This will elide
the code when CONFIG_TCG is disabled for a specific target.
Signed-off-by: Richard Henderson
---
tcg/meson.build | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tcg/meson.build b/tcg/meson.build
index 2977df5862..8266bcb324 100644
--- a/tcg/meson.build
+++ b/tcg/meson.build
@@ -49,4 +49,8 @@ libtcg_system = static_library('tcg_system',
tcg_system = declare_dependency(objects:
libtcg_system.extract_all_objects(recursive: false),
dependencies: tcg_ss.dependencies())
-system_ss.add(tcg_system)
+
+specific_ss.add(when: ['CONFIG_SYSTEM_ONLY', 'CONFIG_TCG'], if_true:
tcg_system)
+if host_os == 'linux'
+ specific_ss.add(when: 'CONFIG_TCG', if_false: files('perf-stubs.c'))
+endif
--
2.43.0
[PATCH v2 04/14] meson: Introduce CONFIG_TCG_TARGET
Use CONFIG_TCG as a project-wide flag to indicate that TCG is enabled
for *some* target. Use CONFIG_TCG_TARGET to indicate that TCG is
enabled for a specific target.
Within a specific compilation unit, we can remap CONFIG_TCG based on
CONFIG_TCG_TARGET. This allows us to avoid changes to the bulk of
the code base.
Within meson.build, while CONFIG_TCG may be set in config_host_data,
it may not be set within config_target. Thus all references to
CONFIG_TCG in source_set 'when:' need not be updated.
For the moment, CONFIG_TCG and CONFIG_TCG_TARGET are identical.
Signed-off-by: Richard Henderson
---
include/qemu/osdep.h | 7 +++
meson.build | 11 +++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 112ebdff21..1f6f73a148 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -34,9 +34,16 @@
#include "config-host.h"
#ifdef COMPILING_PER_TARGET
#include CONFIG_TARGET
+# ifdef CONFIG_TCG_TARGET
+# undef CONFIG_TCG_TARGET
+# else
+# undef CONFIG_TCG
+# endif
#else
#include "exec/poison.h"
#endif
+#pragma GCC poison CONFIG_TCG_TARGET
+
/*
* HOST_WORDS_BIGENDIAN was replaced with HOST_BIG_ENDIAN. Prevent it from
diff --git a/meson.build b/meson.build
index b72114819b..5ca3cc3f34 100644
--- a/meson.build
+++ b/meson.build
@@ -3270,11 +3270,14 @@ foreach target : target_dirs
target_kconfig = []
foreach sym: accelerators
-if sym == 'CONFIG_TCG' or target in accelerator_targets.get(sym, [])
- config_target += { sym: 'y' }
- config_all_accel += { sym: 'y' }
- target_kconfig += [ sym + '=y' ]
+if sym == 'CONFIG_TCG'
+ config_target += { 'CONFIG_TCG_TARGET': 'y' }
+elif target not in accelerator_targets.get(sym, [])
+ continue
endif
+config_target += { sym: 'y' }
+config_all_accel += { sym: 'y' }
+target_kconfig += [ sym + '=y' ]
endforeach
if target_kconfig.length() == 0
if default_targets
--
2.43.0
[PATCH v2 10/14] configure: Define TARGET_LONG_BITS in configs/targets/*.mak
Define TARGET_LONG_BITS in each target's configure fragment. Do this without removing the define in target/*/cpu-param.h so that errors are caught like so: In file included from .../src/include/exec/cpu-defs.h:26, from ../src/target/hppa/cpu.h:24, from ../src/linux-user/qemu.h:4, from ../src/linux-user/hppa/cpu_loop.c:21: ../src/target/hppa/cpu-param.h:11: error: "TARGET_LONG_BITS" redefined [-Werror] 11 | #define TARGET_LONG_BITS 64 | In file included from .../src/include/qemu/osdep.h:36, from ../src/linux-user/hppa/cpu_loop.c:20: ./hppa-linux-user-config-target.h:32: note: this is the location of the previous definition 32 | #define TARGET_LONG_BITS 32 | cc1: all warnings being treated as errors Signed-off-by: Richard Henderson --- configs/targets/aarch64-bsd-user.mak| 1 + configs/targets/aarch64-linux-user.mak | 1 + configs/targets/aarch64-softmmu.mak | 1 + configs/targets/aarch64_be-linux-user.mak | 1 + configs/targets/alpha-linux-user.mak| 1 + configs/targets/alpha-softmmu.mak | 1 + configs/targets/arm-bsd-user.mak| 1 + configs/targets/arm-linux-user.mak | 1 + configs/targets/arm-softmmu.mak | 1 + configs/targets/armeb-linux-user.mak| 1 + configs/targets/avr-softmmu.mak | 1 + configs/targets/hexagon-linux-user.mak | 1 + configs/targets/hppa-linux-user.mak | 2 ++ configs/targets/hppa-softmmu.mak| 1 + configs/targets/i386-bsd-user.mak | 1 + configs/targets/i386-linux-user.mak | 1 + configs/targets/i386-softmmu.mak| 1 + configs/targets/loongarch64-linux-user.mak | 1 + configs/targets/loongarch64-softmmu.mak | 1 + configs/targets/m68k-linux-user.mak | 1 + configs/targets/m68k-softmmu.mak| 1 + configs/targets/microblaze-linux-user.mak | 1 + configs/targets/microblaze-softmmu.mak | 3 +++ configs/targets/microblazeel-linux-user.mak | 1 + configs/targets/microblazeel-softmmu.mak| 3 +++ configs/targets/mips-linux-user.mak | 1 + configs/targets/mips-softmmu.mak| 1 + configs/targets/mips64-linux-user.mak | 1 + configs/targets/mips64-softmmu.mak | 1 + configs/targets/mips64el-linux-user.mak | 1 + configs/targets/mips64el-softmmu.mak| 1 + configs/targets/mipsel-linux-user.mak | 1 + configs/targets/mipsel-softmmu.mak | 1 + configs/targets/mipsn32-linux-user.mak | 1 + configs/targets/mipsn32el-linux-user.mak| 1 + configs/targets/or1k-linux-user.mak | 1 + configs/targets/or1k-softmmu.mak| 1 + configs/targets/ppc-linux-user.mak | 1 + configs/targets/ppc-softmmu.mak | 1 + configs/targets/ppc64-linux-user.mak| 1 + configs/targets/ppc64-softmmu.mak | 1 + configs/targets/ppc64le-linux-user.mak | 1 + configs/targets/riscv32-linux-user.mak | 1 + configs/targets/riscv32-softmmu.mak | 1 + configs/targets/riscv64-bsd-user.mak| 1 + configs/targets/riscv64-linux-user.mak | 1 + configs/targets/riscv64-softmmu.mak | 1 + configs/targets/rx-softmmu.mak | 1 + configs/targets/s390x-linux-user.mak| 1 + configs/targets/s390x-softmmu.mak | 1 + configs/targets/sh4-linux-user.mak | 1 + configs/targets/sh4-softmmu.mak | 1 + configs/targets/sh4eb-linux-user.mak| 1 + configs/targets/sh4eb-softmmu.mak | 1 + configs/targets/sparc-linux-user.mak| 1 + configs/targets/sparc-softmmu.mak | 1 + configs/targets/sparc32plus-linux-user.mak | 1 + configs/targets/sparc64-linux-user.mak | 1 + configs/targets/sparc64-softmmu.mak | 1 + configs/targets/tricore-softmmu.mak | 1 + configs/targets/x86_64-bsd-user.mak | 1 + configs/targets/x86_64-linux-user.mak | 1 + configs/targets/x86_64-softmmu.mak | 1 + configs/targets/xtensa-linux-user.mak | 1 + configs/targets/xtensa-softmmu.mak | 1 + configs/targets/xtensaeb-linux-user.mak | 1 + configs/targets/xtensaeb-softmmu.mak| 1 + 67 files changed, 72 insertions(+) diff --git a/configs/targets/aarch64-bsd-user.mak b/configs/targets/aarch64-bsd-user.mak index 8aaa5d8c80..f99c73377a 100644 --- a/configs/targets/aarch64-bsd-user.mak +++ b/configs/targets/aarch64-bsd-user.mak @@ -1,3 +1,4 @@ TARGET_ARCH=aarch64 TARGET_BASE_ARCH=arm TARGET_XML_FILES= gdb-xml/aarch64-core.xml gdb-xml/aarch64-fpu.xml gdb-xml/aarch64-pauth.xml +TARGET_LONG_BITS=64 diff --git a/configs/targets/aarch64-linux-user.mak b/configs/targets/aarch64-linux-user.mak index 4c6570f56a..b779ac3b4a 100644 --- a/configs/targets/aarch64-linux-user.mak +++ b/configs/targets/aarch64-linux-user.mak @@ -6,3 +6,4 @@ CONFIG_SEMIHOSTING=y CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y TARGET_SYST
Patch: Sparc prevent segfault when dumping uninitialzed cpu state
Hi all, my first contribution. I checked code style, patch submission
rules and did a manual test (details on request)
Synopsis:
It's a corner case, where a segfault occurs when logging Sparc CPU state
in a partially initialized state.
No related bug report.
Open to harsh criticism ;-)
Regards,
Henk van der Laak
Patch is based off 6fccaa2fba391815308a746d68f7fa197bc93586
(origin/master) as of Sun Feb 2 11:09:10 2025 -0500
Signed-off-by: Henk van der Laak
---
target/sparc/cpu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/target/sparc/cpu.c b/target/sparc/cpu.c
index fbd38ec334..83aaa456fc 100644
--- a/target/sparc/cpu.c
+++ b/target/sparc/cpu.c
@@ -642,7 +642,12 @@ static void sparc_cpu_dump_state(CPUState *cs, FILE
*f, int flags)
x == 0 ? 'o' : (x == 1 ? 'l' : 'i'),
i, i + REGS_PER_LINE - 1);
}
- qemu_fprintf(f, TARGET_FMT_lx " ", env->regwptr[i + x * 8]);
+ /*
+ * regwptr may not be initialized yet when logging
+ * e.g. cpu_reset
+ */
+ qemu_fprintf(f, TARGET_FMT_lx " ",
+ env->regwptr ? env->regwptr[i + x * 8] : 0);
if (i % REGS_PER_LINE == REGS_PER_LINE - 1) {
qemu_fprintf(f, "\n");
}
--
2.43.0
Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation
On 1/27/25 07:57, Akihiko Odaki wrote: > On 2025/01/27 3:06, Dmitry Osipenko wrote: >> On 1/21/25 07:26, Akihiko Odaki wrote: >> ... > I feel the dependency information for virglrenderer and Mesa are more > suited for the Mesa documentation as they are not specific to QEMU and > potentially useful also for e.g., libkrun and crosvm. I think while everything is in so much flux it doesn't hurt to include in our docs. I don't know if mesa currently has a dedicated page for GPU virtualisation. >>> >>> Mesa has pages for VirGL and Venus, which can be linked from the >>> respective parts of this documentation. gfxstream is not documented but >>> I think most people will use it only for Android anyway. A documentation >>> for DRM native context will be a nice addition for Mesa. I will not >>> object if you put this information to QEMU documentation though. >> >> Adding native context doc to Mesa indeed will be a good move, as well as >> adding links to the Mesa virgl/venus pages in QEMU. >> >> RE requirements documentation, it's also a valid point that stuff like >> build flags should belong to the relevant projects. On the other hand, >> it's a common headache for a newcoming people to figure everything out >> from scratch and having more centralized documentation helps. The build >> requirements aren't cleanly documented anywhere AFAICT, and the >> requirements also differ based on VMM. I'll update and keep this patch >> in v6, the requirements info should stay actual for a next couple years >> IMO. Let's discuss it further in v6 if more objections will arise. >> > > I think it's fine to require one click to reach the relevant documentation. > > How do the requirements described here vary with VMM? Requirements don't vary much. For example virglrenderer minigbm support is mandatory for crosvm, while for QEMU it's not. > I'm not entirely sure the documentation will stay as is for that long. > The requirements of Intel native context refer to merge requests that > can be merged sooner or later. Asahi may need more updates if you > document it too because its DRM ABI is still unstable. The unstable parts of course will need to be updated sooner, but the stable should be solid for years. I expect that about a year later requirements will need to be revisited. -- Best regards, Dmitry
Re: [PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements
On 1/31/25 20:19, Dmitry Osipenko wrote: > On 1/29/25 04:18, Gurchetan Singh wrote: >> On Sun, Jan 26, 2025 at 12:14 PM Dmitry Osipenko < >> dmitry.osipe...@collabora.com> wrote: >> >>> From: Alex Bennée >>> >>> This attempts to tidy up the VirtIO GPU documentation to make the list >>> of requirements clearer. There are still a lot of moving parts and the >>> distros have some catching up to do before this is all handled >>> automatically. >>> >>> Signed-off-by: Alex Bennée >>> Cc: Sergio Lopez Pascual >>> Signed-off-by: Dmitry Osipenko >>> [dmitry.osipe...@collabora.com: Extended and corrected doc] >>> --- >>> docs/system/devices/virtio-gpu.rst | 107 - >>> 1 file changed, 106 insertions(+), 1 deletion(-) >>> >>> diff --git a/docs/system/devices/virtio-gpu.rst >>> b/docs/system/devices/virtio-gpu.rst >>> index ea3eb052df3c..b3db984ff2d3 100644 >>> --- a/docs/system/devices/virtio-gpu.rst >>> +++ b/docs/system/devices/virtio-gpu.rst >>> @@ -5,7 +5,9 @@ virtio-gpu >>> == >>> >>> This document explains the setup and usage of the virtio-gpu device. >>> -The virtio-gpu device paravirtualizes the GPU and display controller. >>> +The virtio-gpu device provides a GPU and display controller >>> +paravirtualized using VirtIO. It supports a number of different modes >>> +from simple 2D displays to fully accelerated 3D graphics. >>> >>> Linux kernel support >>> >>> @@ -13,6 +15,24 @@ Linux kernel support >>> virtio-gpu requires a guest Linux kernel built with the >>> ``CONFIG_DRM_VIRTIO_GPU`` option. >>> >>> +Dependencies >>> + >>> + >>> +.. note:: >>> + GPU virtualisation is still an evolving field. Depending on the mode >>> + you are running you may need to override distribution supplied >>> + libraries with more recent versions or enable build options. >>> + >>> + Depending on the mode there are a number of requirements the host must >>> + meet to be able to be able to support guests. For 3D acceleration QEMU >>> + must be able to access the hosts GPU and for the best performance be >>> + able to reliably share GPU memory with the guest. >>> + >>> + Virtio-gpu requires a guest Linux kernel built with the >>> + ``CONFIG_DRM_VIRTIO_GPU`` option. For 3D accelerations you >>> + will need support from guest Mesa configured for whichever encapsulation >>> + you need. >>> + >>> QEMU virtio-gpu variants >>> >>> >>> @@ -56,6 +76,16 @@ on typical modern Linux distributions. >>> .. _Mesa: https://www.mesa3d.org/ >>> .. _SwiftShader: https://github.com/google/swiftshader >>> >>> +.. list-table:: Host Requirements >>> + :header-rows: 1 >>> + >>> + * - Mode >>> +- Kernel >>> +- Userspace >>> + * - virtio-gpu >>> +- Framebuffer enabled >>> +- GTK or SDL display >>> + >>> virtio-gpu virglrenderer >>> >>> >>> @@ -94,6 +124,61 @@ of virtio-gpu host memory window. This is typically >>> between 256M and 8G. >>> >>> .. _drm: >>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm >>> >>> +.. list-table:: Host Requirements >>> + :header-rows: 1 >>> + >>> + * - Mode >>> +- Kernel >>> +- Userspace >>> + * - virtio-gpu-gl (OpenGL pass-through) >>> +- GPU enabled >>> +- libvirglrenderer (virgl support) >>> + * - virtio-gpu-gl (Vulkan pass-through) >>> +- Linux 6.13+ >>> +- libvirglrenderer (>= 1.0.0, venus support) >>> + * - virtio-gpu-gl (vDRM native context/AMD) >>> +- Linux 6.13+ >>> +- libvirglrenderer (>= 1.1.0, DRM renderer support) >>> + * - virtio-gpu-gl (vDRM native context/Freedreno) >>> +- Linux 6.4+ >>> +- libvirglrenderer (>= 1.0.0, DRM renderer support) >>> + * - virtio-gpu-gl (vDRM native context/Intel i915) >>> +- Linux 6.13+ >>> +- libvirglrenderer (`mr1384`_, DRM renderer support) >>> + * - virtio-gpu-gl (vDRM native context/Asahi) >>> +- Linux 6.13+ >>> +- libvirglrenderer (`mr1274`_, DRM renderer support) >>> + >>> +.. _mr1384: >>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 >>> +.. _mr1274: >>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274 >>> + >>> +.. list-table:: Guest Requirements >>> + :header-rows: 1 >>> + >>> + * - Mode >>> +- Mesa Version >>> +- Mesa build flags >>> + * - virtio-gpu-gl (OpenGL pass-through) >>> +- 20.3.0+ >>> +- -Dgallium-drivers=virgl >>> + * - virtio-gpu-gl (Vulkan pass-through) >>> +- 24.2.0+ >>> +- -Dvulkan-drivers=virtio >>> + * - virtio-gpu-gl (vDRM native context/AMD) >>> +- 25.0.0+ >>> +- -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true >>> + * - virtio-gpu-gl (vDRM native context/Freedreno) >>> +- 23.1.0+ >>> +- -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno >>> + * - virtio-gpu-gl (vDRM native context/Intel i915) >>> +- `mr29870`_ >>> +- -Dgallium-drivers=iris -Dvulkan-drivers=intel >>> -Dintel-virtio-e
Re: [PATCH v5] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support
Hey Ani! On 28.01.25 22:31, Ani Sinha wrote: VM firmware update is a mechanism where the virtual machines can use their preferred and trusted firmware image in their execution environment without having to depend on a untrusted party to provide the firmware bundle. This is particularly useful for confidential virtual machines that are deployed in the cloud where the tenant and the cloud provider are two different entities. In this scenario, virtual machines can bring their own trusted firmware image bundled as a part of their filesystem (using UKIs for example[1]) and then use this hypervisor interface to update to their trusted firmware image. This also allows the guests to have a consistent measurements on the firmware image. This change introduces support for the fw-cfg based hypervisor interface and the corresponding device.The change also includes the specification document for this interface. The interface is made generic enough so that guests are free to use their own ABI to pass required information between initial and trusted execution contexts (where they are running their own trusted firmware image) without the hypervisor getting involved in between. For pc machines, it implements support for copying firmware image from the guest source physical address specifiied by the guest where the guest loaded the next stage firmware. Currently, this device is only supported for pc machines. Hence, the device is not initialized for other machine types. Trying to initialize it for arm for example will lead to failure: $ ./qemu-system-arm -device vmfwupdate -machine virt qemu-system-arm: -device vmfwupdate: This machine does not support vmfwupdate device Functional and qtests has been added to test basic device operations and fw-cfg files. [1] See systemd pull requests https://github.com/systemd/systemd/pull/35091 and https://github.com/systemd/systemd/pull/35281 for some discussions on how we can bundle firmware image within an UKI. CC: Alex Graf CC: Paolo Bonzini CC: Gerd Hoffman CC: Igor Mammedov CC: Vitaly Kuznetsov Signed-off-by: Ani Sinha --- MAINTAINERS | 11 ++ docs/specs/index.rst| 1 + docs/specs/vmfwupdate.rst | 119 hw/core/machine.c | 2 + hw/i386/pc.c| 55 hw/misc/meson.build | 2 + hw/misc/vmfwupdate.c| 212 include/hw/misc/vmfwupdate.h| 105 ++ tests/functional/meson.build| 2 + tests/functional/test_vmfwupdate.py | 82 +++ tests/qtest/meson.build | 1 + tests/qtest/vmfwupdate-test.c | 67 + 12 files changed, 659 insertions(+) create mode 100644 docs/specs/vmfwupdate.rst create mode 100644 hw/misc/vmfwupdate.c create mode 100644 include/hw/misc/vmfwupdate.h create mode 100644 tests/functional/test_vmfwupdate.py create mode 100644 tests/qtest/vmfwupdate-test.c changelogs: v5: Alex's input, add qtest and functional test. guest reset full support for x86. More testing is required but will need support of DMA based fw-cfw file write capability. This has been added in the patchset https://patchwork.ozlabs.org/project/qemu-devel/list/?series=441003 Cover letter: https://patchwork.ozlabs.org/project/qemu-devel/cover/20250120043847.954881-1-anisi...@redhat.com/ . For more comprehensive testing of this patch, I am requesting inputs and suggestions. CI pipeline is green - so no regressions. https://gitlab.com/anisinha/qemu/-/pipelines/1646036807 v4: remove delay in functional test. Not needed now. v3: inputs from Gerd and Phil taken into account. One basic functional test added. Spec doc updated as per Gerd's suggestions. v2: do not allow changing bios region if advertized size is 0 (non-pc platforms). Thanks a lot for sending out this new version. It's exciting to see it slowly taking shape :). Now that we have the first user included, it's a lot easier to reason about the flow of the code. diff --git a/MAINTAINERS b/MAINTAINERS index 7be3d8f431..370bd4d16b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2559,6 +2559,17 @@ F: include/hw/acpi/vmgenid.h F: docs/specs/vmgenid.rst F: tests/qtest/vmgenid-test.c +VM Firmware Update +M: Ani Sinha +M: Alex Graf +M: Paolo Bonzini +S: Maintained +F: hw/misc/vmfwupdate.c +F: include/hw/misc/vmfwupdate.h +F: docs/specs/vmfwupdate.rst +F: tests/qtest/vmfwupdate-test.c +F: tests/functional/test_vmfwupdate.py + LED M: Philippe Mathieu-Daudé S: Maintained diff --git a/docs/specs/index.rst b/docs/specs/index.rst index d7675cebc2..8d78b647f2 100644 --- a/docs/specs/index.rst +++ b/docs/specs/index.rst @@ -34,6 +34,7 @@ guest hardware that is specific to QEMU. virt-ctlr vmcoreinfo vmgenid + vmfwupdate rapl-msr rocker riscv-iommu diff --git a/docs/specs/vmfwupdate.rst b/docs/specs/vmfwupdate.rst new file mode 100644 index
Re: [PATCH] target/sparc: fake UltraSPARC T1 PCR and PIC registers
On 1/31/25 13:44, Artyom Tarasenko wrote:
fake access to
PCR Performance Control Register
and
PIC Performance Instrumentation Counter.
Ignore writes in privileged mode, and return 0 on reads.
This allows booting Tribblix, MilaX and v9os under Niagara target.
Signed-off-by: Artyom Tarasenko
---
target/sparc/insns.decode | 7 ++-
target/sparc/translate.c | 20
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/target/sparc/insns.decode b/target/sparc/insns.decode
index 989c20b44a..504147563c 100644
--- a/target/sparc/insns.decode
+++ b/target/sparc/insns.decode
@@ -96,7 +96,10 @@ CALL01 i:s30
RDTICK 10 rd:5 101000 00100 0 0
RDPC10 rd:5 101000 00101 0 0
RDFPRS 10 rd:5 101000 00110 0 0
-RDASR17 10 rd:5 101000 10001 0 0
+{
+ RDASR17 10 rd:5 101000 10001 0 0
+ RDPIC 10 rd:5 101000 10001 0 0
+}
RDGSR 10 rd:5 101000 10011 0 0
RDSOFTINT 10 rd:5 101000 10110 0 0
RDTICK_CMPR 10 rd:5 101000 10111 0 0
@@ -114,6 +117,8 @@ CALL01 i:s30
WRCCR 10 00010 11 . . . @n_r_ri
WRASI 10 00011 11 . . . @n_r_ri
WRFPRS 10 00110 11 . . . @n_r_ri
+WRPCR 10 1 11 01000 0 0
+WRPIC 10 10001 11 01000 0 0
{
WRGSR 10 10011 11 . . . @n_r_ri
WRPOWERDOWN 10 10011 11 . . . @n_r_ri
diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index 7e5c7351cb..285c9b0a59 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -2882,6 +2882,15 @@ static TCGv do_rd_leon3_config(DisasContext *dc, TCGv
dst)
TRANS(RDASR17, ASR17, do_rd_special, true, a->rd, do_rd_leon3_config)
+static TCGv do_rdpic(DisasContext *dc, TCGv dst)
+{
+tcg_gen_movi_tl(dst, 0UL);
+return dst;
+}
return tcg_constant_tl(0);
+
+TRANS(RDPIC, HYPV, do_rd_special, true, a->rd, do_rdpic)
Surely reads are not allowed in user mode.
r~
Re: [PATCH] target/sparc: fake UltraSPARC T1 PCR and PIC registers
On 2/2/25 13:46, Richard Henderson wrote:
On 1/31/25 13:44, Artyom Tarasenko wrote:
fake access to
PCR Performance Control Register
and
PIC Performance Instrumentation Counter.
Ignore writes in privileged mode, and return 0 on reads.
This allows booting Tribblix, MilaX and v9os under Niagara target.
Signed-off-by: Artyom Tarasenko
---
target/sparc/insns.decode | 7 ++-
target/sparc/translate.c | 20
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/target/sparc/insns.decode b/target/sparc/insns.decode
index 989c20b44a..504147563c 100644
--- a/target/sparc/insns.decode
+++ b/target/sparc/insns.decode
@@ -96,7 +96,10 @@ CALL 01 i:s30
RDTICK 10 rd:5 101000 00100 0 0
RDPC 10 rd:5 101000 00101 0 0
RDFPRS 10 rd:5 101000 00110 0 0
- RDASR17 10 rd:5 101000 10001 0 0
+ {
+ RDASR17 10 rd:5 101000 10001 0 0
+ RDPIC 10 rd:5 101000 10001 0 0
+ }
RDGSR 10 rd:5 101000 10011 0 0
RDSOFTINT 10 rd:5 101000 10110 0 0
RDTICK_CMPR 10 rd:5 101000 10111 0 0
@@ -114,6 +117,8 @@ CALL 01 i:s30
WRCCR 10 00010 11 . . . @n_r_ri
WRASI 10 00011 11 . . . @n_r_ri
WRFPRS 10 00110 11 . . . @n_r_ri
+ WRPCR 10 1 11 01000 0 0
+ WRPIC 10 10001 11 01000 0 0
{
WRGSR 10 10011 11 . . . @n_r_ri
WRPOWERDOWN 10 10011 11 . . . @n_r_ri
diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index 7e5c7351cb..285c9b0a59 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -2882,6 +2882,15 @@ static TCGv do_rd_leon3_config(DisasContext *dc, TCGv
dst)
TRANS(RDASR17, ASR17, do_rd_special, true, a->rd, do_rd_leon3_config)
+static TCGv do_rdpic(DisasContext *dc, TCGv dst)
+{
+ tcg_gen_movi_tl(dst, 0UL);
+ return dst;
+}
return tcg_constant_tl(0);
+
+TRANS(RDPIC, HYPV, do_rd_special, true, a->rd, do_rdpic)
Surely reads are not allowed in user mode.
You might as well implement RDPCR as well, which *is* privileged.
Since PCR=0, then RDPCR is allowed.
It might be worthwhile to implement PCR, or at least PCR.PRIV.
r~
r~
Re: [PATCH 1/1] target/riscv: log guest errors when reserved bits are set in PTEs
On 2/2/25 2:15 AM, julia wrote:
For instance, QEMUs newer than b6ecc63c569bb88c0fcadf79fb92bf4b88aefea8
would silently treat this akin to an unmapped page (as required by the
RISC-V spec, admittedly). However, not all hardware platforms do (e.g.
CVA6) which leads to an apparent QEMU bug.
Instead, log a guest error so that in future, incorrectly set up page
tables can be debugged without bisecting QEMU.
Signed-off-by: julia
Usually the author line consists of a full name. You can set the author name by
using 'git config --global user.name '. To amend an existing patch
you can use:
git commit --amend --author="Full Author Name "
---
target/riscv/cpu_helper.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index e1dfc4ecbf..87adf16a49 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1226,14 +1226,27 @@ restart:
ppn = pte >> PTE_PPN_SHIFT;
} else {
if (pte & PTE_RESERVED) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: reserved bits set in PTE: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x%" PRIx64 "\n",
+ __func__, pte_addr, pte);
This will fail to compile for riscv32 (riscv32-softmmu configure target) with
errors
like this:
../target/riscv/cpu_helper.c: In function ‘get_physical_address’:
../target/riscv/cpu_helper.c:1230:48: error: format ‘%lx’ expects argument of
type ‘long unsigned int’, but argument 4 has type ‘target_ulong’ {aka ‘unsigned
int’} [-Werror=format=]
1230 | qemu_log_mask(LOG_GUEST_ERROR, "%s: reserved bits set in
PTE: "
|
^~~~
1231 | "addr: 0x%" HWADDR_PRIx " pte: 0x%" PRIx64
"\n",
1232 | __func__, pte_addr, pte);
| ~~~
| |
| target_ulong {aka
unsigned int}
/home/danielhb/work/qemu/include/qemu/log.h:57:22: note: in definition of macro
‘qemu_log_mask’
57 | qemu_log(FMT, ## __VA_ARGS__); \
| ^~~
This happens because 'pte' is a 'target_ulong' type that, for riscv32, will be
interpreted as uint32_t while the FMT being used is PRIx64.
You can fix it by using TARGET_FMT_lx instead of PRIx64:
+++ b/target/riscv/cpu_helper.c
@@ -1228,7 +1228,7 @@ restart:
} else {
if (pte & PTE_RESERVED) {
qemu_log_mask(LOG_GUEST_ERROR, "%s: reserved bits set in PTE: "
- "addr: 0x%" HWADDR_PRIx " pte: 0x%" PRIx64 "\n",
+ "addr: 0x%" HWADDR_PRIx " pte:" TARGET_FMT_lx
"\n",
__func__, pte_addr, pte);
return TRANSLATE_FAIL;
This change is needed in all qemu_log_mask() entries added. Thanks,
Daniel
return TRANSLATE_FAIL;
}
if (!pbmte && (pte & PTE_PBMT)) {
+/* Reserved without Svpbmt. */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: PBMT bits set in PTE, "
+ "and Svpbmt extension is disabled: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x%" PRIx64 "\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
if (!riscv_cpu_cfg(env)->ext_svnapot && (pte & PTE_N)) {
+/* Reserved without Svnapot extension */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: N bit set in PTE, "
+ "and Svnapot extension is disabled: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x%" PRIx64 "\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
@@ -1244,14 +1257,19 @@ restart:
/* Invalid PTE */
return TRANSLATE_FAIL;
}
+
if (pte & (PTE_R | PTE_W | PTE_X)) {
goto leaf;
}
-/* Inner PTE, continue walking */
if (pte & (PTE_D | PTE_A | PTE_U | PTE_ATTR)) {
+/* D, A, and U bits are reserved in non-leaf/inner PTEs */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: D, A, or U bits set in non-leaf
PTE: "
+ "addr: 0x%" HWADDR_PRIx " pte: 0x%" PRIx64 "\n",
+ __func__, pte_addr, pte);
return TRANSLATE_FAIL;
}
+/* Inner PTE, continue walking */
base = ppn << PGSHIFT;
}
@@ -1261,10 +1279,17 @@ restart:
leaf:
if (ppn & ((1ULL << ptshift) - 1)) {
/* Misaligned PPN */
+qemu_log_mask(LOG_GUEST_ERROR, "%s: PPN bits in PTE is m
Re: [PATCH qemu] target/riscv: Check ext_zca for misaligned return address of mret/sret.
On Thu, Jan 16, 2025 at 1:32 PM ~yuming wrote:
>
> From: Yu-Ming Chang
>
> Only check misa.C will cause issues when ext_zca is enabled without
> misa.C being set. For example, only enable ext_zce.
Thanks for the patch!
I'm not clear what the problem is and what this commit fixes. Do you
mind updating this to clearly describe what you are fixing?
>
> Signed-off-by: Yu-Ming Chang
> ---
> target/riscv/op_helper.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
> index eddedacf4b..891002f954 100644
> --- a/target/riscv/op_helper.c
> +++ b/target/riscv/op_helper.c
> @@ -269,8 +269,10 @@ target_ulong helper_sret(CPURISCVState *env)
> }
>
> target_ulong retpc = env->sepc;
> -if (!riscv_has_ext(env, RVC) && (retpc & 0x3)) {
> -riscv_raise_exception(env, RISCV_EXCP_INST_ADDR_MIS, GETPC());
> +if (!riscv_has_ext(env, RVC) && !env_archcpu(env)->cfg.ext_zca) {
I think you can just check ext_zca, as misa.C enables ext_zca
Alistair
> +if ((retpc & 0x3) != 0) {
> +riscv_raise_exception(env, RISCV_EXCP_INST_ADDR_MIS, GETPC());
> +}
> }
>
> if (get_field(env->mstatus, MSTATUS_TSR) && !(env->priv >= PRV_M)) {
> @@ -328,8 +330,10 @@ target_ulong helper_mret(CPURISCVState *env)
> }
>
> target_ulong retpc = env->mepc;
> -if (!riscv_has_ext(env, RVC) && (retpc & 0x3)) {
> -riscv_raise_exception(env, RISCV_EXCP_INST_ADDR_MIS, GETPC());
> +if (!riscv_has_ext(env, RVC) && !env_archcpu(env)->cfg.ext_zca) {
> +if ((retpc & 0x3) != 0) {
> +riscv_raise_exception(env, RISCV_EXCP_INST_ADDR_MIS, GETPC());
> +}
> }
>
> uint64_t mstatus = env->mstatus;
> --
> 2.45.2
>
Re: [RFC 2/4] spdm: add spdm storage transport virtual header
On Tue, 2025-01-28 at 09:03 +0100, Klaus Jensen wrote:
> On Jan 15 02:16, Wilfred Mallawa wrote:
> > On Fri, 2025-01-10 at 10:04 +0100, Klaus Jensen wrote:
> > > On Jan 7 15:29, Wilfred Mallawa via wrote:
> > > > This header contains the transport encoding for an SPDM message
> > > > that
> > > > uses the SPDM over Storage transport as defined by the DMTF
> > > > DSP0286.
> > > >
> > > > Signed-off-by: Wilfred Mallawa
> > > > ---
> > > > include/system/spdm-socket.h | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/include/system/spdm-socket.h
> > > > b/include/system/spdm-
> > > > socket.h
> > > > index 2b7d03f82d..fc007e5b48 100644
> > > > --- a/include/system/spdm-socket.h
> > > > +++ b/include/system/spdm-socket.h
> > > > @@ -88,6 +88,18 @@ bool spdm_socket_send(const int socket,
> > > > uint32_t
> > > > socket_cmd,
> > > > */
> > > > void spdm_socket_close(const int socket, uint32_t
> > > > transport_type);
> > > >
> > > > +/*
> > > > + * Defines the transport encoding for SPDM, this information
> > > > shall
> > > > be passed
> > > > + * down to the SPDM server, when conforming to the SPDM over
> > > > Storage standard
> > > > + * as defined by DSP0286.
> > > > + */
> > > > +typedef struct QEMU_PACKED {
> > > > + uint8_t security_protocol;
> > > > + uint16_t security_protocol_specific;
> > > > + bool inc_512;
> > > > + uint32_t length;
> > > > +} StorageSpdmTransportHeader;
> > >
> > > Does it make sense to pack a bool? Is this defined by the SPDM
> > > server
> > > in
> > > use? I can't find the definition of this header anywhere.
> > >
> > This is essentially a virtual header containing essential storage
> > transport data as per DSP0286. For example, this is defined in the
> > upstream effort for
> > `libspmd` to add storage binding support [1] and in DSP0286 [2],
> > this
> > is defined in section 5.1.1.
> >
> > Current implementation of the SPDM server (i.e in `spdm-utils` only
> > one
> > to have support for storage), will just pass this header to
> > `libspdm`
> > to be decoded. Once decoded by `libspdm`, `spdm-utils`/server will
> > contextually check for validity of the message.
> >
>
> OK, understood.
>
> > As for inc_512, it just need to be yes or no, is there a better way
> > to
> > represent that here?
>
> It's a byte, right? Then I think using uint8_t is more clear here.
As per, SCSI Primary Commands - 6 (SPC-6) it's a single bit to
indicate weather it's set or not, hence why I thought a boolean might
make more sense here.
[PATCH v7 03/10] virtio-gpu: Handle virgl fence creation errors
Print out error messages when virgl fence creation fails to aid debugging
of the fence-related bugs.
Reviewed-by: Akihiko Odaki
Acked-by: Michael S. Tsirkin
Tested-by: Alex Bennée
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-virgl.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 145a0b387956..2eb6aaab4e84 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -872,6 +872,7 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
bool cmd_suspended = false;
+int ret;
VIRTIO_GPU_FILL_CMD(cmd->cmd_hdr);
@@ -970,7 +971,17 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
}
trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
-virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
+
+/*
+ * Unlike other virglrenderer functions, this one returns a positive
+ * error code.
+ */
+ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0);
+if (ret) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: virgl_renderer_create_fence error: %s",
+ __func__, strerror(ret));
+}
}
static void virgl_write_fence(void *opaque, uint32_t fence)
--
2.47.1
[PATCH 1/1] vhost-scsi: support VIRTIO_SCSI_F_HOTPLUG
So far there isn't way to test host kernel vhost-scsi event queue path,
because VIRTIO_SCSI_F_HOTPLUG isn't supported by QEMU.
virtio-scsi.c and vhost-user-scsi.c already support VIRTIO_SCSI_F_HOTPLUG
as property "hotplug".
Add support to vhost-scsi.c to help evaluate and test event queue.
To test the feature:
1. Create vhost-scsi target with targetcli.
targetcli /backstores/fileio create name=storage file_or_dev=disk01.raw
targetcli /vhost create naa.1123451234512345
targetcli /vhost/naa.1123451234512345/tpg1/luns create
/backstores/fileio/storage
2. Create QEMU instance with vhost-scsi.
-device vhost-scsi-pci,wwpn=naa.1123451234512345,hotplug=true
3. Once guest bootup, hotplug a new LUN from host.
targetcli /backstores/fileio create name=storage02 file_or_dev=disk02.raw
targetcli /vhost/naa.1123451234512345/tpg1/luns create
/backstores/fileio/storage02
Signed-off-by: Dongli Zhang
---
hw/scsi/vhost-scsi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index 8039d13fd9..d3a260f6a7 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -359,6 +359,9 @@ static const Property vhost_scsi_properties[] = {
DEFINE_PROP_BIT64("t10_pi", VHostSCSICommon, host_features,
VIRTIO_SCSI_F_T10_PI,
false),
+DEFINE_PROP_BIT64("hotplug", VHostSCSICommon, host_features,
+ VIRTIO_SCSI_F_HOTPLUG,
+ false),
DEFINE_PROP_BOOL("migratable", VHostSCSICommon, migratable, false),
DEFINE_PROP_BOOL("worker_per_virtqueue", VirtIOSCSICommon,
conf.worker_per_virtqueue, false),
--
2.39.3
Re: [PATCH] MAINTAINERS: Remove Bin Meng from RISC-V maintainers
On Tue, Jan 28, 2025 at 4:05 PM Alistair Francis wrote: > > Bin Meng has been a long time contributor and maintainer for QEMU RISC-V > and has been very beneficial to the RISC-V ecosystem. > > Unfortunately his email has started to bounce so this patch is removing > them from MAINTAINERS. If in the future Bin Meng wants to return we will > happily re-add them. > > Note that I'm not removing Bin Meng as a "SD (Secure Card)" maintainer. > > Signed-off-by: Alistair Francis Thanks! Applied to riscv-to-apply.next Alistair > --- > MAINTAINERS | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7be3d8f431..a0e305aa99 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -318,7 +318,6 @@ F: tests/functional/test_ppc_74xx.py > RISC-V TCG CPUs > M: Palmer Dabbelt > M: Alistair Francis > -M: Bin Meng > R: Weiwei Li > R: Daniel Henrique Barboza > R: Liu Zhiwei > @@ -1599,7 +1598,6 @@ F: include/hw/riscv/opentitan.h > F: include/hw/*/ibex_*.h > > Microchip PolarFire SoC Icicle Kit > -M: Bin Meng > L: qemu-ri...@nongnu.org > S: Supported > F: docs/system/riscv/microchip-icicle-kit.rst > @@ -1626,7 +1624,6 @@ F: include/hw/char/shakti_uart.h > > SiFive Machines > M: Alistair Francis > -M: Bin Meng > M: Palmer Dabbelt > L: qemu-ri...@nongnu.org > S: Supported > @@ -3721,7 +3718,7 @@ S: Orphan > F: hw/i386/amd_iommu.? > > OpenSBI Firmware > -M: Bin Meng > +L: qemu-ri...@nongnu.org > S: Supported > F: pc-bios/opensbi-* > F: .gitlab-ci.d/opensbi.yml > -- > 2.48.1 >
Re: [PATCH v5 3/7] target/riscv: Add support for Control Transfer Records extension CSRs.
On Thu, Dec 5, 2024 at 9:36 PM Rajnesh Kanwal wrote:
>
> This commit adds support for [m|s|vs]ctrcontrol, sctrstatus and
> sctrdepth CSRs handling.
>
> Signed-off-by: Rajnesh Kanwal
Acked-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu.h | 5 ++
> target/riscv/cpu_cfg.h | 2 +
> target/riscv/csr.c | 144
> +
> 3 files changed, 151 insertions(+)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index
> 903268626374474306f0e0259f37128326b354d4..da14ac2f874b81d3f01bc31b0064d020f2dbdf61
> 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -305,6 +305,11 @@ struct CPUArchState {
> target_ulong mcause;
> target_ulong mtval; /* since: priv-1.10.0 */
>
> +uint64_t mctrctl;
> +uint32_t sctrdepth;
> +uint32_t sctrstatus;
> +uint64_t vsctrctl;
> +
> /* Machine and Supervisor interrupt priorities */
> uint8_t miprio[64];
> uint8_t siprio[64];
> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
> index
> ae2b019703fe4849eb7f264b4d90743d4c013b86..e365a368d71a695b1b99c3b6ae330347143d3422
> 100644
> --- a/target/riscv/cpu_cfg.h
> +++ b/target/riscv/cpu_cfg.h
> @@ -130,6 +130,8 @@ struct RISCVCPUConfig {
> bool ext_zvfhmin;
> bool ext_smaia;
> bool ext_ssaia;
> +bool ext_smctr;
> +bool ext_ssctr;
> bool ext_sscofpmf;
> bool ext_smepmp;
> bool rvv_ta_all_1s;
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index
> a77b6ed4c9f35fe25f0901c290cac8a666a48c27..a399d55740c7259cd1c1d893687541e23ea3ce52
> 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -649,6 +649,48 @@ static RISCVException pointer_masking(CPURISCVState
> *env, int csrno)
> return RISCV_EXCP_ILLEGAL_INST;
> }
>
> +/*
> + * M-mode:
> + * Without ext_smctr raise illegal inst excep.
> + * Otherwise everything is accessible to m-mode.
> + *
> + * S-mode:
> + * Without ext_ssctr or mstateen.ctr raise illegal inst excep.
> + * Otherwise everything other than mctrctl is accessible.
> + *
> + * VS-mode:
> + * Without ext_ssctr or mstateen.ctr raise illegal inst excep.
> + * Without hstateen.ctr raise virtual illegal inst excep.
> + * Otherwise allow sctrctl (vsctrctl), sctrstatus, 0x200-0x2ff entry range.
> + * Always raise illegal instruction exception for sctrdepth.
> + */
> +static RISCVException ctr_mmode(CPURISCVState *env, int csrno)
> +{
> +/* Check if smctr-ext is present */
> +if (riscv_cpu_cfg(env)->ext_smctr) {
> +return RISCV_EXCP_NONE;
> +}
> +
> +return RISCV_EXCP_ILLEGAL_INST;
> +}
> +
> +static RISCVException ctr_smode(CPURISCVState *env, int csrno)
> +{
> +const RISCVCPUConfig *cfg = riscv_cpu_cfg(env);
> +
> +if (!cfg->ext_smctr && !cfg->ext_ssctr) {
> +return RISCV_EXCP_ILLEGAL_INST;
> +}
> +
> +RISCVException ret = smstateen_acc_ok(env, 0, SMSTATEEN0_CTR);
> +if (ret == RISCV_EXCP_NONE && csrno == CSR_SCTRDEPTH &&
> +env->virt_enabled) {
> +return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
> +}
> +
> +return ret;
> +}
> +
> static RISCVException aia_hmode(CPURISCVState *env, int csrno)
> {
> int ret;
> @@ -3157,6 +3199,10 @@ static RISCVException write_mstateen0(CPURISCVState
> *env, int csrno,
> wr_mask |= (SMSTATEEN0_AIA | SMSTATEEN0_IMSIC);
> }
>
> +if (riscv_cpu_cfg(env)->ext_ssctr) {
> +wr_mask |= SMSTATEEN0_CTR;
> +}
> +
> return write_mstateen(env, csrno, wr_mask, new_val);
> }
>
> @@ -3196,6 +3242,10 @@ static RISCVException write_mstateen0h(CPURISCVState
> *env, int csrno,
> wr_mask |= SMSTATEEN0_P1P13;
> }
>
> +if (riscv_cpu_cfg(env)->ext_ssctr) {
> +wr_mask |= SMSTATEEN0_CTR;
> +}
> +
> return write_mstateenh(env, csrno, wr_mask, new_val);
> }
>
> @@ -3250,6 +3300,10 @@ static RISCVException write_hstateen0(CPURISCVState
> *env, int csrno,
> wr_mask |= (SMSTATEEN0_AIA | SMSTATEEN0_IMSIC);
> }
>
> +if (riscv_cpu_cfg(env)->ext_ssctr) {
> +wr_mask |= SMSTATEEN0_CTR;
> +}
> +
> return write_hstateen(env, csrno, wr_mask, new_val);
> }
>
> @@ -3289,6 +3343,10 @@ static RISCVException write_hstateen0h(CPURISCVState
> *env, int csrno,
> {
> uint64_t wr_mask = SMSTATEEN_STATEEN | SMSTATEEN0_HSENVCFG;
>
> +if (riscv_cpu_cfg(env)->ext_ssctr) {
> +wr_mask |= SMSTATEEN0_CTR;
> +}
> +
> return write_hstateenh(env, csrno, wr_mask, new_val);
> }
>
> @@ -4002,6 +4060,86 @@ static RISCVException write_satp(CPURISCVState *env,
> int csrno,
> return RISCV_EXCP_NONE;
> }
>
> +static RISCVException rmw_sctrdepth(CPURISCVState *env, int csrno,
> +target_ulong *ret_val,
> +target_ulong new_val, target_ulong
> wr_mask)
> +{
> +uint64_t mask = wr_mask & SCTRDEPTH_MASK;
> +
> +if (ret_val) {
> +*ret_val = env->sctrdepth;
> +}
> +
> +
RE: Call for GSoC internship project ideas
+ Troy * Email Confidentiality Notice 免責聲明: 本信件(或其附件)可能包含機密資訊，並受法律保護。如 台端非指定之收件者，請以電子郵件通知本電子郵件之發送者, 並請立即刪除本電子郵件及其附件和銷毀所有複印件。謝謝您的合作! DISCLAIMER: This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you. > -Original Message- > From: Stefano Garzarella > Sent: Thursday, January 30, 2025 1:44 AM > To: Rust-VMM Mailing List > Cc: Stefan Hajnoczi ; qemu-devel > ; kvm ; Richard Henderson > ; Philippe Mathieu-Daudé > ; Peter Maydell ; Paolo > Bonzini ; Thomas Huth ; Daniel P. > Berrange ; Pierrick Bouvier > ; Alex Bennee ; > Akihiko Odaki ; Zhao Liu ; > Bibo Mao ; Jamin Lin ; > Cédric Le Goater ; Fabiano Rosas ; > Palmer Dabbelt ; Eugenio Pérez > ; Hanna Reitz > Subject: Re: Call for GSoC internship project ideas > > +Cc rust-vmm ML, since in past years we have used QEMU as an umbrella > project for rust-vmm ideas for GSoC. > > Thanks, > Stefano > > On Tue, 28 Jan 2025 at 17:17, Stefan Hajnoczi wrote: > > > > Dear QEMU and KVM communities, > > QEMU will apply for the Google Summer of Code internship program again > > this year. Regular contributors can submit project ideas that they'd > > like to mentor by replying to this email by February 7th. > > > > About Google Summer of Code > > - > > GSoC (https://summerofcode.withgoogle.com/) offers paid open source > > remote work internships to eligible people wishing to participate in > > open source development. QEMU has been doing internship for many > > years. Our mentors have enjoyed helping talented interns make their > > first open source contributions and some former interns continue to > > participate today. > > > > Who can mentor > > -- > > Regular contributors to QEMU and KVM can participate as mentors. > > Mentorship involves about 5 hours of time commitment per week to > > communicate with the intern, review their patches, etc. Time is also > > required during the intern selection phase to communicate with > > applicants. Being a mentor is an opportunity to help someone get > > started in open source development, will give you experience with > > managing a project in a low-stakes environment, and a chance to > > explore interesting technical ideas that you may not have time to > > develop yourself. > > > > How to propose your idea > > -- > > Reply to this email with the following project idea template filled in: > > > > === TITLE === > > > > '''Summary:''' Short description of the project > > > > Detailed description of the project that explains the general idea, > > including a list of high-level tasks that will be completed by the > > project, and provides enough background for someone unfamiliar with > > the code base to research the idea. Typically 2 or 3 paragraphs. > > > > '''Links:''' > > * Links to mailing lists threads, git repos, or web sites > > > > '''Details:''' > > * Skill level: beginner or intermediate or advanced > > * Language: C/Python/Rust/etc > > > > More information > > -- > > You can find out about the process we follow here: > > Video: https://www.youtube.com/watch?v=xNVCX7YMUL8 > > Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf > > > > The QEMU wiki page for GSoC 2024 is now available: > > https://wiki.qemu.org/Google_Summer_of_Code_2025 > > > > What about Outreachy? > > --- > > We have struggled to find sponsors for the Outreachy internship > > program (https://www.outreachy.org/) in recent years. If you or your > > organization would like to sponsor an Outreachy internship, please get > > in touch. > > > > Thanks, > > Stefan > >
Re: Patch: Sparc prevent segfault when dumping uninitialzed cpu state
On 2/2/25 19:14, Henk van der Laak (LaakSoft) via wrote: Hi all, my first contribution. I checked code style, patch submission rules and did a manual test (details on request) Synopsis: It's a corner case, where a segfault occurs when logging Sparc CPU state in a partially initialized state. No related bug report. Open to harsh criticism ;-) How do we arrive here with a partially initialized state? r~
Re: Patch: Sparc prevent segfault when dumping uninitialzed cpu state
On 2/2/25 20:03, Henk van der Laak (LaakSoft) wrote: On 03/02/2025 04:45, Richard Henderson wrote: On 2/2/25 19:14, Henk van der Laak (LaakSoft) via wrote: Hi all, my first contribution. I checked code style, patch submission rules and did a manual test (details on request) Synopsis: It's a corner case, where a segfault occurs when logging Sparc CPU state in a partially initialized state. No related bug report. Open to harsh criticism ;-) How do we arrive here with a partially initialized state? r~ |> qemu-sparc64 -d cpu_reset -D ./cpu_reset.log demo.sparc64.asm.elf ||The logging category 'cpu_reset' causes logging of all resets including the very first one, where initialization by Qemu has not been completed. Like I said, it's a corner case. Henk van der Laak | Gotcha. I'd forgotten that -d cpu_reset exists. Of course the logging happens before the superclass reset even starts, much less finishes. I guess the logging should happen in the exit phase, not the hold phase. r~
Re: [PATCH 20/21] hw/i2c: Import TCA6416 emulation from Xilinx
At Sun, 02/02/2025 at 18:09 +0100, Philippe Mathieu-Daudé writes: > No clue about compatibility. If you unfortunately need to add it, > then please address my comments in the next version. TCA6416 is _way_ more complex device than PCF8574. Basically PCF8574 is shift register directly connected to IO lines, while TCA6416 is more like fully-fledged GPIO controller with output direction, drive strength, interrupt mask configuration etc etc. In Linux kernel these devices are handled by family-compatible driver drivers/gpio/gpio-pca953x.c Closest things by implementation in QEMU source tree are hw/gpio/pca9552.c and hw/gpio/pca9554.c However they are NOT register-compatible with pca953x. I suppose, best decision would be new driver for TCA6416 which eventually should support whole pca953x family of I2C GPIO expanders. Best regards, Dmitrii
Re: [PATCH 1/1] target/riscv: log guest errors when reserved bits are set in PTEs
> This happens because 'pte' is a 'target_ulong' type that, for riscv32, will be > interpreted as uint32_t while the FMT being used is PRIx64. > > You can fix it by using TARGET_FMT_lx instead of PRIx64: > I've sent a follow-up patch fixing these build errors, it builds on 32 & 64 bit on my system. Cheers As for the Signed-off-by, I'd rather not, and the contributing guide does not require it. Regards, Julia
RE: [PATCH v5 13/17] aspeed/soc: Add AST2700 support
Hi Philippe,
> From: Philippe Mathieu-Daudé
> Sent: Thursday, January 30, 2025 11:14 PM
> To: Jamin Lin ; Cédric Le Goater ;
> Peter Maydell ; Andrew Jeffery
> ; Joel Stanley ; Alistair
> Francis ; Cleber Rosa ; Wainer
> dos Santos Moschetta ; Beraldo Leal
> ; open list:ASPEED BMCs ; open
> list:All patches CC here ; Jinjie Ruan
>
> Cc: Troy Lee ; Yunlin Tang
>
> Subject: Re: [PATCH v5 13/17] aspeed/soc: Add AST2700 support
>
> Hi Jamin,
>
> On 4/6/24 07:44, Jamin Lin wrote:
> > Initial definitions for a simple machine using an AST2700 SOC (Cortex-a35
> CPU).
> >
> > AST2700 SOC and its interrupt controller are too complex to handle in
> > the common Aspeed SoC framework. We introduce a new ast2700 class with
> > instance_init and realize handlers.
> >
> > AST2700 is a 64 bits quad core cpus and support 8 watchdog.
> > Update maximum ASPEED_CPUS_NUM to 4 and ASPEED_WDTS_NUM to 8.
> > In addition, update AspeedSocState to support scuio, sli, sliio and intc.
> >
> > Add TYPE_ASPEED27X0_SOC machine type.
> >
> > The SDMC controller is unlocked at SPL stage.
> > At present, only supports to emulate booting start from u-boot stage.
> > Set SDMC controller unlocked by default.
> >
> > In INTC, each interrupt of INT 128 to INT 136 combines 32 interrupts.
> > It connect GICINT IRQ GPIO-OUTPUT pins to GIC device with irq 128 to 136.
> > And, if a device irq is 128 to 136, its irq GPIO-OUTPUT pin is
> > connected to GICINT or-gates instead of GIC device.
> >
> > Signed-off-by: Troy Lee
> > Signed-off-by: Jamin Lin
> > ---
> > hw/arm/aspeed_ast27x0.c | 563
>
> > hw/arm/meson.build | 1 +
> > include/hw/arm/aspeed_soc.h | 28 +-
> > 3 files changed, 590 insertions(+), 2 deletions(-)
> > create mode 100644 hw/arm/aspeed_ast27x0.c
>
>
> > +static bool aspeed_soc_ast2700_gic_realize(DeviceState *dev, Error
> > +**errp) {
> > +Aspeed27x0SoCState *a = ASPEED27X0_SOC(dev);
> > +AspeedSoCState *s = ASPEED_SOC(dev);
> > +AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
> > +SysBusDevice *gicbusdev;
> > +DeviceState *gicdev;
> > +QList *redist_region_count;
> > +int i;
> > +
> > +gicbusdev = SYS_BUS_DEVICE(&a->gic);
> > +gicdev = DEVICE(&a->gic);
> > +qdev_prop_set_uint32(gicdev, "revision", 3);
> > +qdev_prop_set_uint32(gicdev, "num-cpu", sc->num_cpus);
> > +qdev_prop_set_uint32(gicdev, "num-irq", AST2700_MAX_IRQ);
> > +
> > +redist_region_count = qlist_new();
> > +qlist_append_int(redist_region_count, sc->num_cpus);
> > +qdev_prop_set_array(gicdev, "redist-region-count",
> > + redist_region_count);
> > +
> > +if (!sysbus_realize(gicbusdev, errp)) {
> > +return false;
> > +}
> > +sysbus_mmio_map(gicbusdev, 0, sc->memmap[ASPEED_GIC_DIST]);
> > +sysbus_mmio_map(gicbusdev, 1, sc->memmap[ASPEED_GIC_REDIST]);
> > +
> > +for (i = 0; i < sc->num_cpus; i++) {
> > +DeviceState *cpudev = DEVICE(&a->cpu[i]);
> > +int NUM_IRQS = 256, ARCH_GIC_MAINT_IRQ = 9,
> VIRTUAL_PMU_IRQ = 7;
> > +int ppibase = NUM_IRQS + i * GIC_INTERNAL + GIC_NR_SGIS;
> > +
> > +const int timer_irq[] = {
> > +[GTIMER_PHYS] = 14,
> > +[GTIMER_VIRT] = 11,
> > +[GTIMER_HYP] = 10,
> > +[GTIMER_SEC] = 13,
> > +};
> > +int j;
> > +
> > +for (j = 0; j < ARRAY_SIZE(timer_irq); j++) {
> > +qdev_connect_gpio_out(cpudev, j,
> > +qdev_get_gpio_in(gicdev, ppibase + timer_irq[j]));
> > +}
> > +
> > +qemu_irq irq = qdev_get_gpio_in(gicdev,
> > +ppibase +
> ARCH_GIC_MAINT_IRQ);
> > +qdev_connect_gpio_out_named(cpudev,
> "gicv3-maintenance-interrupt",
> > +0, irq);
> > +qdev_connect_gpio_out_named(cpudev, "pmu-interrupt", 0,
> > +qdev_get_gpio_in(gicdev, ppibase +
> VIRTUAL_PMU_IRQ));
> > +
> > +sysbus_connect_irq(gicbusdev, i, qdev_get_gpio_in(cpudev,
> ARM_CPU_IRQ));
> > +sysbus_connect_irq(gicbusdev, i + sc->num_cpus,
> > + qdev_get_gpio_in(cpudev,
> ARM_CPU_FIQ));
> > +sysbus_connect_irq(gicbusdev, i + 2 * sc->num_cpus,
> > + qdev_get_gpio_in(cpudev,
> ARM_CPU_VIRQ));
> > +sysbus_connect_irq(gicbusdev, i + 3 * sc->num_cpus,
> > + qdev_get_gpio_in(cpudev,
> ARM_CPU_VFIQ));
>
> Your patch was merged around the same time Jinjie added NMI support (see
> commit b36a32ead1 "target/arm: Add support for Non-maskable Interrupt").
>
> Should we add them now?
>
After I read this commit, https://github.com/qemu/qemu/commit/b36a32ead, it
seems that it improves the handling of ARM_CPU_VIRQ and ARM_CPU_VFIQ.
I tested the changes by removing the following lines and worked for AST2700.
sysbus_connect_irq(gicbusdev, i + 2 * nr_apu_cpus,
qdev_get_
RE: [PATCH v5 13/17] aspeed/soc: Add AST2700 support
Hi Philippe,
> From: Jamin Lin
> Sent: Monday, February 3, 2025 3:29 PM
> To: Philippe Mathieu-Daudé ; Cédric Le Goater
> ; Peter Maydell ; Andrew Jeffery
> ; Joel Stanley ; Alistair
> Francis ; Cleber Rosa ; Wainer
> dos Santos Moschetta ; Beraldo Leal
> ; open list:ASPEED BMCs ; open
> list:All patches CC here ; Jinjie Ruan
>
> Cc: Troy Lee ; Yunlin Tang
>
> Subject: RE: [PATCH v5 13/17] aspeed/soc: Add AST2700 support
>
> Hi Philippe,
>
> > From: Philippe Mathieu-Daudé
> > Sent: Thursday, January 30, 2025 11:14 PM
> > To: Jamin Lin ; Cédric Le Goater
> > ; Peter Maydell ; Andrew
> > Jeffery ; Joel Stanley ;
> > Alistair Francis ; Cleber Rosa
> > ; Wainer dos Santos Moschetta
> ;
> > Beraldo Leal ; open list:ASPEED BMCs
> > ; open list:All patches CC here
> > ; Jinjie Ruan
> > Cc: Troy Lee ; Yunlin Tang
> >
> > Subject: Re: [PATCH v5 13/17] aspeed/soc: Add AST2700 support
> >
> > Hi Jamin,
> >
> > On 4/6/24 07:44, Jamin Lin wrote:
> > > Initial definitions for a simple machine using an AST2700 SOC
> > > (Cortex-a35
> > CPU).
> > >
> > > AST2700 SOC and its interrupt controller are too complex to handle
> > > in the common Aspeed SoC framework. We introduce a new ast2700 class
> > > with instance_init and realize handlers.
> > >
> > > AST2700 is a 64 bits quad core cpus and support 8 watchdog.
> > > Update maximum ASPEED_CPUS_NUM to 4 and ASPEED_WDTS_NUM to 8.
> > > In addition, update AspeedSocState to support scuio, sli, sliio and intc.
> > >
> > > Add TYPE_ASPEED27X0_SOC machine type.
> > >
> > > The SDMC controller is unlocked at SPL stage.
> > > At present, only supports to emulate booting start from u-boot stage.
> > > Set SDMC controller unlocked by default.
> > >
> > > In INTC, each interrupt of INT 128 to INT 136 combines 32 interrupts.
> > > It connect GICINT IRQ GPIO-OUTPUT pins to GIC device with irq 128 to 136.
> > > And, if a device irq is 128 to 136, its irq GPIO-OUTPUT pin is
> > > connected to GICINT or-gates instead of GIC device.
> > >
> > > Signed-off-by: Troy Lee
> > > Signed-off-by: Jamin Lin
> > > ---
> > > hw/arm/aspeed_ast27x0.c | 563
> >
> > > hw/arm/meson.build | 1 +
> > > include/hw/arm/aspeed_soc.h | 28 +-
> > > 3 files changed, 590 insertions(+), 2 deletions(-)
> > > create mode 100644 hw/arm/aspeed_ast27x0.c
> >
> >
> > > +static bool aspeed_soc_ast2700_gic_realize(DeviceState *dev, Error
> > > +**errp) {
> > > +Aspeed27x0SoCState *a = ASPEED27X0_SOC(dev);
> > > +AspeedSoCState *s = ASPEED_SOC(dev);
> > > +AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
> > > +SysBusDevice *gicbusdev;
> > > +DeviceState *gicdev;
> > > +QList *redist_region_count;
> > > +int i;
> > > +
> > > +gicbusdev = SYS_BUS_DEVICE(&a->gic);
> > > +gicdev = DEVICE(&a->gic);
> > > +qdev_prop_set_uint32(gicdev, "revision", 3);
> > > +qdev_prop_set_uint32(gicdev, "num-cpu", sc->num_cpus);
> > > +qdev_prop_set_uint32(gicdev, "num-irq", AST2700_MAX_IRQ);
> > > +
> > > +redist_region_count = qlist_new();
> > > +qlist_append_int(redist_region_count, sc->num_cpus);
> > > +qdev_prop_set_array(gicdev, "redist-region-count",
> > > + redist_region_count);
> > > +
> > > +if (!sysbus_realize(gicbusdev, errp)) {
> > > +return false;
> > > +}
> > > +sysbus_mmio_map(gicbusdev, 0, sc->memmap[ASPEED_GIC_DIST]);
> > > +sysbus_mmio_map(gicbusdev, 1,
> sc->memmap[ASPEED_GIC_REDIST]);
> > > +
> > > +for (i = 0; i < sc->num_cpus; i++) {
> > > +DeviceState *cpudev = DEVICE(&a->cpu[i]);
> > > +int NUM_IRQS = 256, ARCH_GIC_MAINT_IRQ = 9,
> > VIRTUAL_PMU_IRQ = 7;
> > > +int ppibase = NUM_IRQS + i * GIC_INTERNAL + GIC_NR_SGIS;
> > > +
> > > +const int timer_irq[] = {
> > > +[GTIMER_PHYS] = 14,
> > > +[GTIMER_VIRT] = 11,
> > > +[GTIMER_HYP] = 10,
> > > +[GTIMER_SEC] = 13,
> > > +};
> > > +int j;
> > > +
> > > +for (j = 0; j < ARRAY_SIZE(timer_irq); j++) {
> > > +qdev_connect_gpio_out(cpudev, j,
> > > +qdev_get_gpio_in(gicdev, ppibase +
> timer_irq[j]));
> > > +}
> > > +
> > > +qemu_irq irq = qdev_get_gpio_in(gicdev,
> > > +ppibase +
> > ARCH_GIC_MAINT_IRQ);
> > > +qdev_connect_gpio_out_named(cpudev,
> > "gicv3-maintenance-interrupt",
> > > +0, irq);
> > > +qdev_connect_gpio_out_named(cpudev, "pmu-interrupt", 0,
> > > +qdev_get_gpio_in(gicdev, ppibase +
> > VIRTUAL_PMU_IRQ));
> > > +
> > > +sysbus_connect_irq(gicbusdev, i, qdev_get_gpio_in(cpudev,
> > ARM_CPU_IRQ));
> > > +sysbus_connect_irq(gicbusdev, i + sc->num_cpus,
> > > + qdev_get_gpio_in(cpudev,
> > ARM_CPU_FIQ));
> > > +sysbus_connect_irq(gicbusdev, i + 2 * sc->num_cpus,
> > > + qdev_get_gp
Re: [PATCH v4 09/33] migration: postcopy_ram_listen_thread() needs to take BQL for some calls
* Maciej S. Szmigiero (m...@maciej.szmigiero.name) wrote: > On 2.02.2025 03:06, Dr. David Alan Gilbert wrote: > > * Maciej S. Szmigiero (m...@maciej.szmigiero.name) wrote: > > > From: "Maciej S. Szmigiero" > > > > > > postcopy_ram_listen_thread() is a free running thread, so it needs to > > > take BQL around function calls to migration methods requiring BQL. > > > > > > qemu_loadvm_state_main() needs BQL held since it ultimately calls > > > "load_state" SaveVMHandlers. > > > > > > migration_incoming_state_destroy() needs BQL held since it ultimately > > > calls > > > "load_cleanup" SaveVMHandlers. > > > > > > Signed-off-by: Maciej S. Szmigiero > > > --- > > > migration/savevm.c | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/migration/savevm.c b/migration/savevm.c > > > index b0b74140daea..0ceea9638cc1 100644 > > > --- a/migration/savevm.c > > > +++ b/migration/savevm.c > > > @@ -2013,7 +2013,9 @@ static void *postcopy_ram_listen_thread(void > > > *opaque) > > >* in qemu_file, and thus we must be blocking now. > > >*/ > > > qemu_file_set_blocking(f, true); > > > +bql_lock(); > > > load_res = qemu_loadvm_state_main(f, mis); > > > +bql_unlock(); > > > > Doesn't that leave that held for a heck of a long time? > > Yes, and it effectively broke "postcopy recover" test but I > think the reason for that is qemu_loadvm_state_main() and > its children don't drop BQL while waiting for I/O. > > I've described this case in more detail in my reply to Fabiano here: > https://lore.kernel.org/qemu-devel/0a09e627-955e-4f26-8d08-0192ecd25...@maciej.szmigiero.name/ While it might be the cause in this case, my feeling is it's more fundamental here - it's the whole reason that postcopy has a separate ram listen thread. As the destination is running, after it loads it's devices and as it starts up the destination will be still loading RAM (and other postcopiable devices) potentially for quite a while. Holding the bql around the ram listen thread means that the execution of the destination won't be able to take that lock until the postcopy load has finished; so while that might apparently complete, it'll lead to the destination stalling until that's finished which defeats the whole point of postcopy. That last one probably won't fail a test but it will lead to a long stall if you give it a nice big guest with lots of RAM that it's rapidly changing. > I still think that "load_state" SaveVMHandlers need to be called > with BQL held since implementations apparently expect it that way: > for example, I think PCI device configuration restore calls > address space manipulation methods which abort() if called > without BQL held. However, the only devices that *should* be arriving on the channel that the postcopy_ram_listen_thread is reading from are those that are postcopiable (i.e. RAM and hmm block's dirty_bitmap). Those load handlers are safe to be run while the other devices are being changed. Note the *should* - you could add a check to fail if any other device arrives on that channel. > I have previously even submitted a patch to explicitly document > "load_state" SaveVMHandler as requiring BQL (which was also > included in the previous version of this patch set) and it > received a "Reviewed-by:" tag: > https://lore.kernel.org/qemu-devel/6976f129df610c8207da4e531c8c0475ec204fa4.1730203967.git.maciej.szmigi...@oracle.com/ > https://lore.kernel.org/qemu-devel/e1949839932efaa531e2fe63ac13324e5787439c.1731773021.git.maciej.szmigi...@oracle.com/ > https://lore.kernel.org/qemu-devel/87o732bti7@suse.de/ It happens! You could make this safer by having a load_state and a load_state_postcopy member, and only mark the load_state as requiring the lock. > It's also worth noting that COLO equivalent of postcopy > incoming thread (colo_process_incoming_thread()) explicitly > takes BQL around qemu_loadvm_state_main(): > > bql_lock(); > > cpu_synchronize_all_states(); > > ret = qemu_loadvm_state_main(mis->from_src_file, mis); > > bql_unlock(); > It's not a straight equivalent; it's about a decade since I've thought about COLO, so I can't quite remember when that thread runs. > > That RAM loading has to happen in parallel with the loading of > > devices doesn't it - especially if one of the devices > > being loaded touches RAM. > > > > (I wish this series had a description in the cover letter!) > > I guess you mean "more detailed description" since there's > a paragraph about this patch in this series cover letter change log: > > * postcopy_ram_listen_thread() now takes BQL around function calls that > > ultimately call migration methods requiring BQL. > > This fixes one of QEMU tests failing when explicitly BQL-sensitive code > > is added later to these methods. I meant a higher level description of what the series is doing. Dave > > > Dave > > Thanks, > Maciej > > -- -Open up your eyes, open up your mind, open up your code
Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
On 1/27/25 19:17, Alex Bennée wrote: ... > I'm still seeing corruption with -display gtk,gl=on on my x86 system > BTW. I would like to understand if that is a problem with QEMU, GTK or > something else in the stack before we merge. I reproduced the display mirroring/corruption issue and bisected it to the following commit. The problem only happens when QEMU/GTK uses Wayland display directly, while previously I was running QEMU with XWayland that doesn't have the problem. Why this change breaks dmabuf displaying with Wayland/GTK is unclear. Reverting commit fixes the bug. +Dongwon Kim +Vivek Kasireddy commit 77bf310084dad38b3a2badf01766c659056f1cf2 Author: Dongwon Kim Date: Fri Apr 26 15:50:59 2024 -0700 ui/gtk: Draw guest frame at refresh cycle Draw routine needs to be manually invoked in the next refresh if there is a scanout blob from the guest. This is to prevent a situation where there is a scheduled draw event but it won't happen bacause the window is currently in inactive state (minimized or tabified). If draw is not done for a long time, gl_block timeout and/or fence timeout (on the guest) will happen eventually. v2: Use gd_gl_area_draw(vc) in gtk-gl-area.c Suggested-by: Vivek Kasireddy Cc: Gerd Hoffmann Cc: Marc-André Lureau Cc: Daniel P. Berrangé Signed-off-by: Dongwon Kim Acked-by: Marc-André Lureau Message-Id: <20240426225059.3871283-1-dongwon@intel.com> -- Best regards, Dmitry
Re: [PATCH v7 51/52] i386/tdx: Validate phys_bits against host value
On 2/1/2025 2:27 AM, Paolo Bonzini wrote:
On Fri, Jan 24, 2025 at 2:40 PM Xiaoyao Li wrote:
For TDX guest, the phys_bits is not configurable and can only be
host/native value.
Validate phys_bits inside tdx_check_features().
Hi Xiaoyao,
to avoid
qemu-kvm: TDX requires guest CPU physical bits (48) to match host CPU
physical bits (52)
I need options like
-cpu
host,phys-bits=52,guest-phys-bits=52,host-phys-bits-limit=52,-kvm-asyncpf-int
to start a TDX guest, is that intentional?
"-cpu host" should be sufficient and should not hit the error.
why did you get "guest CPU physical bits (48)"?
Thanks,
Paolo
Signed-off-by: Xiaoyao Li
---
target/i386/host-cpu.c | 2 +-
target/i386/host-cpu.h | 1 +
target/i386/kvm/tdx.c | 8
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/target/i386/host-cpu.c b/target/i386/host-cpu.c
index 3e4e85e729c8..8a15af458b05 100644
--- a/target/i386/host-cpu.c
+++ b/target/i386/host-cpu.c
@@ -15,7 +15,7 @@
#include "system/system.h"
/* Note: Only safe for use on x86(-64) hosts */
-static uint32_t host_cpu_phys_bits(void)
+uint32_t host_cpu_phys_bits(void)
{
uint32_t eax;
uint32_t host_phys_bits;
diff --git a/target/i386/host-cpu.h b/target/i386/host-cpu.h
index 6a9bc918baa4..b97ec01c9bec 100644
--- a/target/i386/host-cpu.h
+++ b/target/i386/host-cpu.h
@@ -10,6 +10,7 @@
#ifndef HOST_CPU_H
#define HOST_CPU_H
+uint32_t host_cpu_phys_bits(void);
void host_cpu_instance_init(X86CPU *cpu);
void host_cpu_max_instance_init(X86CPU *cpu);
bool host_cpu_realizefn(CPUState *cs, Error **errp);
diff --git a/target/i386/kvm/tdx.c b/target/i386/kvm/tdx.c
index bb75eb06dad9..c906a76c4c0e 100644
--- a/target/i386/kvm/tdx.c
+++ b/target/i386/kvm/tdx.c
@@ -24,6 +24,7 @@
#include "cpu.h"
#include "cpu-internal.h"
+#include "host-cpu.h"
#include "hw/i386/e820_memory_layout.h"
#include "hw/i386/x86.h"
#include "hw/i386/tdvf.h"
@@ -838,6 +839,13 @@ static int tdx_check_features(X86ConfidentialGuest *cg,
CPUState *cs)
return -1;
}
+if (cpu->phys_bits != host_cpu_phys_bits()) {
+error_report("TDX requires guest CPU physical bits (%u) "
+ "to match host CPU physical bits (%u)",
+ cpu->phys_bits, host_cpu_phys_bits());
+exit(1);
+}
+
return 0;
}
--
2.34.1
Re: [PATCH v2 06/69] target/arm: Define FPCR AH, FIZ, NEP bits
On 2/1/25 08:39, Peter Maydell wrote: The Armv8.7 FEAT_AFP feature defines three new control bits in the FPCR: * FPCR.AH: "alternate floating point mode"; this changes floating point behaviour in a variety of ways, including: - the sign of a default NaN is 1, not 0 - if FPCR.FZ is also 1, denormals detected after rounding with an unbounded exponent has been applied are flushed to zero - FPCR.FZ does not cause denormalized inputs to be flushed to zero - miscellaneous other corner-case behaviour changes * FPCR.FIZ: flush denormalized numbers to zero on input for most instructions * FPCR.NEP: makes scalar SIMD operations merge the result with higher vector elements in one of the source registers, instead of zeroing the higher elements of the destination This commit defines the new bits in the FPCR, and allows them to be read or written when FEAT_AFP is implemented. Actual behaviour changes will be implemented in subsequent commits. Note that these are the first FPCR bits which don't appear in the AArch32 FPSCR view of the register, and which share bit positions with FPSR bits. Signed-off-by: Peter Maydell --- target/arm/cpu-features.h | 5 + target/arm/cpu.h | 3 +++ target/arm/vfp_helper.c | 11 --- 3 files changed, 16 insertions(+), 3 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 04/69] fpu: Implement float_flag_input_denormal_used
On 2/1/25 08:39, Peter Maydell wrote: For the x86 and the Arm FEAT_AFP semantics, we need to be able to tell the target code that the FPU operation has used an input denormal. Implement this; when it happens we set the new float_flag_denormal_input_used. Note that we only set this when an input denormal is actually used by the operation: if the operation results in Invalid Operation or Divide By Zero or the result is a NaN because some other input was a NaN then we never needed to look at the input denormal and do not set denormal_input_used. We mostly do not need to adjust the hardfloat codepaths to deal with this flag, because almost all hardfloat operations are already gated on the input not being a denormal, and will fall back to softfloat for a denormal input. The only exception is the comparison operations, where we need to add the check for input denormals, which must now fall back to softfloat where they did not before. Signed-off-by: Peter Maydell --- v2: drop the now-unnecessary float*_input_flush2() calls in the float*_hs_compare() functions --- include/fpu/softfloat-types.h | 7 fpu/softfloat.c | 38 +--- fpu/softfloat-parts.c.inc | 68 ++- 3 files changed, 107 insertions(+), 6 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v2 05/69] fpu: allow flushing of output denormals to be after rounding
On 2/1/25 08:39, Peter Maydell wrote: Currently we handle flushing of output denormals in uncanon_normal always before we deal with rounding. This works for architectures that detect tininess before rounding, but is usually not the right place when the architecture detects tininess after rounding. For example, for x86 the SDM states that the MXCSR FTZ control bit causes outputs to be flushed to zero "when it detects a floating-point underflow condition". This means that we mustn't flush to zero if the input is such that after rounding it is no longer tiny. At least one of our guest architectures does underflow detection after rounding but flushing of denormals before rounding (MIPS MSA); this means we need to have a config knob for this that is separate from our existing tininess_before_rounding setting. Add an ftz_detection flag. For consistency with tininess_before_rounding, we make it default to "detect ftz after rounding"; this means that we need to explicitly set the flag to "detect ftz before rounding" on every existing architecture that sets flush_to_zero, so that this commit has no behaviour change. (This means more code change here but for the long term a less confusing API.) For several architectures the current behaviour is either definitely or possibly wrong; annotate those with TODO comments. These architectures are definitely wrong (and should detect ftz after rounding): * x86 * Alpha For these architectures the spec is unclear: * MIPS (for non-MSA) * RX * SH4 PA-RISC makes ftz detection IMPDEF, but we aren't setting the "tininess before rounding" setting that we ought to. Signed-off-by: Peter Maydell --- include/fpu/softfloat-helpers.h | 11 +++ include/fpu/softfloat-types.h | 18 ++ target/mips/fpu_helper.h| 6 ++ target/alpha/cpu.c | 7 +++ target/arm/cpu.c| 1 + target/hppa/fpu_helper.c| 11 +++ target/i386/tcg/fpu_helper.c| 8 target/mips/msa.c | 9 + target/ppc/cpu_init.c | 3 +++ target/rx/cpu.c | 8 target/sh4/cpu.c| 8 target/tricore/helper.c | 1 + tests/fp/fp-bench.c | 1 + fpu/softfloat-parts.c.inc | 21 +++-- 14 files changed, 107 insertions(+), 6 deletions(-) Reviewed-by: Richard Henderson r~
