Branch: refs/heads/staging-9.2
Home: https://github.com/qemu/qemu
Commit: 800495a3943dbc6a07d2789ccd7278c1e10fb2d2
https://github.com/qemu/qemu/commit/800495a3943dbc6a07d2789ccd7278c1e10fb2d2
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: fix leak in kvm_riscv_init_multiext_cfg()
'reglist' is being g-malloc'ed but never freed.
Reported-by: Andrew Jones <ajo...@ventanamicro.com>
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-3-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 906af6de9462c5192547cca0beac2c134659a437)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 6b10b25dddfb70a2df149dde4b2e09e97430ba9a
https://github.com/qemu/qemu/commit/6b10b25dddfb70a2df149dde4b2e09e97430ba9a
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: turn u32/u64 reg functions into macros
This change is motivated by a future change w.r.t CSRs management. We
want to handle them the same way as KVM extensions, i.e. a static array
with KVMCPUConfig objs that will be read/write during init and so on.
But to do that properly we must be able to declare a static array that
hold KVM regs.
C does not allow to init static arrays and use functions as
initializers, e.g. we can't do:
.kvm_reg_id = kvm_riscv_reg_id_ulong(...)
When instantiating the array. We can do that with macros though, so our
goal is turn kvm_riscv_reg_ulong() in a macro. It is cleaner to turn
every other reg_id_*() function in macros, and ulong will end up using
the macros for u32 and u64, so we'll start with them.
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-4-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit b6096103494506514d9bfa442f62fef36ffc8fba)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: e2d4d3c2ac9e01bad0a734f3c51c93815eda9ffb
https://github.com/qemu/qemu/commit/e2d4d3c2ac9e01bad0a734f3c51c93815eda9ffb
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: turn kvm_riscv_reg_id_ulong() into a macro
We need the reg_id_ulong() helper to be a macro to be able to create a
static array of KVMCPUConfig that will hold CSR information.
Despite the amount of changes all of them are tedious/trivial:
- replace instances of "kvm_riscv_reg_id_ulong" with
"KVM_RISCV_REG_ID_ULONG";
- RISCV_CORE_REG(), RISCV_CSR_REG(), RISCV_CONFIG_REG() and
RISCV_VECTOR_CSR_REG() only receives one 'name' arg. Remove unneeded
'env' variables when applicable.
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-5-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 11766e17616a5a4181d4a63f88adf67ac52c553b)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 289dcab554eddb536055e1ddc058d7d838f299af
https://github.com/qemu/qemu/commit/289dcab554eddb536055e1ddc058d7d838f299af
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M target/riscv/cpu.h
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: add kvm_csr_cfgs[]
At this moment we're not checking if the host has support for any
specific CSR before doing get/put regs. This will cause problems if the
host KVM doesn't support it (see [1] as an example).
We'll use the same approach done with the CPU extensions: read all known
KVM CSRs during init() to check for availability, then read/write them
if they are present. This will be made by either using get-reglist or by
directly reading the CSRs.
For now we'll just convert the CSRs to use a kvm_csr_cfg[] array,
reusing the same KVMCPUConfig abstraction we use for extensions, and use
the array in (get|put)_csr_regs() instead of manually listing them. A
lot of boilerplate will be added but at least we'll automate the get/put
procedure for CSRs, i.e. adding a new CSR in the future will be a matter
of adding it in kvm_csr_regs[] and everything else will be taken care
of.
Despite all the code changes no behavioral change is made.
[1]
https://lore.kernel.org/qemu-riscv/CABJz62OfUDHYkQ0T3rGHStQprf1c7_E0qBLbLKhfv=+jb0s...@mail.gmail.com/
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Acked-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-6-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit d3b6f1742c36e3a3c1e74cb60646ee98a4e39ea3)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 5d139247e910132082027afbc19d60a7a6cdb693
https://github.com/qemu/qemu/commit/5d139247e910132082027afbc19d60a7a6cdb693
Author: Rakesh Jeyasingh <rakeshjb...@gmail.com>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M hw/pci-host/gt64120.c
Log Message:
-----------
hw/pci-host/gt64120: Fix endianness handling
The GT-64120 PCI controller requires special handling where:
1. Host bridge(bus 0 ,device 0) must never be byte-swapped
2. Other devices follow MByteSwap bit in GT_PCI0_CMD
The previous implementation incorrectly swapped all accesses, breaking
host bridge detection (lspci -d 11ab:4620).
Changes made:
1. Removed gt64120_update_pci_cfgdata_mapping() and moved data_mem
initialization
to gt64120_realize() for cleaner setup
2. Implemented custom read/write handlers that:
- Preserve host bridge accesses (extract32(config_reg,11,13)==0)
- apply swapping only for non-bridge devices in big-endian mode
Fixes: 145e2198 ("hw/mips/gt64xxx_pci: Endian-swap using PCI_HOST_BRIDGE
MemoryRegionOps")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2826
Signed-off-by: Rakesh Jeyasingh <rakeshjb...@gmail.com>
Tested-by: Thomas Huth <th...@redhat.com>
Link: https://lore.kernel.org/r/20250429170354.150581-2-rakeshjb...@gmail.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit e5894fd6f411c113e2b5f62811e96eeb5b084381)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 361bd5efe41ccebbc799b0f5530e188cdfd1c29b
https://github.com/qemu/qemu/commit/361bd5efe41ccebbc799b0f5530e188cdfd1c29b
Author: Rakesh Jeyasingh <rakeshjb...@gmail.com>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M hw/pci/pci_host.c
M include/hw/pci-host/dino.h
M include/hw/pci/pci_host.h
Log Message:
-----------
hw/pci-host: Remove unused pci_host_data_be_ops
pci_host_data_be_ops became unused after endianness fixes
Suggested-by: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Rakesh Jeyasingh <rakeshjb...@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Tested-by: Thomas Huth <th...@redhat.com>
Link: https://lore.kernel.org/r/20250429170354.150581-3-rakeshjb...@gmail.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit 560375cff3ccedabf1fe5ca1bc7a31b13fdc68e5)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 5a1414313bc52946e2287913368ff1d783b08028
https://github.com/qemu/qemu/commit/5a1414313bc52946e2287913368ff1d783b08028
Author: Zhao Liu <zhao1....@intel.com>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M qapi/misc-target.json
Log Message:
-----------
qapi/misc-target: Fix the doc to distinguish query-sgx and
query-sgx-capabilities
There're 2 QMP commands: query-sgx and query-sgx-capabilities, but
their outputs are very similar and the documentation lacks clear
differentiation.
>From the codes, query-sgx is used to gather guest's SGX capabilities
(including SGX related CPUIDs and EPC sections' size, in SGXInfo), and
if guest doesn't have SGX, then QEMU will report the error message.
On the other hand, query-sgx-capabilities is used to gather host's SGX
capabilities (descripted by SGXInfo as well). And if host doesn't
support SGX, then QEMU will also report the error message.
Considering that SGXInfo is already documented and both these 2 commands
have enough error messages (for the exception case in their codes).
Therefore the QAPI documentation for these two commands only needs to
emphasize that one of them applies to the guest and the other to the
host.
Fix their documentation to reflect this difference.
Reported-by: Markus Armbruster <arm...@redhat.com>
Suggested-by: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Acked-by: Markus Armbruster <arm...@redhat.com>
Link: https://lore.kernel.org/r/20250513143131.2008078-3-zhao1....@intel.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit 7f2131c35c1781ca41c62dc26fd93282e1351323)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 53a4bf6830874caf31a1a832beac15115a22443f
https://github.com/qemu/qemu/commit/53a4bf6830874caf31a1a832beac15115a22443f
Author: Peter Xu <pet...@redhat.com>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M migration/options.c
Log Message:
-----------
migration: Allow caps to be set when preempt or multifd cap enabled
With commit 82137e6c8c ("migration: enforce multifd and postcopy preempt to
be set before incoming"), and if postcopy preempt / multifd is enabled, one
cannot setup any capability because these checks would always fail.
(qemu) migrate_set_capability xbzrle off
Error: Postcopy preempt must be set before incoming starts
To fix it, check existing cap and only raise an error if the specific cap
changed.
Fixes: 82137e6c8c ("migration: enforce multifd and postcopy preempt to be set
before incoming")
Reviewed-by: Dr. David Alan Gilbert <d...@treblig.org>
Reviewed-by: Juraj Marcin <jmar...@redhat.com>
Signed-off-by: Peter Xu <pet...@redhat.com>
(cherry picked from commit 17bec9235bb0775cf8dec4103c167757ee8898f3)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: b1ff64ba4e84fdefc514111270da4283b94271c3
https://github.com/qemu/qemu/commit/b1ff64ba4e84fdefc514111270da4283b94271c3
Author: Helge Deller <del...@gmx.de>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M target/hppa/int_helper.c
Log Message:
-----------
target/hppa: Copy instruction code into fr1 on FPU assist fault
The hardware stores the instruction code in the lower bits of the FP
exception register #1 on FP assist traps.
This fixes the FP exception handler on Linux, as the Linux kernel uses
the value to decide on the correct signal which should be pushed into
userspace (see decode_fpu() in Linux kernel).
Signed-off-by: Helge Deller <del...@gmx.de>
(cherry picked from commit 923976dfe367b0bfed45ff660c369f3fe65604a7)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 148eb79f573299bf517ff2ff0f2ed87f18d59af9
https://github.com/qemu/qemu/commit/148eb79f573299bf517ff2ff0f2ed87f18d59af9
Author: Helge Deller <del...@gmx.de>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M linux-user/hppa/cpu_loop.c
Log Message:
-----------
linux-user/hppa: Send proper si_code on SIGFPE exception
Improve the linux-user emulation to send the correct si_code depending
on overflow (TARGET_FPE_FLTOVF), underflow (TARGET_FPE_FLTUND), ...
Note that the hardware stores the relevant flags in FP exception
register #1, which is actually the lower 32-bits of the 64-bit fr[0]
register in qemu.
Signed-off-by: Helge Deller <del...@gmx.de>
(cherry picked from commit b4b49cf39dba5f993ad925f204cb820aacfc8e45)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 0befc056f38731d9cbdd727244c2b4324f1ac813
https://github.com/qemu/qemu/commit/0befc056f38731d9cbdd727244c2b4324f1ac813
Author: Helge Deller <del...@gmx.de>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M target/hppa/fpu_helper.c
Log Message:
-----------
target/hppa: Fix FPE exceptions
Implement FP exception register #1 (lower 32-bits of 64-bit fr[0]).
A proper implementation is necessary to allow the Linux kernel in
system mode and the qemu linux-user to send proper si_code values
on SIGFPE signal.
Always set the T-bit on taken exception, and merge over- and underflow
in system mode to just set overflow bit to mimic the behaviour I tested
on a physical machine.
The test program below can be used to verify correct behaviour. Note
that behaviour on SIGFPE may vary on different platforms. The program
should always detect the correct signal, but it may or may not be able
to sucessfully continue afterwards.
#define _GNU_SOURCE
#include <signal.h>
#include <stdio.h>
#include <fenv.h>
#include <float.h>
static void fpe_func(int sig, siginfo_t *i, void *v) {
sigset_t set;
sigemptyset(&set);
sigaddset(&set, SIGFPE);
sigprocmask(SIG_UNBLOCK, &set, NULL);
printf("GOT signal %d with si_code %ld\n", sig, i->si_code);
}
int main(int argc, char *argv[]) {
struct sigaction action = {
.sa_sigaction = fpe_func,
.sa_flags = SA_RESTART|SA_SIGINFO };
sigaction(SIGFPE, &action, 0);
feenableexcept(FE_OVERFLOW | FE_UNDERFLOW);
double x = DBL_MIN;
return printf("%lf\n", argc > 1
? 1.7976931348623158E308*1.7976931348623158E308
: x / 10);
}
Signed-off-by: Helge Deller <del...@gmx.de>
(cherry picked from commit ebd394948de4e868cb8fc5b265a8a18f0935dce1)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/84ecaf227312...0befc056f387
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
