On 5/25/2025 8:47 PM, Xiaoyao Li wrote:
On 1/3/2025 4:48 PM, Xin Li (Intel) wrote:
@@ -1133,6 +1134,25 @@ FeatureWordInfo
feature_word_info[FEATURE_WORDS] = {
},
.tcg_features = TCG_7_1_EAX_FEATURES,
},
+ [FEAT_7_1_ECX] = {
+ .type = CPUID_FEATURE_WORD,
+
Hi everyone,
The QEMU v9.2.4 stable release is now available.
You can grab the tarball from our download page here:
https://www.qemu.org/download/#source
https://download.qemu.org/qemu-9.2.4.tar.xz
https://download.qemu.org/qemu-9.2.4.tar.xz.sig (signature)
v9.2.4 is now tagged in the of
On 5/2/2025 7:46 AM, Alejandro Jimenez wrote:
On reset, restore the default address translation mode for all the
address spaces managed by the vIOMMU.
Signed-off-by: Alejandro Jimenez
---
hw/i386/amd_iommu.c | 28
1 file changed, 28 insertions(+)
diff --git a
qemu-thread used to abstract pthread primitives into futex for the
QemuEvent implementation of POSIX systems other than Linux. However,
this abstraction has one key difference: unlike futex, pthread
primitives require an explicit destruction, and it must be ordered after
wait and wake operations.
The pair of smp_mb() and qatomic_read() sometimes allows skipping the
following qatomic_xchg() call, but it is unclear if it improves
performance so remove it.
Commit 374293ca6fb0 ("qemu-thread: use acquire/release to clarify
semantics of QemuEvent") replaced atomic_mb_read() in qemu_event_set()
w
Use the futex-based implementation of QemuEvent on Windows to
remove code duplication and remove the overhead of event object
construction and destruction.
Signed-off-by: Akihiko Odaki
Reviewed-by: Philippe Mathieu-Daudé
---
include/qemu/thread-posix.h | 9 ---
include/qemu/thread-win32.h |
thread_sync_sem is an one-shot event so it can be converted into
QemuEvent, which is more lightweight.
Signed-off-by: Akihiko Odaki
Reviewed-by: Fabiano Rosas
---
migration/migration.h| 4 ++--
migration/postcopy-ram.c | 10 +-
migration/savevm.c | 2 +-
3 files changed, 8 i
scripts/checkpatch.pl warns for __linux__ saying "architecture specific
defines should be avoided".
Signed-off-by: Akihiko Odaki
Reviewed-by: Philippe Mathieu-Daudé
---
include/qemu/thread-posix.h | 2 +-
util/qemu-thread-posix.c| 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
Document QemuEvent to help choose an appropriate synchronization
primitive.
Signed-off-by: Akihiko Odaki
---
include/qemu/thread.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/qemu/thread.h b/include/qemu/thread.h
index 573f8c9ede20..f0302ed01fdb 100644
--- a/include/q
Windows supports futex-like APIs since Windows 8 and Windows Server
2012.
Signed-off-by: Akihiko Odaki
---
meson.build | 2 ++
include/qemu/futex.h | 53 ++-
tests/unit/test-aio-multithread.c | 2 +-
util/lockcnt.c
colo_exit_sem and colo_incoming_sem represent one-shot events so they
can be converted into QemuEvent, which is more lightweight.
Signed-off-by: Akihiko Odaki
Reviewed-by: Fabiano Rosas
Reviewed-by: Philippe Mathieu-Daudé
---
migration/migration.h | 6 +++---
migration/colo.c | 20 ++
sem in AppleGFXReadMemoryJob is an one-shot event so it can be converted
into QemuEvent, which is more specialized for such a use case.
Signed-off-by: Akihiko Odaki
Reviewed-by: Philippe Mathieu-Daudé
---
hw/display/apple-gfx.m | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
d
futex(2) - Linux manual page
https://man7.org/linux/man-pages/man2/futex.2.html
> Note that a wake-up can also be caused by common futex usage patterns
> in unrelated code that happened to have previously used the futex
> word's memory location (e.g., typical futex-based implementations of
> Pthrea
In a recent discussion, Phil Dennis-Jordan pointed out a quirk in
QemuEvent destruction due to futex-like abstraction, which prevented
the usage of QemuEvent in new and existing code[1]. With some more
thoughts after this discussion, I also found other problem and room
of improvement in futex usage
This unlocks the futex-based implementation of QemuLockCnt to Windows.
Signed-off-by: Akihiko Odaki
---
include/qemu/lockcnt.h | 2 +-
util/lockcnt.c | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/qemu/lockcnt.h b/include/qemu/lockcnt.h
index f4b62a3f
On Wed, May 28, 2025 at 12:07:21PM +0100, Jonathan Cameron wrote:
> v14: Simplifications suggeseted by Itaru (and some extra simplifications
> that became apparent) and gather tags.
> See individual patches for more information.
>
> Updated cover letter
>
> Richard Henderson has posted
Hi,
On 5/29/2025 3:47 AM, Alejandro Jimenez wrote:
> Correct mistakes in bitmasks, offsets, decoding of fields, and behavior that
> do not match the latest AMD I/O Virtualization Technology (IOMMU)
> Specification. These bugs do not trigger problems today in the limited mode
> of operation support
On 5/29/2025 3:47 AM, Alejandro Jimenez wrote:
> Address various issues with definitions of the MMIO registers e.g. for the
> Device Table Address Register, the size mask currently encompasses reserved
> bits [11:9], so change it to only extract the bits [8:0] encoding size.
>
> Convert masks t
While trying to export and obtain fds associated with a texture, it
is possible that the fds returned after eglExportDMABUFImageMESA()
call have error values. Therefore, we need to evaluate the value of
all fds and return false if any of them are negative.
Cc: Gerd Hoffmann
Cc: Marc-André Lureau
In the specific case where the display layer (virtio-gpu) is using
dmabuf, and if remote clients are enabled (-spice gl=on,port=),
it makes sense to limit the maximum (streaming) rate (refresh rate)
to a fixed value using the GUI refresh timer. Otherwise, the updates
or gl_draw requests would b
In cases where the scanout buffer is provided as a texture (e.g. Virgl)
we need to check to see if it has a linear memory layout or not. If
it doesn't have a linear layout, then blitting it onto the texture
associated with the display surface (which already has a linear layout)
seems to ensure that
Newer versions of Spice server should be able to accept dmabuf
fds from Qemu for clients that are connected via the network.
In other words, when this option is enabled, Qemu would share
a dmabuf fd with Spice which would encode and send the data
associated with the fd to a client that could be loc
There are cases where we do not want the memory layout of a texture to
be tiled as the component processing the texture would not know how to
de-tile either via software or hardware. Therefore, ensuring that the
memory backing the texture has a linear layout is absolutely necessary
in these situati
Since most encoders/decoders (invoked by Spice) may not work properly
with tiled memory associated with a texture, we need to create another
texture that has linear memory layout and use that instead.
Note that, there does not seem to be a direct way to indicate to the
GL implementation that a tex
Giving users an option to choose a particular codec will enable
them to make an appropriate decision based on their hardware and
use-case.
Cc: Gerd Hoffmann
Cc: Marc-André Lureau
Cc: Dmitry Osipenko
Cc: Frediano Ziglio
Cc: Dongwon Kim
Cc: Michael Scherle
Signed-off-by: Vivek Kasireddy
---
To address the limitation that this option is incompatible with
remote clients, this patch series adds an option to select a
preferred codec and also enable gl=on option for clients that
are connected via the network. In other words, with this option
enabled (and the below linked Spice series merge
On Thu, May 22, 2025 at 6:14 PM Jay Chang wrote:
>
> Previously, the number of PMP regions was hardcoded to 16 in QEMU.
> This patch replaces the fixed value with a new `pmp_regions` field,
> allowing platforms to configure the number of PMP regions.
>
> If no specific value is provided, the defau
On 2025/05/26 18:29, Philippe Mathieu-Daudé wrote:
On 26/5/25 11:27, Philippe Mathieu-Daudé wrote:
On 26/5/25 07:29, Akihiko Odaki wrote:
sem in AppleGFXReadMemoryJob is an one-shot event so it can be converted
into QemuEvent, which is more specialized for such a use case.
BTW it would be nic
On 5/29/2025 3:47 AM, Alejandro Jimenez wrote:
> Fix an off-by-one error in the definition of AMDVI_IR_PHYS_ADDR_MASK. The
> current definition masks off the most significant bit of the Interrupt Table
> Root ptr i.e. it only generates a mask with bits [50:6] set. See the AMD I/O
> Virtualizatio
On Wed, May 21, 2025 at 3:24 AM Daniel Henrique Barboza
wrote:
>
> Hi,
>
> The motivation of this short series is to fix a reported in [1]. A
> couple of bugs were fixed along the way.
>
> Björn, these patches should remediate the situation you're experiencing.
>
> Patches based on master.
>
> [1]
On 2025/05/28 22:00, 'Eric Blake' via devel wrote:
On Wed, May 28, 2025 at 08:30:05PM +0900, Akihiko Odaki wrote:
file-posix used to assume that existing holes satisfy the requested
alignment, which equals to the estimated direct I/O alignment
requirement if direct I/O is requested, and assert t
On 5/29/2025 3:47 AM, Alejandro Jimenez wrote:
> No functional change.
>
> Signed-off-by: Alejandro Jimenez
I had similar fix locally :-) Thanks for fixing it.
Reviewed-by: Vasant Hegde
-Vasant
On Wed, May 21, 2025 at 3:24 AM Daniel Henrique Barboza
wrote:
>
> Björn reported in [1] a case where a rv64 CPU is going through the
> profile code path to enable satp mode. In this case,the amount of
> extensions on top of the rv64 CPU made it compliant with the RVA22S64
> profile during the val
On Wed, May 28, 2025 at 4:13 PM Ethan Chen wrote:
>
> On Thu, May 22, 2025 at 11:24:28AM +1000, Alistair Francis wrote:
> > [EXTERNAL MAIL]
> >
> > On Wed, Mar 12, 2025 at 7:43 PM Ethan Chen via
> > wrote:
> > >
> > > - Add 'iopmp=on' option to enable IOPMP. It adds iopmp devices virt
> > > mac
On Wed, May 21, 2025 at 3:24 AM Daniel Henrique Barboza
wrote:
>
> We have code in riscv_cpu_add_profiles() to enable a profile right away
> in case a CPU chose the profile during its cpu_init(). But we're using
> the user callback option to do so, setting profile->user_set.
>
> Create a new helpe
On Wed, May 21, 2025 at 3:24 AM Daniel Henrique Barboza
wrote:
>
> We're changing 'mmu' to true regardless of whether the profile is
> being enabled or not, and at the same time we're changing satp_mode to
> profile->enabled.
>
> This will promote a situation where we'll set mmu=on without a virtu
On Wed, May 28, 2025 at 03:09:14PM -0400, Stefan Hajnoczi wrote:
> Introduce the aio_add_sqe() API for submitting io_uring requests in the
> current AioContext. This allows other components in QEMU, like the block
> layer, to take advantage of io_uring features without creating their own
> io_uring
The DeviceID bits are extracted using an incorrect offset in the call to
amdvi_iotlb_remove_page(). This field is read (correctly) earlier, so use
the value already retrieved for devid.
Cc: qemu-sta...@nongnu.org
Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Alejandro Jimenez
The DTE validation method verifies that all bits in reserved DTE fields are
unset. Update them according to the latest definition available in AMD I/O
Virtualization Technology (IOMMU) Specification - Section 2.2.2.1 Device
Table Entry Format. Remove the magic numbers and use a macro helper to
gene
Correct mistakes in bitmasks, offsets, decoding of fields, and behavior that
do not match the latest AMD I/O Virtualization Technology (IOMMU)
Specification. These bugs do not trigger problems today in the limited mode
of operation supported by the AMD vIOMMU (passthrough), but upcoming
functionali
No functional change.
Signed-off-by: Alejandro Jimenez
---
hw/i386/amd_iommu.h | 4
1 file changed, 4 deletions(-)
diff --git a/hw/i386/amd_iommu.h b/hw/i386/amd_iommu.h
index 1836b7061d848..31e473924fa20 100644
--- a/hw/i386/amd_iommu.h
+++ b/hw/i386/amd_iommu.h
@@ -206,10 +206,6 @@
/* C
Address various issues with definitions of the MMIO registers e.g. for the
Device Table Address Register, the size mask currently encompasses reserved
bits [11:9], so change it to only extract the bits [8:0] encoding size.
Convert masks to use GENMASK64 for consistency, and make unrelated
definiti
Correctly calculate the Device Table size using the format encoded in the
Device Table Base Address Register (MMIO Offset h).
Cc: qemu-sta...@nongnu.org
Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Alejandro Jimenez
Reviewed-by: Vasant Hegde
---
hw/i386/amd_iommu.c |
The definitions encoding the maximum Virtual, Physical, and Guest Virtual
Address sizes supported by the IOMMU are using incorrect offsets i.e. the
VASize and GVASize offsets are switched.
Cc: qemu-sta...@nongnu.org
Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Alejandro Jime
Fix an off-by-one error in the definition of AMDVI_IR_PHYS_ADDR_MASK. The
current definition masks off the most significant bit of the Interrupt Table
Root ptr i.e. it only generates a mask with bits [50:6] set. See the AMD I/O
Virtualization Technology (IOMMU) Specification for the Interrupt Table
Fix an off-by-one error in the definition of AMDVI_IR_PHYS_ADDR_MASK. The
current definition masks off the most significant bit of the Interrupt Table
Root ptr i.e. it only generates a mask with bits [50:6] set. See the AMD I/O
Virtualization Technology (IOMMU) Specification for the Interrupt Table
On Wed, May 28, 2025 at 03:09:13PM -0400, Stefan Hajnoczi wrote:
> io_uring may not be available at runtime due to system policies (e.g.
> the io_uring_disabled sysctl) or creation could fail due to file
> descriptor resource limits.
>
> Handle failure scenarios as follows:
>
> If another AioCont
Hi Jonathan,
On Wed, May 28, 2025 at 12:07:21PM +0100, Jonathan Cameron wrote:
> v14: Simplifications suggeseted by Itaru (and some extra simplifications
> that became apparent) and gather tags.
> See individual patches for more information.
I think the suggestion was made by Zhi jian o
On Wed, May 28, 2025 at 03:09:12PM -0400, Stefan Hajnoczi wrote:
> When aio_context_new() -> aio_context_setup() fails at startup it
> doesn't really matter whether errors are returned to the caller or the
> process terminates immediately.
>
> However, it is not acceptable to terminate when hotplu
On Wed, May 28, 2025 at 03:09:11PM -0400, Stefan Hajnoczi wrote:
> g_source_destroy() only removes the GSource from the GMainContext it's
> attached to, if any. It does not free it.
>
> Use g_source_unref() instead so that the AioContext (which embeds a
> GSource) is freed. There is no need to cal
On Wed, May 28, 2025 at 03:09:10PM -0400, Stefan Hajnoczi wrote:
> There is no need for aio_context_use_g_source() now that epoll(7) and
> io_uring(7) file descriptor monitoring works with the glib event loop.
> AioContext doesn't need to be notified that GSource is being used.
>
> Signed-off-by:
On Wed, May 28, 2025 at 03:09:09PM -0400, Stefan Hajnoczi wrote:
> AioContext's glib integration only supports ppoll(2) file descriptor
> monitoring. epoll(7) and io_uring(7) disable themselves and switch back
> to ppoll(2) when the glib event loop is used. The main loop thread
> cannot use epoll(7
Hi Thomas,
On 5/28/25 09:11, Gustavo Romero wrote:
Hi Thomas,
On 5/28/25 04:57, Thomas Huth wrote:
On 28/05/2025 03.47, Gustavo Romero wrote:
The current links for the Linux and initrd.gz images are not truly
immutable, so let's change them to point to immutable versions, to avoid
having to k
On Wed, May 28, 2025 at 03:09:08PM -0400, Stefan Hajnoczi wrote:
> test-nested-aio-poll relies on internal details of how fdmon-poll.c
> handles AioContext polling. Skip it when other fdmon implementations are
> in use.
>
> Note that this test is only built on POSIX systems so it is safe to
> incl
On Wed, May 28, 2025 at 03:09:07PM -0400, Stefan Hajnoczi wrote:
> Commit 816a430c517e ("util/aio: Defer disabling poll mode as long as
> possible") kept polling enabled when the event loop timeout is 0. Since
> there is no timeout the event loop will continue immediately and the
> overhead of disa
We want to configure other CPU types to use profiles as an alternative
to adding every profile extension explicitly, i.e. a profile is nothing
more than an extension bundle.
This means that a vendor CPU can set .profile=rva23s64 while having the
same handling as any other vendor CPU. Same thing wi
Add a functional test, aarch64_hotplug_pci, to exercise PCI hotplug and
hot-unplug on arm64.
Signed-off-by: Gustavo Romero
Reviewed-by: Daniel P. Berrangé
Acked-by: Thomas Huth
---
MAINTAINERS | 6 ++
tests/functional/meson.build | 1 +
tests/
On Wed, May 28, 2025 at 03:09:06PM -0400, Stefan Hajnoczi wrote:
> The io_uring(7) file descriptor monitor cannot enter polling mode
> because it needs to submit a POLL_ADD SQE every time a file descriptor
> becomes active. Submitting SQEs only happens in FDMonOps->wait() outside
> of polling mode.
Hi Stefan!
The following changes since commit 80db93b2b88f9b3ed8927ae7ac74ca30e643a83e:
Merge tag 'pull-aspeed-20250526' of https://github.com/legoater/qemu into
staging (2025-05-26 10:16:59 -0400)
are available in the Git repository at:
https://gitlab.com/thuth/qemu.git tags/pull-request
On 28/05/2025 21.23, Stefan Hajnoczi wrote:
On Wed, May 28, 2025 at 6:12 AM Thomas Huth wrote:
Hi!
The following changes since commit 80db93b2b88f9b3ed8927ae7ac74ca30e643a83e:
Merge tag 'pull-aspeed-20250526' of https://github.com/legoater/qemu into
staging (2025-05-26 10:16:59 -0400)
Add an always present IOMMU platform device for the rvsp-ref board.
The IRQs being used are similar to what the 'virt' board is using: IRQs
36 to 39, one IRQ for queue.
Signed-off-by: Daniel Henrique Barboza
---
hw/riscv/Kconfig | 1 +
hw/riscv/server_platform_ref.c | 78
From: Fei Wu
The harts requirements of RISC-V server platform [1] require RVA23 ISA
profile support, plus Sv48, Svadu, H, Sscofmpf etc. This patch provides
a virt CPU type (rvsp-ref) as compliant as possible.
[1]
https://github.com/riscv-non-isa/riscv-server-platform/blob/main/server_platform_r
Hi,
This is my attempt to ressurect the Server SoC Platform reference work
that has been buried for an year. The last posting was made an year ago
[1].
Most of the changes were made due to upstream differences from one year
ago. Patch 1 is an example of that.
In patch 2 (former 1), the main dif
From: Fei Wu
The RISC-V Server Platform specification[1] defines a standardized set
of hardware and software capabilities, that portable system software,
such as OS and hypervisors can rely on being present in a RISC-V server
platform.
A corresponding Qemu RISC-V server platform reference (rvsp-
On Wed, May 28, 2025 at 6:12 AM Thomas Huth wrote:
>
> Hi!
>
> The following changes since commit 80db93b2b88f9b3ed8927ae7ac74ca30e643a83e:
>
> Merge tag 'pull-aspeed-20250526' of https://github.com/legoater/qemu into
> staging (2025-05-26 10:16:59 -0400)
>
> are available in the Git repositor
I have shared v2 with updated commit msg to everyone in form of a new PATCH.
Please check it and let me know if anything is still missing or confusing.
On Wed, 28 May 2025 at 11:36 PM, Stefan Hajnoczi wrote:
> On Mon, May 26, 2025 at 10:51 PM Tanish Desai
> wrote:
> >
> > > Can you explain 3 m
This change improves performance by moving the hot path of the
trace_vhost_commit()(or any other trace function) logic to the header file.
Previously, even when the trace event was disabled, the function call chain:-
trace_vhost_commit()(Or any other trace function) →
_nocheck__trace_vho
This patch series contains io_uring improvements:
1. Support the glib event loop in fdmon-io_uring.
- aio-posix: fix polling mode with fdmon-io_uring
- aio-posix: keep polling enabled with fdmon-io_uring.c
- tests/unit: skip test-nested-aio-poll with io_uring
- aio-posix: integrate fdm
Introduce the aio_add_sqe() API for submitting io_uring requests in the
current AioContext. This allows other components in QEMU, like the block
layer, to take advantage of io_uring features without creating their own
io_uring context.
This API supports nested event loops just like file descriptor
AioContext's glib integration only supports ppoll(2) file descriptor
monitoring. epoll(7) and io_uring(7) disable themselves and switch back
to ppoll(2) when the glib event loop is used. The main loop thread
cannot use epoll(7) or io_uring(7) because it always uses the glib event
loop.
Future QEMU
The io_uring(7) file descriptor monitor cannot enter polling mode
because it needs to submit a POLL_ADD SQE every time a file descriptor
becomes active. Submitting SQEs only happens in FDMonOps->wait() outside
of polling mode.
Fix this using the multi-shot mechanism introduced in Linux 5.13 and
li
AioContext has its own io_uring instance for file descriptor monitoring.
The disk I/O io_uring code was developed separately. Originally I
thought the characteristics of file descriptor monitoring and disk I/O
were too different, requiring separate io_uring instances.
Now it has become clear to me
g_source_destroy() only removes the GSource from the GMainContext it's
attached to, if any. It does not free it.
Use g_source_unref() instead so that the AioContext (which embeds a
GSource) is freed. There is no need to call g_source_destroy() in
aio_context_new() because the GSource isn't attache
test-nested-aio-poll relies on internal details of how fdmon-poll.c
handles AioContext polling. Skip it when other fdmon implementations are
in use.
Note that this test is only built on POSIX systems so it is safe to
include "util/aio-posix.h".
Signed-off-by: Stefan Hajnoczi
---
tests/unit/test
fdmon_ops->wait() is called with notify_me enabled. This makes it an
expensive place to call qemu_bh_schedule() because aio_notify() invokes
write(2) on the EventNotifier.
Moving qemu_bh_schedule() after notify_me is reset improves IOPS from
270k to 300k IOPS with --blockdev file,aio=io_uring.
I
There is no need for aio_context_use_g_source() now that epoll(7) and
io_uring(7) file descriptor monitoring works with the glib event loop.
AioContext doesn't need to be notified that GSource is being used.
Signed-off-by: Stefan Hajnoczi
---
include/block/aio.h | 3 ---
tests/uni
Commit 816a430c517e ("util/aio: Defer disabling poll mode as long as
possible") kept polling enabled when the event loop timeout is 0. Since
there is no timeout the event loop will continue immediately and the
overhead of disabling and re-enabling polling can be avoided.
fdmon-io_uring.c is unable
io_uring may not be available at runtime due to system policies (e.g.
the io_uring_disabled sysctl) or creation could fail due to file
descriptor resource limits.
Handle failure scenarios as follows:
If another AioContext already has io_uring, then fail AioContext
creation so that the aio_add_sqe
When aio_context_new() -> aio_context_setup() fails at startup it
doesn't really matter whether errors are returned to the caller or the
process terminates immediately.
However, it is not acceptable to terminate when hotplugging --object
iothread at runtime. Refactor aio_context_setup() so that er
On 5/27/25 9:59 PM, Markus Armbruster wrote:
Pierrick Bouvier writes:
On 5/27/25 4:20 AM, Markus Armbruster wrote:
Pierrick Bouvier writes:
Signed-off-by: Pierrick Bouvier
My comment on the previous patch applies.
I'm not sure to which comment exactly you refer to.
Should've been e
From: Daniel P. Berrangé
This removes the TARGET_* conditions from all the CPU commands
that are conceptually target independent. Top level stubs are
provided to cope with targets which do not currently implement
all of the commands. Adjust the doc comments accordingly.
Reviewed-by: Richard Hend
Eric Blake writes:
> On Wed, May 28, 2025 at 10:45:35AM -0500, Eric Blake wrote:
>> On Fri, May 23, 2025 at 11:27:22AM -0500, Eric Blake wrote:
>> > Fiona reported that an ext4 filesystem on top of LVM can sometimes
>> > report over-allocation to du (based on the hueristics the filesystem
>> > is
Hi,
In this version I removed an extra signed-off-by in patch 3.
No other changes made. Patches based on alistair/riscv-to-apply.next.
All patches acked.
Changes from v1:
- patch 3:
- removed a duplicated Signed-off-by tag
- v1 link:
https://lore.kernel.org/qemu-riscv/20250520172336.759708-1
We're changing 'mmu' to true regardless of whether the profile is
being enabled or not, and at the same time we're changing satp_mode to
profile->enabled.
This will promote a situation where we'll set mmu=on without a virtual
memory mode, which is a mistake.
Only touch 'mmu' and satp_mode if the
Björn reported in [1] a case where a rv64 CPU is going through the
profile code path to enable satp mode. In this case,the amount of
extensions on top of the rv64 CPU made it compliant with the RVA22S64
profile during the validation of CPU 0. When the subsequent CPUs were
initialized the static pro
We have code in riscv_cpu_add_profiles() to enable a profile right away
in case a CPU chose the profile during its cpu_init(). But we're using
the user callback option to do so, setting profile->user_set.
Create a new helper that does all the grunt work to enable/disable a
given profile. Use this
John Snow writes:
> This series is RFC-ish and based on python-qapi-linting-v4, which I
> think ... should show up in origin/master soon(?).
Please use
Based-on:
Out of time for today, or I'd hunt for the exact base myself.
From: Daniel P. Berrangé
This file is now empty and can thus be removed.
Observe the pre-existing bug with s390-skeys.c and target/i386/monitor.c
both including qapi-commands-misc-target.h despite not requiring it.
Reviewed-by: Richard Henderson
Signed-off-by: Daniel P. Berrangé
Signed-off-by
John Snow writes:
> If we remove the legacy parser, this formulation begins to fail because
> the body text is appended directly after the field list entry, which is
> invalid rST syntax.
>
> Markus: suggest where the new Exception(s) should go, if anywhere, and
> how to update the tests? I'm ass
On 5/27/25 11:01 PM, Markus Armbruster wrote:
Pierrick Bouvier writes:
On 5/27/25 4:26 AM, Markus Armbruster wrote:
[...]
All good for me.
The only question that crossed my mind when you asked for those changes previously was:
"Why does QAPI has it's own style, and not simply following th
From: Daniel P. Berrangé
This removes the TARGET_I386 condition from the SGX confidential
virtualization commands, moving them to the recently introduced
misc-i386.json QAPI file, given they are inherantly i386 specific
commands.
Observe a pre-existing bug that the "SGXEPCSection" struct lacked
From: Daniel P. Berrangé
This removes the TARGET_I386 condition from the SEV confidential
virtualization commands, moving them to the recently introduced
misc-i386.json QAPI file, given they are inherantly i386 specific
commands.
Reviewed-by: Richard Henderson
Signed-off-by: Daniel P. Berrangé
From: Pierrick Bouvier
As requested by Markus:
> We prefer imperative mood "Return" over "Returns".
Signed-off-by: Pierrick Bouvier
Message-ID: <20250522190542.588267-14-pierrick.bouv...@linaro.org>
Reviewed-by: Markus Armbruster
[Change several more]
---
qapi/audio.json | 2 +-
qapi/blo
From: Pierrick Bouvier
Monolithic files (qapi_nonmodule_outputs) can now be compiled just
once, so we can remove qapi_util_outputs logic.
This removes the need for any specific_ss file.
Signed-off-by: Pierrick Bouvier
Message-ID: <20250522190542.588267-13-pierrick.bouv...@linaro.org>
Reviewed-b
The following changes since commit 80db93b2b88f9b3ed8927ae7ac74ca30e643a83e:
Merge tag 'pull-aspeed-20250526' of https://github.com/legoater/qemu into
staging (2025-05-26 10:16:59 -0400)
are available in the Git repository at:
https://repo.or.cz/qemu/armbru.git tags/pull-qapi-2025-05-28
fo
On Wed, May 28, 2025 at 10:45:35AM -0500, Eric Blake wrote:
> On Fri, May 23, 2025 at 11:27:22AM -0500, Eric Blake wrote:
> > Fiona reported that an ext4 filesystem on top of LVM can sometimes
> > report over-allocation to du (based on the hueristics the filesystem
> > is making while observing the
From: Daniel P. Berrangé
This removes the TARGET_S390X and CONFIG_KVM conditions from the
CPU commands that are conceptually specific to s390x. Top level
stubs are provided to cope with non-s390x targets, or builds
without KVM.
The removal of CONFIG_KVM is justified by the fact there is no
conce
From: Daniel P. Berrangé
This removes the TARGET_ARM condition from the query-gic-capability
command. This requires providing a QMP command stub for non-ARM targets.
This in turn requires moving the command out of misc-target.json, since
that will trigger symbol poisoning errors when built from t
From: Pierrick Bouvier
There is no more QAPI files that need to be compiled per target, so we
can remove this. qapi_specific_outputs is now empty, so we can remove
the associated logic in meson.
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Richard Henderson
Reviewed-by: Markus Armbruster
Sign
From: Daniel P. Berrangé
This removes the TARGET_I386 condition from the Xen event channel
commands, moving them to the recently introduced misc-i386.json
QAPI file, given they are inherantly i386 specific commands.
Reviewed-by: Richard Henderson
Signed-off-by: Daniel P. Berrangé
Acked-by: Dav
1 - 100 of 296 matches
Mail list logo
