Patch was applied with invalid authorship by accident, which confuses
git tooling that look at git blame for contributors etc.
Patch will be re-applied with correct authorship right after this
commit.
This reverts commit d0f0cd5b1f7e9780753344548e17ad4df9fcf5d8.
Signed-off-by: Manos Pitsidianaki
This commit adds a re-implementation of hw/char/pl011.c in Rust.
How to build:
1. Configure a QEMU build with:
--enable-system --target-list=aarch64-softmmu --enable-rust
2. Launching a VM with qemu-system-aarch64 should use the Rust version
of the pl011 device
Co-authored-by: Junjie Mao
On Wed, Oct 23, 2024 at 12:28 PM Manos Pitsidianakis
wrote:
> By the way I already have a patch that adds a -luminary version,
> planning on including it with the rest of my procedural macro patches
> I will send.
I'll hold on this patch until I get yours then. It is not needed yet
for CI, since
On 10/22/24 17:23, Kevin Wolf wrote:
Am 22.10.2024 um 15:40 hat Cédric Le Goater geschrieben:
static const VMStateDescription vmstate_aspeed_smc = {
.name = "aspeed.smc",
-.version_id = 2,
+.version_id = 3,
.minimum_version_id = 2,
.fields = (const VMStateField[])
Add a new derive procedural macro to declare device models. Add
corresponding DeviceImpl trait after already existing ObjectImpl trait.
At the same time, add instance_init, instance_post_init,
instance_finalize methods to the ObjectImpl trait and call them from the
ObjectImplUnsafe trait, which is
Add a function for sending signals to individual threads. It does not make
sense on Windows, so do not provide an implementation, so that if someone
uses it by accident, they will get a linker error.
Signed-off-by: Ilya Leoshkevich
---
include/qemu/osdep.h | 9 +
util/oslib-posix.c |
This code juxtaposed what should be happening according to the C device
model but is not needed now that this has been reviewed (I hope) and its
validity checked against what the C device does (I hope, again).
No functional change.
Signed-off-by: Manos Pitsidianakis
---
rust/hw/char/pl011/src/d
current_migration is never reset, even if the migration object is freed
already. It means anyone references that can trigger UAF and it'll be hard
to debug.
Properly clear the pointer now, so far the only way to do is via
finalize() as we know there's only one instance of it, meanwhile QEMU won't
On 21/10/2024 12.16, Joel Stanley wrote:
I was attempting to run some boot tests today and saw this:
(11/39)
tests/avocado/boot_linux_console.py:BootLinuxConsole.test_arm_bpim2u_gmac:
CANCEL: Missing asset
http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20221116.0/armel
Change all related docs and tests to use the new 'reconnect-ms' option
instead of the now deprecated 'reconnect'.
Signed-off-by: Daniil Tatianin
---
docs/COLO-FT.txt | 4 ++--
docs/system/ppc/powernv.rst | 2 +-
qemu-options.hx | 22 +++---
tests/qt
Do the same thing we already did for chardev in c8e2b6b4d7e, and
introduce a new 'reconnect-ms' option to make it possible to specify
sub-second timeouts. This also changes the related documentaion and
tests to use reconnect-ms as well.
Signed-off-by: Daniil Tatianin
---
docs/about/deprecated.rs
We've deprecated the 'reconnect' property in c8e2b6b4d7e, but all the
tests, as well as the stream netdev were still left using it. This
series finalizes the deprecation and replaces all local usage and docs
metions of 'reconnect' with 'reconnect-ms'.
Daniil Tatianin (2):
net/stream: deprecate '
Peter Xu writes:
> This patchset introduces the singleton interface for QOM.
>
> The singleton interface is as simple as "this class can only create one
> instance".
>
> We used to have similar demand when working on all kinds of vIOMMUs,
> because in most cases that I am aware of, vIOMMU must be
On Tue, 22 Oct 2024 at 17:51, Kevin Wolf wrote:
>
> The following changes since commit 6f625ce2f21d6a1243065d236298277c56f972d5:
>
> Merge tag 'pull-request-2024-10-21' of https://gitlab.com/thuth/qemu into
> staging (2024-10-21 17:12:59 +0100)
>
> are available in the Git repository at:
>
>
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 virglre
On 21/10/2024 17.02, Thomas Huth wrote:
On 21/10/2024 14.36, Daniel P. Berrangé wrote:
This ensures that if a functional test runs QEMU with a writable
disk pointing to a cached asset, an error will be reported, rather
than silently modifying the cache file.
As an example, tweaking test_sbsaref
Just my two cents on this with regard to the future:
Tools using libvirt to define or modify libvirt domains should not be
enforced to change there PCI code logic to prevent the usage of
pci-bridge for s390x.
The PCI bus configuration in QEMU is QEMU internal only as the zPCI
configuration is u
On 10/10/2024 5:23 PM, Peter Xu wrote:
On Thu, Oct 10, 2024 at 04:06:13PM -0400, Steven Sistare wrote:
vhost requires us to stop the vm early:
qmp_migrate
stop vm
migration_call_notifiers MIG_EVENT_PRECOPY_CPR_SETUP
vhost_cpr_notifier
vhost_reset_device - must be aft
This series adds the support for following features in qemu.
1. RAS feature bits (SUCCOR, McaOverflowRecov)
2. perfmon-v2
3. Update EPYC-Genoa to support perfmon-v2 and RAS bits
4. Support for bits related to SRSO (sbpb, ibpb-brtype, srso-user-kernel-no)
5. Added support for feature bits CPUID_Fn
The virtio_blk_free_request() function has been a 1-liner forwarding
to g_free() for a while now. We may as well call g_free on the request
pointer directly.
Signed-off-by: Phil Dennis-Jordan
---
hw/block/virtio-blk.c | 43 +++---
hw/vmapple/virtio-blk.c
Hello Jamin,
On 10/22/24 11:40, Jamin Lin wrote:
change from v1:
1. Fix write incorrect data into flash in user mode.
2. Refactor aspeed smc qtest testcases to support AST2600, AST2500 and
AST1030.
3. Add ast2700 smc qtest testcase to support AST2700.
change from v2:
1. Introduce a new as
checkpatch.pl lints for spaces around operators including / (slash).
Code lines starting with #include are ignored, as slashes in those
represent path separators.
In Objective-C code, #import is often used in preference to #include,
as preprocessor-based multiple-#include defenses are considered
n
This change wires up the PCI variant of the paravirtualised
graphics device, mainly useful for x86-64 macOS guests, implemented
by macOS's ParavirtualizedGraphics.framework. It builds on code
shared with the vmapple/mmio variant of the PVG device.
Signed-off-by: Phil Dennis-Jordan
---
v4:
* Th
From: Pierrick Bouvier
Mention it's now possible to build with gcc, instead of clang, and
explain how to build a sanitized glib version.
Signed-off-by: Pierrick Bouvier
Reviewed-by: Thomas Huth
Message-Id: <20240910174013.141-4-pierrick.bouv...@linaro.org>
Signed-off-by: Alex Bennée
Messa
This helper is mostly the same as migration_is_running(), except that one
has COLO reported as true, the other has CANCELLING reported as true.
Per my past years experience on the state changes, none of them should
matter.
To make it slightly safer, report both COLO || CANCELLING to be true in
mi
On 24/10/24 05:27, Thomas Huth wrote:
Now that we are aware of binaries that are available for sh4eb,
we should make sure that there are no regressions with this
target and test it regularly in our CI.
Signed-off-by: Thomas Huth
---
tests/functional/meson.build | 3 +++
tests/function
Add the support for following RAS features bits on AMD guests.
SUCCOR: Software uncorrectable error containment and recovery capability.
The processor supports software containment of uncorrectable errors
through context synchronizing data poisoning and deferred error
inter
On 10/24/24 09:25, Richard Henderson wrote:
On 10/23/24 23:20, Pierrick Bouvier wrote:
When instrumenting memory accesses for plugin, we force memory accesses
to use the slow path for mmu. [1]
This create a situation where we end up calling ptw_setl_slow.
Since this function gets called during
From: Alexander Graf
Apple defines a new "vmapple" machine type as part of its proprietary
macOS Virtualization.Framework vmm. This machine type is similar to the
virt one, but with subtle differences in base devices, a few special
vmapple device additions and a vastly different boot chain.
This
On 21/10/24 13:34, Paolo Bonzini wrote:
qapi_event_send_device_deleted is always included (together with the
rest of QAPI) in libqemuutil.a if either system-mode emulation or tools
are being built, and in that case the stub causes a duplicate symbol
to appear in libqemuutil.a.
Add the symbol onl
On 10/23/24 09:39, Pierrick Bouvier wrote:
This file was created by mistake in recent ed7667188 (9p: remove
'proxy' filesystem backend driver).
When cloning the repository using native git for windows, we see this:
Error: error: invalid path 'scripts/meson-buildoptions.'
Error: The process 'C:\P
Hello,
This series enables Vulkan Venus context support on virtio-gpu.
All virglrender and almost all Linux kernel prerequisite changes
needed by Venus are already in upstream. For kernel there is a pending
KVM patchset that fixes mapping of compound pages needed for DRM drivers
using TTM or huge
Peter Xu writes:
> Signed-off-by: Peter Xu
> ---
> include/qom/object_interfaces.h | 47 +
> qom/object.c| 3 +++
> qom/object_interfaces.c | 24 +
> qom/qom-qmp-cmds.c | 22 ---
> system/qdev-
Hello everyone, the pathological corrosion of QEMU code continues.
This series expands the device model harness work performed in the
initial Rust work from the previous month. In particular:
- A new derive proc macro, Device, is introduced and the Object derive
macro is heavily expanded upon.
The following changes since commit 6f625ce2f21d6a1243065d236298277c56f972d5:
Merge tag 'pull-request-2024-10-21' of https://gitlab.com/thuth/qemu into
staging (2024-10-21 17:12:59 +0100)
are available in the Git repository at:
https://github.com/legoater/qemu/ tags/pull-aspeed-20241024
for
On 10/24/24 10:53, Philippe Mathieu-Daudé wrote:
Hi Guenter,
On 24/10/24 01:04, Guenter Roeck wrote:
On 10/23/24 20:27, Philippe Mathieu-Daudé wrote:
Hi Guenter,
On 23/10/24 19:24, Guenter Roeck wrote:
Hi,
On Fri, Jun 28, 2024 at 09:01:27AM +0200, Philippe Mathieu-Daudé wrote:
Signed-off-b
Dmitry Osipenko writes:
> Hello,
>
> This series enables Vulkan Venus context support on virtio-gpu.
>
> All virglrender and almost all Linux kernel prerequisite changes
> needed by Venus are already in upstream. For kernel there is a pending
> KVM patchset that fixes mapping of compound pages ne
Signed-off-by: Eric Auger
---
target/arm/cpu-features.h | 36 +-
target/arm/cpu.h | 14 ++--
hw/intc/armv7m_nvic.c | 12 ++--
target/arm/cpu.c | 24 +++
target/arm/cpu64.c| 28
target/arm/helper.c | 14 ++--
target/arm/kvm.c
Signed-off-by: Eric Auger
---
target/arm/cpu-features.h | 18
target/arm/cpu.h | 6 ---
hw/intc/armv7m_nvic.c | 8 ++--
target/arm/cpu64.c| 16 +++
target/arm/helper.c | 12 ++---
target/arm/kvm.c | 18 +++-
target/arm/tcg/cpu-v7m.c | 48 +++
Signed-off-by: Eric Auger
---
target/arm/cpu-features.h | 38 +++---
target/arm/cpu.h | 2 --
target/arm/cpu.c | 9 +++--
target/arm/cpu64.c| 9 +
target/arm/helper.c | 4 ++--
target/arm/kvm.c | 6 ++
t
IEEE 758 does not define a fixed rule for which NaN to pick as the
result if both operands of a 2-operand operation are NaNs. As a
result different architectures have ended up with different rules for
propagating NaNs.
QEMU currently hardcodes the NaN propagation logic into the binary,
because pi
Set the NaN propagation rule explicitly in xtensa_use_first_nan().
(When we convert the softfloat pickNaNMulAdd routine to also
select a NaN propagation rule at runtime, we will be able to
remove the use_first_nan flag because the propagation rules
will handle everything.)
Signed-off-by: Peter Ma
Set the 2-NaN propagation rule explicitly in env->fp_status
and env->vec_status.
Signed-off-by: Peter Maydell
---
As an aside, it looks a bit suspicious that we set
tininess_before_rounding on fp_status but not vec_status...
---
target/ppc/cpu_init.c | 8
fpu/softfloat-special
On Fri, Oct 25, 2024 at 10:32:15AM -0400, Steven Sistare wrote:
> On 10/25/2024 9:43 AM, Daniel P. Berrangé wrote:
> > On Fri, Oct 25, 2024 at 09:33:51AM -0400, Steven Sistare wrote:
> > > On 10/25/2024 4:46 AM, Daniel P. Berrangé wrote:
> > > > On Thu, Oct 24, 2024 at 05:16:14PM -0400, Steven Sist
On 10/25/24 16:12, Peter Maydell wrote:
A summary of those TODOs and other oddities I have noticed but not
tried to tackle is:>
* hppa really ought to implement a CPU reset method
* alpha also doesn't implement CPU reset
I used the alpha code as template to implement the hppa machine.
Tha
Set the 2-NaN propagation rule explicitly in the float_status word we
use.
(There are a couple of places in fpu_helper.c where we create a
dummy float_status word with "float_status *s = { };", but these
are only used for calling float*_is_quiet_nan() so it doesn't
matter that we don't set a 2-NaN
20.10.2024 16:01, Avihai Horon:
vfio_state_pending_exact() is used to update migration core how much
device data is left for the device migration. Currently, the sum of
pre-copy and stop-copy sizes of the VFIO device are reported.
The pre-copy size is obtained via the VFIO_MIG_GET_PRECOPY_INFO i
On Fri, 2024-10-25 at 06:59 -0700, Guenter Roeck wrote:
> On 10/25/24 02:57, Jan Lübbe wrote:
> > On Fri, 2024-10-25 at 08:55 +0200, Cédric Le Goater wrote:
> > > On 10/24/24 19:59, Philippe Mathieu-Daudé wrote:
> > > > Cc'ing Jan.
> > > >
> > > > On 22/10/24 12:04, Guenter Roeck wrote:
> > > >
>
18.10.2024 19:02, Michael Tokarev wrote:
10.07.2024 09:29, Paolo Bonzini wrote:
This fixes a bug wherein i386/tcg assumed an interrupt return using
the CALL or JMP instructions were always going from kernel or user mode to
kernel mode, when using a call gate. This assumption is violated if
the c
On Fri, Oct 25, 2024 at 5:26 PM Michael Tokarev wrote:
> > It can be picked up for 9.1.x, but for 9.0 and before it needs a few
> > other changes in this area, like v9.0.0-2238-g8053862af9 "target/i386/tcg:
> > Compute MMU index once" and v9.0.0-2236-g059368bcf5 "target/i386/tcg:
> > Reorg push/po
On 25/10/24 10:57, Daniel P. Berrangé wrote:
On Fri, Oct 25, 2024 at 02:50:50PM +0100, Peter Maydell wrote:
I notice that with the recent migration to check-functional we
seem to be using a lot of disk space in the build tree: for
one of my build trees
du -h build/arm-clang/tests/functional/
r
Queued, thanks for offering to help!
Paolo
--generate-cstr is a good idea and generally the right thing to do,
but it is not available in Debian 12 and Ubuntu 22.04. Work around
the absence.
Signed-off-by: Paolo Bonzini
---
meson.build | 4 +++-
rust/hw/char/pl011/src/device.rs | 1 +
rust/qemu-api/src/device_cl
Hi,
Since e3c07527f3 (crypto/hash: Implement and use new hash API,
2024-10-08), we've been seeing a memory leak in two check-unit tests:
test-crypto-hash and test-crypto-ivgen. Looking a bit further to try and
plug the leak, I got a bit confused regarding how the result crypto
buffer is handled. L
From: Manos Pitsidianakis
This code juxtaposed what should be happening according to the C device
model but is not needed now that this has been reviewed (I hope) and its
validity checked against what the C device does (I hope, again).
No functional change.
Signed-off-by: Manos Pitsidianakis
S
On 10/24/24 00:44, Thomas Huth wrote:
On 24/10/2024 02.11, Rob Landley wrote:
I use it, and ship system images for it:
https://landley.net/bin/mkroot/latest/sh4eb.tgz
Oh, that's interesting, I've been told that the r2d machine does not
work in big endian mode:
https://lore.kernel.org/
Occasionally, we may need to silence warnings and clippy lints that
were only introduced in newer Rust compiler versions. However, this
would fail when compiling with an older rustc:
error: unknown lint: `non_local_definitions`
--> rust/qemu-api/rust-qemu-api-tests.p/structured/offset_of.rs:79
From: Manos Pitsidianakis
Add a device specialization for the Luminary UART device.
This commit adds a DeviceId enum that utilizes the Index trait to return
different bytes depending on what device id the UART has (Arm -default-
or Luminary)
Signed-off-by: Manos Pitsidianakis
Signed-off-by: Pa
Cope with the old version that is provided in Debian 12.
--size_t-is-usize is needed on bindgen <0.61.0, and it was removed in
bindgen 0.65.0, so check for it in meson.build.
--merge-extern-blocks was added in 0.61.0.
--formatter rustfmt was added in 0.65.0 and is the default, so remove it.
Apa
Replay the configuration that would be computed by build.rs when compiling
on a 1.63.0 compiler.
Reviewed-by: Junjie Mao
Signed-off-by: Paolo Bonzini
---
subprojects/packagefiles/proc-macro2-1-rs/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/subprojects/pack
On 10/25/24 17:18, Michael Tokarev wrote:
20.10.2024 16:01, Avihai Horon:
vfio_state_pending_exact() is used to update migration core how much
device data is left for the device migration. Currently, the sum of
pre-copy and stop-copy sizes of the VFIO device are reported.
The pre-copy size is o
core::ffi::c_* types were introduced in Rust 1.64.0. Use the older types
in std::os::raw, which are now aliases of the types in core::ffi. There is
no need to compile QEMU as no_std, so this is acceptable as long as we support
a version of Debian with Rust 1.63.0.
Reviewed-by: Zhao Liu
Signed-o
Disable the detection code altogether if have_system == false.
Signed-off-by: Paolo Bonzini
---
meson.build | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/meson.build b/meson.build
index 69b8367eb3c..d199bcdd824 100644
--- a/meson
On 10/24/24 03:27, Thomas Huth wrote:
This reverts commit 73ceb12960e686b763415f0880cc5171ccce01cf.
The "r2d" machine can work in big endian mode, see:
https://lore.kernel.org/qemu-devel/d6755445-1060-48a8-82b6-2f392c21f...@landley.net/
So the reasoning for removing sh4eb was wrong.
Signed
We have fixed all incompatibilities with older versions of rustc
and bindgen. Enable Rust on Debian to check that the minimum
supported version of Rust is indeed 1.63.0, and 0.60.x for bindgen.
Signed-off-by: Paolo Bonzini
---
.gitlab-ci.d/buildtest.yml | 4 ++--
1 file changed, 2 insertions(+)
On Fri, Oct 25, 2024 at 12:11:51PM -0300, Philippe Mathieu-Daudé wrote:
> On 24/10/24 17:53, Peter Xu wrote:
> > On Thu, Oct 24, 2024 at 05:02:19PM -0300, Philippe Mathieu-Daudé wrote:
> > > Hi Peter,
> >
> > Hi, Phil,
> >
> > Thanks for the quick reviews!
> >
> > >
> > > (Cc'ing Mark)
> > >
>
On Fri, Oct 25, 2024 at 12:17:02PM -0400, Peter Xu wrote:
> On Fri, Oct 25, 2024 at 10:51:21AM +0100, Daniel P. Berrangé wrote:
> > > diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c
> > > index e91a235347..ecc1cf781c 100644
> > > --- a/qom/qom-qmp-cmds.c
> > > +++ b/qom/qom-qmp-cmds.c
> > > @@
I disagree with your points, Paolo. A patch review should not be "Fear
Uncertainty and Doubt" but point out actual problems with the code.
Please do not proceed with this conversation since it's not
productive.
If this series misses softfreeze because of code problems or by people
delaying the rev
On Fri, Oct 25, 2024 at 10:51:21AM +0100, Daniel P. Berrangé wrote:
> On Thu, Oct 24, 2024 at 12:56:24PM -0400, Peter Xu wrote:
>
> Adding significant new functionality to QOM should really come
> with a commit message explaining the rationale and the design
> choices
>
> > Signed-off-by: Peter X
Paolo, you picked up my patches without us first talking about it.
This is not how things should work.
On Fri, Oct 25, 2024 at 01:06:01PM -0300, Matheus Tavares Bernardino wrote:
> Hi,
>
> Since e3c07527f3 (crypto/hash: Implement and use new hash API,
> 2024-10-08), we've been seeing a memory leak in two check-unit tests:
> test-crypto-hash and test-crypto-ivgen. Looking a bit further to try and
>
On 10/24/24 09:25, Richard Henderson wrote:
On 10/23/24 23:20, Pierrick Bouvier wrote:
When instrumenting memory accesses for plugin, we force memory accesses
to use the slow path for mmu. [1]
This create a situation where we end up calling ptw_setl_slow.
Since this function gets called duri
On Fri, Oct 25, 2024, 5:51 a.m. Daniel P. Berrangé
wrote:
> On Thu, Oct 24, 2024 at 12:56:24PM -0400, Peter Xu wrote:
>
> Adding significant new functionality to QOM should really come
> with a commit message explaining the rationale and the design
> choices
>
Ohh i definitely missed it, my bad.
On Fri, Oct 25, 2024 at 12:50:45PM +0200, Klaus Jensen wrote:
> @@ -1520,9 +1520,16 @@ static void nvme_post_cqes(void *opaque)
> nvme_inc_cq_tail(cq);
> nvme_sg_unmap(&req->sg);
> +
> +if (QTAILQ_EMPTY(&sq->req_list) && !nvme_sq_empty(sq)) {
> +qemu_bh_schedul
The next commit will introduce a new build.rs dependency for rust/qemu-api,
version_check. Before adding it, ensure that all dependencies are
synchronized between the Meson- and cargo-based build systems.
Note that it's not clear whether in the long term we'll use Cargo for
anything; it seems tha
Working on XIVE has been one of the most complex and fascinating
experiences for me. It's been a real journey, and now it's time for
IBM to take over and guide its future. I'm stepping back as the
maintainer of XIVE.
Cc: Michael Kowal
Cc: Nicholas Piggin
Cc: Frédéric Barrat
Signed-off-by: Cédri
Introduce migration_mutex, protecting concurrent updates to
current_migration.
In reality, most of the exported migration functions are safe to access
migration objects on capabilities, etc., e.g. many of the code is invoked
within migration thread via different hooks (e.g., precopy notifier,
vmst
LFENCE and SFENCE were introduced with the original SSE instruction set;
marking them incorrectly as cpuid(SSE2) causes failures for CPU models
that lack SSE2, for example pentium3.
Reported-by: Guenter Roeck
Tested-by: Guenter Roeck
Cc: qemu-sta...@nongnu.org
Signed-off-by: Paolo Bonzini
---
On Thu, Oct 24, 2024 at 12:56:24PM -0400, Peter Xu wrote:
Adding significant new functionality to QOM should really come
with a commit message explaining the rationale and the design
choices
> Signed-off-by: Peter Xu
> ---
> include/qom/object_interfaces.h | 47 +
On Mon, Oct 21, 2024 at 06:35:37PM +0200, Paolo Bonzini wrote:
> Date: Mon, 21 Oct 2024 18:35:37 +0200
> From: Paolo Bonzini
> Subject: [PATCH v2 12/13] rust: provide safe wrapper for
> MaybeUninit::zeroed()
> X-Mailer: git-send-email 2.46.2
>
> MaybeUninit::zeroed() is handy, but it introduces
We want to give a chance to override the value of host ID regs.
In a previous patch we made sure all their values could be fetched
through kvm_get_one_reg() calls before their modification. After
their potential modification we need to make sure we write back
the values through kvm_set_one_reg() ca
We recently converted from the LegacyReset to the new reset framework
in commit c009a311e939 ("virtio-mem: Use new Resettable framework instead
of LegacyReset") to be able to use the ResetType to filter out wakeup
resets.
However, this change had an undesired implications: as we override the
Reset
This RFC series introduces a KVM host "custom" model.
Since v6.7 kernel, KVM/arm allows the userspace to overwrite the values
of a subset of ID regs. The list of writable fields continues to grow.
The feature ID range is defined as the AArch64 System register space
with op0==3, op1=={0, 1, 3}, CRn
I put it under my name as there may be other maintainer testing trees
as well.
Reviewed-by: Thomas Huth
Signed-off-by: Alex Bennée
Message-Id: <20241023113406.1284676-4-alex.ben...@linaro.org>
diff --git a/MAINTAINERS b/MAINTAINERS
index c3bfa132fd..ef1678a1a8 100644
--- a/MAINTAINERS
+++ b/MAI
In cf_fpu_gdb_get_reg() and cf_fpu_gdb_set_reg() we use a temporary
float_status variable to pass to floatx80_to_float64() and
float64_to_floatx80(), but we don't initialize it, meaning that those
functions could access uninitialized data. Zero-init the structs.
(We don't need to set a NaN-propag
Although the floating point rounding mode for Microblaze is always
nearest-even, we cannot set it just once in the CPU initfn. This is
because env->fp_status is in the part of the CPU state struct that is
zeroed on reset.
Move the call to set_float_rounding_mode() into the reset fn.
(This had no
Set the 2-NaN propagation rule explicitly in env->fp_status.
Really we only need to do this at CPU reset (after reset has zeroed
out most of the CPU state struct, which typically includes fp_status
fields). However target/hppa does not currently implement CPU reset
at all, so leave a TODO comment
Set the NaN propagation rule explicitly in the float_status
words we use.
Signed-off-by: Peter Maydell
---
target/sparc/cpu.c | 8
target/sparc/fop_helper.c | 10 --
fpu/softfloat-specialize.c.inc | 6 ++
3 files changed, 18 insertions(+), 6 deletions(-)
IEEE 758 does not define a fixed rule for which NaN to pick as the
result if both operands of a 2-operand operation are NaNs. As a
result different architectures have ended up with different rules for
propagating NaNs.
QEMU currently hardcodes the NaN propagation logic into the binary
because pic
Now that all targets have been converted to explicitly set a NaN
propagation rule, we can remove the set of target ifdefs (which now
list every target) and clean up the references to fallback behaviour
for float_2nan_prop_none.
The "default" case in the switch will catch any remaining places
where
Explicitly set a 2-NaN propagation rule in the softfloat tests. In
meson.build we put -DTARGET_ARM in fpcflags, and so we should select
here the Arm propagation rule of float_2nan_prop_s_ab.
Signed-off-by: Peter Maydell
---
tests/fp/fp-bench.c | 2 ++
tests/fp/fp-test-log2.c | 1 +
tests/fp
In xtensa we currently call set_use_first_nan() in a lot of
places where we want to switch the NaN-propagation handling.
We're about to change the softfloat API we use to do that,
so start by factoring all the calls out into a single
xtensa_use_first_nan() function.
The bulk of this change was don
Set the NaN propagation rule explicitly for the float_status word
used in the openrisc target.
Signed-off-by: Peter Maydell
---
target/openrisc/cpu.c | 6 ++
fpu/softfloat-specialize.c.inc | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/target/openrisc/cpu.c b/
Set the NaN propagation rule explicitly for the float_status word
used in this target.
This is a no-behaviour-change commit, so we retain the existing
behaviour of x87-style pick-largest-significand NaN propagation.
This is however not the architecturally correct handling, so we leave
a TODO note
Set the 2-NaN propagation rule explicitly in the float_status words
we use.
For active_fpu.fp_status, we do this in a new fp_reset() function
which mirrors the existing msa_reset() function in doing "first call
restore to set the fp status parts that depend on CPU state, then set
the fp status par
Currently we call cpu_put_fsr(0) in sparc_cpu_realizefn(), which
initializes various fields in the CPU struct:
* fsr_cexc_ftt
* fcc[]
* fsr_qne
* fsr
It also sets the rounding mode in env->fp_status.
This is largely pointless, because when we later reset the CPU
this will zero out all the fiel
On 10/25/2024 9:43 AM, Daniel P. Berrangé wrote:
On Fri, Oct 25, 2024 at 09:33:51AM -0400, Steven Sistare wrote:
On 10/25/2024 4:46 AM, Daniel P. Berrangé wrote:
On Thu, Oct 24, 2024 at 05:16:14PM -0400, Steven Sistare wrote:
Regarding: "what you want is effectively to execute monitor command
On Thu, 24 Oct 2024 at 07:38, Cédric Le Goater wrote:
>
> The following changes since commit 6f625ce2f21d6a1243065d236298277c56f972d5:
>
> Merge tag 'pull-request-2024-10-21' of https://gitlab.com/thuth/qemu into
> staging (2024-10-21 17:12:59 +0100)
>
> are available in the Git repository at:
On 10/24/24 23:30, Peter Xu wrote:
Now with the current migration_is_running(), it will report exactly the
opposite of what will be reported by migration_is_idle().
Drop migration_is_idle(), instead use "!migration_is_running()" which
should be identical on functionality.
In reality, most of th
On Fri, Oct 25, 2024 at 12:17:32PM +0200, Eric Auger wrote:
> The known ID regs are described in a new initialization function
> dubbed initialize_cpu_sysreg_properties(). That code will be
> automatically generated from linux arch/arm64/tools/sysreg. For the
> time being let's just describe a sing
1 - 100 of 300 matches
Mail list logo
