Hey Sairaj,
On 5/29/25 2:16 AM, Sairaj Kodilkar wrote:
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 +
On Fri, May 30, 2025 at 05:35:12PM +0800, Zhenzhong Duan wrote:
> Some device information returned by ioctl(IOMMU_GET_HW_INFO) are vendor
> specific. Save them as raw data in a union supporting different vendors,
> then vendor IOMMU can query the raw data with its fixed format for
> capability dire
On Fri, May 30, 2025 at 05:35:10PM +0800, Zhenzhong Duan wrote:
> Enhance HostIOMMUDeviceIOMMUFD object with 3 new members, specific
> to the iommufd BE + 2 new class functions.
>
> IOMMUFD BE includes IOMMUFD handle, devid and hwpt_id. IOMMUFD handle
> and devid are used to allocate/free ioas and
On Fri, May 30, 2025 at 05:35:11PM +0800, Zhenzhong Duan wrote:
> Implement [at|de]tach_hwpt handlers in VFIO subsystem. vIOMMU
> utilizes them to attach to or detach from hwpt on host side.
>
> Signed-off-by: Yi Liu
> Signed-off-by: Zhenzhong Duan
> Reviewed-by: Cédric Le Goater
Reviewed-by:
Em Fri, 30 May 2025 16:49:03 +0200
Igor Mammedov escreveu:
> On Fri, 30 May 2025 08:01:28 -0400
> "Michael S. Tsirkin" wrote:
>
> > On Wed, May 28, 2025 at 05:42:12PM +0200, Igor Mammedov wrote:
> > > On Tue, 20 May 2025 08:41:31 +0200
> > > Mauro Carvalho Chehab wrote:
> > >
> > > > Cr
On Fri, May 30, 2025 at 02:43:35PM +0100, Jonathan Cameron wrote:
> On Tue, 20 May 2025 17:33:46 +
> Anisa Su wrote:
>
> > On Tue, May 20, 2025 at 08:37:35AM -0700, Fan Ni wrote:
> > > On Thu, May 08, 2025 at 12:00:57AM +, anisa.su...@gmail.com wrote:
> > > > From: Anisa Su
> > > >
>
Hi!
For quite some time (almost whole day yesterday) I'm trying to find out
what's going on with mmtcg in qemu. There's apparently a race condition
somewhere, like a use-after-free or something.
It started as an incarnation of
https://gitlab.com/qemu-project/qemu/-/issues/1921 -- the same asser
On Fri, 30 May 2025 02:59:40 +
"Zhijian Li (Fujitsu)" wrote:
> On 29/05/2025 21:48, Jonathan Cameron via wrote:
> > This has been wrong from day 1. For now we only have
> > two entries (component and device registers).
>
> Wow, I finally understood this.
>
>
> >
> > The wrong size coul
On Sun, 11 May 2025 09:40:08 -0400
"Michael S. Tsirkin" wrote:
> On Fri, Mar 07, 2025 at 03:53:28PM +0530, Ani Sinha wrote:
> > commit 0788a56bd1ae3 ("i386: Make unversioned CPU models be aliases")
> > introduced 'default_cpu_version' for PCMachineClass. This created three
> > categories of CPU m
The function bdrv_new() calls bdrv_drained_begin(), which must be
called with the graph unlocked.
Marking bdrv_new() as GRAPH_UNLOCKED requires making the locked
section in bdrv_open_inherit() shorter.
Signed-off-by: Fiona Ebner
---
I'm not sure if the TODO comment is only intended for the
lowe
We have been inconsistent about whether ROMS stored in git have
execute permission set, and by default meson will preserve source
file permissions when installing files. This has caused periodic
problems in RPM packaging as executable binary files get analysed
by various tools/linters, which can tr
Suggested-by: Kevin Wolf
Signed-off-by: Fiona Ebner
---
tests/qemu-iotests/tests/graph-changes-while-io | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/qemu-iotests/tests/graph-changes-while-io
b/tests/qemu-iotests/tests/graph-changes-while-io
index 194fda500e..35489e3b5e 100755
--- a
From: Philippe Mathieu-Daudé
"target/arm/cpu-features.h" dereferences the ARMISARegisters
structure, which is defined in "cpu.h". Include the latter to
avoid when refactoring unrelated headers:
In file included from target/arm/internals.h:33:
target/arm/cpu-features.h:45:54: error: unknown t
The function bdrv_replace_child_bs() calls bdrv_drained_begin() which
must be called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/block/block-global-state.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/block/block-global-state.h
b/include/bl
The function stream_prepare() calls bdrv_drain_all_begin(), which
must be called with the graph unlocked.
Also mark the JobDriver's prepare() callback as GRAPH_UNLOCKED_PTR,
because that is the callback via which stream_prepare() is reached.
Signed-off-by: Fiona Ebner
---
block/stream.c | 2
This is in preparation to mark bdrv_drained_begin() as GRAPH_UNLOCKED.
More granular draining is not trivially possible, because
bdrv_inactivate_recurse() can recursively call itself.
Signed-off-by: Fiona Ebner
Reviewed-by: Kevin Wolf
---
block.c | 25 ++---
1 file changed,
This is in preparation to mark bdrv_drained_begin() as GRAPH_UNLOCKED.
More granular draining is not trivially possible, because
bdrv_reopen_queue_child() can recursively call itself.
Signed-off-by: Fiona Ebner
Reviewed-by: Kevin Wolf
---
block.c | 19 +++
1 file changed, 11 in
The function bdrv_inactivate_all() calls bdrv_drain_all_begin(), which
must be called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/block/block-global-state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/block/block-global-state.h
b/include/block
On Fri, May 23, 2025 at 02:24:38PM -0400, John Snow wrote:
> v3: rebased on top of python-qapi-linting (v4) pull request;
> removed commits that are no longer needed.
> Markus: I forget where we left off... shall we refresh?
>
> v2: fix multi-return-sections bug :(
LGTM
My bits:
Acked-b
On Mon, May 26, 2025 at 10:20:55AM -0700, Matheus Tavares Bernardino wrote:
> The test fails with --enable-asan as the error struct is never freed.
> In the case where the test expects a success but it fails, let's also
> report the error for debugging (it will be freed internally).
>
> Fixes 316e
Copying block maintainers, since while this is in QOM source files, this
method is defacto block layer code.
On Fri, May 23, 2025 at 09:02:11AM +0200, Fiona Ebner wrote:
> Currently, changing the 'drive' property of e.g. a scsi-hd object will
> result in an assertion failure if the aio context of
This is in preparation to mark bdrv_set_backing_hd() as
GRAPH_UNLOCKED.
Switch to using the bdrv_set_backing_hd_drained() variant, so that the
drained and locked section can also cover the calls to
bdrv_skip_filters() and bdrv_cow_bs().
Signed-off-by: Fiona Ebner
---
block/mirror.c | 12 +++
This is a small step in preparation to mark bdrv_drained_begin() as
GRAPH_UNLOCKED. More concretely, it allows marking the
change_aio_ctx() callback GRAPH_RDLOCK_PTR, which is the next step.
Signed-off-by: Fiona Ebner
Reviewed-by: Kevin Wolf
---
block.c | 8
1 file changed, 4 insertion
All of bdrv_drain_all_begin(), bdrv_drain_all() and
bdrv_drained_begin() poll and are not allowed to be called with the
block graph lock held. Mark the function as such.
Suggested-by: Kevin Wolf
Signed-off-by: Fiona Ebner
---
include/block/block-global-state.h | 4 ++--
include/block/block-io.h
Both commit ab61335025 ("block: drain from main loop thread in
bdrv_co_yield_to_drain()") and commit d05ab380db ("block: Mark drain
related functions GRAPH_RDLOCK") introduced a GLOBAL_STATE_CODE()
macro in bdrv_do_drained_end(). The assertion of being in the main
thread cannot change here, so keep
The function blk_drain() calls bdrv_drained_begin(), which must be
called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/system/block-backend-global-state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/system/block-backend-global-state.h
b/include
The function bdrv_reopen_queue() can call bdrv_drain_all_begin(),
which must be called with the graph unlocked.
The function bdrv_reopen_multiple() calls bdrv_reopen_prepare() which
must be called with the graph unlocked.
To mark bdrv_reopen_queue() as GRAPH_UNLOCKED, it is necessary to make
the
This is in preparation to mark bdrv_set_backing_hd() as
GRAPH_UNLOCKED.
Signed-off-by: Fiona Ebner
---
block.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 1da10d55f0..ca3b67b233 100644
--- a/block.c
+++ b/block.c
@@ -3632,7 +3632,8 @@ int bdr
The functions blk_log_writes_close(), blkverify_close(),
quorum_close(), vmdk_close() via vmdk_free_extents(), and other
bdrv_close() implementations call bdrv_graph_wrlock_drained(), which
must be called with the graph unlocked. They are reached via the
BlockDriver's bdrv_close() callback and the
From: Andrey Drobyshev
This case is catching potential deadlock which takes place when job-dismiss
is issued when I/O requests are processed in a separate iothread.
See https://mail.gnu.org/archive/html/qemu-devel/2025-04/msg04421.html
Signed-off-by: Andrey Drobyshev
[FE: re-use top image and
This is part of resolving the deadlock mentioned in commit "block:
move draining out of bdrv_change_aio_context() and mark GRAPH_RDLOCK".
bdrv_root_unref_child() is called by:
1. blk_remove_bs(), where a drained section is introduced.
2. bdrv_unref_child(), which runs under the graph lock, so the
This is part of resolving the deadlock mentioned in commit "block:
move draining out of bdrv_change_aio_context() and mark GRAPH_RDLOCK".
The function bdrv_root_attach_child() runs under the graph lock, so it
is not allowed to drain. It is called by:
1. blk_insert_bs(), where a drained section is
The function commit_abort() calls bdrv_drained_begin(), which must be
called with the graph unlocked.
Also mark the JobDriver's abort() callback as GRAPH_UNLOCKED_PTR,
because that is the callback via which commit_abort() is reached.
Signed-off-by: Fiona Ebner
---
block/commit.c | 2 +-
inc
The function bdrv_set_backing_hd() calls bdrv_drain_all_begin(), which
must be called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/block/block-global-state.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/block/block-global-state.h
b/include/
The function bdrv_drop_intermediate() calls bdrv_drained_begin(),
which must be called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/block/block-global-state.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/block/block-global-state.h
b/inclu
This is in preparation to mark bdrv_drained_begin() as GRAPH_UNLOCKED.
Note that even if bdrv_drained_begin() were already marked as
GRAPH_UNLOCKED, TSA would not complain about the instance in
bdrv_change_aio_context() before this change, because it is preceded
by a bdrv_graph_rdunlock_main_loop(
The function blk_remove_bs() calls bdrv_graph_wrlock_drained() and can
also call bdrv_drained_begin(), both of which which must be called with
the graph unlocked.
Marking blk_remove_bs() as GRAPH_UNLOCKED requires temporarily
unlocking in hmp_drive_del().
Signed-off-by: Fiona Ebner
---
block/mo
> On 30 May 2025, at 8:37 PM, Igor Mammedov wrote:
>
> On Sun, 11 May 2025 09:40:08 -0400
> "Michael S. Tsirkin" wrote:
>
>> On Fri, Mar 07, 2025 at 03:53:28PM +0530, Ani Sinha wrote:
>>> commit 0788a56bd1ae3 ("i386: Make unversioned CPU models be aliases")
>>> introduced 'default_cpu_versio
The function blk_io_limits_disable() calls bdrv_drained_begin(), which
must be called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/system/block-backend-global-state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/system/block-backend-global-state.
By using the appropriate variants bdrv_set_backing_hd_drained() and
bdrv_try_change_aio_context_locked(), there only needs to be a single
drained and write-locked section in external_snapshot_abort().
Signed-off-by: Fiona Ebner
---
The assumption in the added code comment about the reference is
This is in preparation to mark bdrv_drained_begin() as GRAPH_UNLOCKED.
Signed-off-by: Fiona Ebner
---
blockdev.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index bd5ca77619..506755bef1 100644
--- a/blockdev.c
+++ b/blockdev.c
This is a small step in preparation to mark bdrv_drained_begin() as
GRAPH_UNLOCKED. More concretely, it is in preparation to move the
drain out of bdrv_change_aio_context() and marking that function as
GRAPH_RDLOCK.
Signed-off-by: Fiona Ebner
Reviewed-by: Kevin Wolf
---
include/block/block-glob
This is part of resolving the deadlock mentioned in commit "block:
move draining out of bdrv_change_aio_context() and mark GRAPH_RDLOCK".
The quorum_add_child() callback runs under the graph lock, so it is
not allowed to drain. It is only called as the .bdrv_add_child()
callback, which is only cal
This is part of resolving the deadlock mentioned in commit "block:
move draining out of bdrv_change_aio_context() and mark GRAPH_RDLOCK".
The function bdrv_attach_child() runs under the graph lock, so it is
not allowed to drain. It is called by:
1. replication_start()
2. quorum_add_child()
3. bdrv
This is part of resolving the deadlock mentioned in commit "block:
move draining out of bdrv_change_aio_context() and mark GRAPH_RDLOCK".
The function bdrv_set_backing_hd_drained() holds the graph lock, so it
is not allowed to drain. It is called by:
1. bdrv_set_backing_hd(), where a drained secti
The function block_job_remove_all_bdrv() calls
bdrv_graph_wrlock_drained(), which must be called with the graph
unlocked.
Signed-off-by: Fiona Ebner
---
include/block/blockjob.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/block/blockjob.h b/include/block/blockjob.
The function bdrv_inactivate() calls bdrv_drain_all_begin(), which
needs to be called with the graph unlocked, so either
bdrv_inactivate() should be marked as GRAPH_UNLOCKED or the drain
needs to be moved to the callers. The caller in
qmp_blockdev_set_active() requires that the locked section cover
Many write-locked sections are also drained sections. A new
bdrv_graph_wrunlock_drained() wrapper around bdrv_graph_wrunlock() is
introduced, which will begin a drained section first. A global
variable is used so bdrv_graph_wrunlock() knows if it also needs
to end such a drained section. Both the a
The function bdrv_open_child_common() calls
bdrv_graph_wrlock_drained(), which must be called with the graph
unlocked. Mark it and its two callers bdrv_open_file_child() and
bdrv_open_child() as GRAPH_UNLOCKED. This requires temporarily
unlocking in vmdk_parse_extents() and making the locked sectio
The function bdrv_all_delete_snapshot() calls bdrv_drain_all_begin(),
which must be called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/block/snapshot.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/block/snapshot.h b/include/block/snapshot.
This is a small step in preparation to mark bdrv_drained_begin() as
GRAPH_UNLOCKED. More concretely, it is in preparation to move the
drain out of bdrv_change_aio_context() and marking that function as
GRAPH_RDLOCK.
Signed-off-by: Fiona Ebner
Reviewed-by: Kevin Wolf
---
block.c
All accesses of bs->quiesce_counter are in the main thread, either
after a GLOBAL_STATE_CODE() macro or in a function with GRAPH_WRLOCK
annotation.
This is essentially a revert of 414c2ec358 ("block: access
quiesce_counter with atomic ops"). At that time, neither the
GLOBAL_STATE_CODE() macro nor
This is in preparation to mark bdrv_set_backing_hd() as
GRAPH_UNLOCKED.
Switch to using the bdrv_set_backing_hd_drained() variant. For the
first pair of calls to avoid draining and locking twice in a row
within the individual calls. For the third call, so that the drained
and locked section can al
AioContext locking was removed in commit b49f4755c7 ("block: remove
AioContext locking").
Signed-off-by: Fiona Ebner
Reviewed-by: Kevin Wolf
---
block.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/block.c b/block.c
index f222e1a50a..a5399888ba 100644
--- a/block.c
+++ b/block.c
@@
The function bdrv_close_all() calls bdrv_drain_all(), which must be
called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/block/block-global-state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/block/block-global-state.h
b/include/block/block-glob
This is part of resolving the deadlock mentioned in commit "block:
move draining out of bdrv_change_aio_context() and mark GRAPH_RDLOCK".
Convert the function to a _locked() version that has to be called with
the graph lock held and add a convenience wrapper that has to be
called with the graph un
The quorum_del_child() callback runs under the graph lock, so it is
not allowed to drain. It is only called as the .bdrv_del_child()
callback, which is only called in the bdrv_del_child() function, which
also runs under the graph lock.
The bdrv_del_child() function is called by qmp_x_blockdev_chan
The function bdrv_insert_node() calls bdrv_drained_begin() which must
be called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/block/block-global-state.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/block/block-global-state.h
b/include/block/
This is in preparation to mark bdrv_drained_begin() as GRAPH_UNLOCKED.
Signed-off-by: Fiona Ebner
---
blockdev.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/blockdev.c b/blockdev.c
index 506755bef1..2e7fda6780 100644
--- a/blockdev.c
+++ b/blockdev.c
@@
This is part of resolving the deadlock mentioned in commit "block:
move draining out of bdrv_change_aio_context() and mark GRAPH_RDLOCK".
The function bdrv_attach_child_common_abort() is used only as the
abort callback in bdrv_attach_child_common_drv transactions, so the
tran_finalize() calls of s
Previous discussions:
v3: [0]
v2: [1]
v1: [2]
Changes in v4:
* Document requirement to drain all block nodes for affected
functions.
* Also cover the generated bdrv_co_unref_child().
* Remove now superfluous drain_bs variable in bdrv_set_backing_hd().
* Mark bdrv_graph_wrlock_drained() wrapper a
The function blk_drain_all() calls bdrv_drain_all_begin(), which must
be called with the graph unlocked.
Signed-off-by: Fiona Ebner
---
include/system/block-backend-global-state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/system/block-backend-global-state.h
b/i
This is in preparation to mark bdrv_drained_begin() as GRAPH_UNLOCKED.
More granular draining is not trivially possible, because
bdrv_snapshot_delete() can recursively call itself.
The return value of bdrv_all_delete_snapshot() changes from -1 to
-errno propagated from failed sub-calls. This is f
Nearly all callers (outside of the tests) are already using the
_drained() variant of the function. It doesn't seem worth keeping.
Simply adapt the remaining callers of bdrv_set_backing_hd() and rename
bdrv_set_backing_hd_drained() to bdrv_set_backing_hd().
Signed-off-by: Fiona Ebner
---
block.c
On Fri, 30 May 2025 14:05:16 +0200
Igor Mammedov wrote:
> On Fri, 30 May 2025 11:02:27 +0100
> Jonathan Cameron wrote:
>
> > On Tue, 27 May 2025 09:40:07 +0200
> > Eric Auger wrote:
> >
> > > acpi_dsdt_add_pci_osc() name is confusing as it gives the impression
> > > it appends the _OSC meth
On 30.05.25 13:18, Michael S. Tsirkin wrote:
On Wed, May 14, 2025 at 11:26:05AM +0200, David Hildenbrand wrote:
On 14.05.25 11:12, Igor Mammedov wrote:
On Tue, 13 May 2025 15:12:11 +0200
David Hildenbrand wrote:
On 13.05.25 14:13, Igor Mammedov wrote:
On Mon, 3 Mar 2025 13:02:17 -0500
yuan
On Fri, 30 May 2025 08:01:28 -0400
"Michael S. Tsirkin" wrote:
> On Wed, May 28, 2025 at 05:42:12PM +0200, Igor Mammedov wrote:
> > On Tue, 20 May 2025 08:41:31 +0200
> > Mauro Carvalho Chehab wrote:
> >
> > > Create a new property (x-has-hest-addr) and use it to detect if
> > > the GHES tabl
On Tue, 4 Mar 2025 14:30:55 +0100
Mauro Carvalho Chehab wrote:
> Hi Igor,
>
> This patch series comes after:
>
> https://lore.kernel.org/qemu-devel/cover.1740903110.git.mchehab+hua...@kernel.org/
>
> I'm basically trying to add support for error injection for x86,
> without success so far.
On 5/30/25 7:41 AM, Michael S. Tsirkin wrote:
On Fri, May 02, 2025 at 02:15:45AM +, Alejandro Jimenez wrote:
This series adds support for guests using the AMD vIOMMU to enable DMA
remapping for VFIO devices. In addition to the currently supported
passthrough (PT) mode, guest kernels are n
On Tue, 4 Mar 2025 14:30:56 +0100
Mauro Carvalho Chehab wrote:
> The only reason why we're passing ags to acpi HEST table build
> is to check if migration will be used or not.
>
> Well, we only need migration for arm, as other architectures
> will only use the new code. So, move this out of acp
Modify memory_region_set_ram_discard_manager() to return -EBUSY if a
RamDiscardManager is already set in the MemoryRegion. The caller must
handle this failure, such as having virtio-mem undo its actions and fail
the realize() process. Opportunistically move the call earlier to avoid
complex error h
On Tue, 20 May 2025 14:39:47 +0100
Jonathan Cameron via wrote:
> On Thu, 8 May 2025 00:00:56 +
> anisa.su...@gmail.com wrote:
>
> > From: Anisa Su
> >
> > This patchset adds support for 6 FM API DCD Management commands
> > (0x5600-0x5605)
> > according to the CXL r3.2 Spec. It is based o
Hi Guenter et al.,
I was trying to create a functional test for the "highbank" and "midway" arm
machines of QEMU, and only succeeded after lots of trial and error to boot
something on the "highbank" machine. Peter mentioned on IRC that he also
does not test these machines by default, so we
On Fri, May 30, 2025, 02:18 Thomas Huth wrote:
> On 29/05/2025 16.45, Stefan Hajnoczi wrote:
> > The OrangePi, Cubieboard, Banana Pi, and replay tests use a sunxi
> > armhf Linux package URL that is failing due to an expired TLS
> > certificate:
> >
> > 2025-05-29 13:37:56,005 - qemu-test - INFO
From: Souleymane Conte
buglink: https://gitlab.com/qemu-project/qemu/-/issues/527
Signed-off-by: Souleymane Conte
Reviewed-by: Peter Maydell
Reviewed-by: Eric Blake
Message-id: 20250522092622.40869-1-conte.souleym...@gmail.com
[PMM: switched a few more bits of formatting to monospaced;
updat
On Thu, 8 May 2025 00:00:58 +
anisa.su...@gmail.com wrote:
> From: Anisa Su
>
> FM DCD Management command 0x5600 implemented per CXL 3.2 Spec Section
> 7.6.7.6.1.
>
> Signed-off-by: Anisa Su
Looks like a missing include - though probably due to some indirect include
going away.
> ---
>
On Thu, May 29, 2025 at 05:23:14PM -0300, Daniel Henrique Barboza wrote:
> 'ssstrict' is a RVA23 profile-defined extension defined as follows:
>
> "No non-conforming extensions are present. Attempts to execute
> unimplemented opcodes or access unimplemented CSRs in the standard or
> reserved encod
These properties were deprecated in QEMU 8.2, commit 8043effd9b.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 17 -
target/riscv/cpu.h | 1 -
target/riscv/tcg/tcg-cpu.c | 31 +--
3 files changed, 1 insertion(+), 48 d
On Tue, 20 May 2025 17:33:46 +
Anisa Su wrote:
> On Tue, May 20, 2025 at 08:37:35AM -0700, Fan Ni wrote:
> > On Thu, May 08, 2025 at 12:00:57AM +, anisa.su...@gmail.com wrote:
> > > From: Anisa Su
> > >
> > > In preparation for the next patch, move opcodes enum to new cxl_opcodes.h
>
Hi Ilya,
On 5/27/25 10:51 PM, Ilya Maximets wrote:
On 5/12/25 6:06 PM, Daniel Borkmann wrote:
Extend 'inhibit=on' setting with the option to specify a pinned XSK map
path along with a starting index (default 0) to push the created XSK
sockets into. Example usage:
# ./build/qemu-system-x86_6
On Tue, 27 May 2025 09:40:15 +0200
Eric Auger wrote:
> We plan to reuse build_append_notification_callback() on ARM
> so let's move it to pcihp.c.
>
> No functional change intended.
>
> Signed-off-by: Eric Auger
> Reviewed-by: Gustavo Romero
FWIW given it's just a move.
Reviewed-by: Jonathan
From: Thomas Huth
The 2023 edition of the QEMU advent calendar featured an image
that we can use to test whether the lm3s6965evb machine is basically
still working.
And for the lm3s811evb there is a small test kernel on github
which can be used to check its UART.
Signed-off-by: Thomas Huth
Mes
On Fri, May 30, 2025 at 14:08:25 +0200, Peter Krempa wrote:
> The rest are CPU properties
>
> DEFINE_PROP_BOOL("cpuid-0xb", X86CPU, enable_cpuid_0xb, true),
> DEFINE_PROP_BOOL("fill-mtrr-mask", X86CPU, fill_mtrr_mask, true),
> DEFINE_PROP_BOOL("full-cpuid-auto-level", X86CPU, full_cpuid_auto_le
On Thu, 29 May 2025 14:48:28 +0100
Jonathan Cameron wrote:
> This has been wrong from day 1. For now we only have
> two entries (component and device registers).
>
> The wrong size could lead to arbitrary data off the stack being presented
> in PCIe config space.
As noted in reply to Zhijian,
Hi!
Thank you for your attention!
On 30.05.2025 09:39, Weifeng Liu wrote:
On Thu, 2025-05-29 at 10:23 +0300, Michael Tokarev wrote:
Is there anything here which should be picked up for qemu-stable
(current active branches: 7.2 and 10.0)?
I think the first five patches are good candidates fo
From: Philippe Mathieu-Daudé
CPReadFn type definitions use the CPUARMState type, itself
declared in "cpu.h". Include this file in order to avoid when
refactoring headers:
../target/arm/cpregs.h:241:27: error: unknown type name 'CPUARMState'
typedef uint64_t CPReadFn(CPUARMState *env, const A
From: Philippe Mathieu-Daudé
ARMCPU typedef is declared in "cpu-qom.h". Include it in
order to avoid when refactoring unrelated headers:
target/arm/hvf_arm.h:23:41: error: unknown type name 'ARMCPU'
23 | void hvf_arm_set_cpu_features_from_host(ARMCPU *cpu);
|
From: Philippe Mathieu-Daudé
In order to allow non-target specific code to include
"hvf_arm.h", define the stubs in hvf-stub.c.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Pierrick Bouvier
Reviewed-by: Richard Henderson
Message-id: 20250513173928.77376-3-phi...@linaro.org
Signed-off-by
The nand.c device (TYPE_NAND) is an emulation of a NAND flash memory
chip which was used by the old OMAP boards. No current QEMU board
uses it, and although techically "-device nand,chip-id=0x6b" doesn't
error out, it's not possible to usefully use it from the command
line because the only interfa
From: Nabih Estefan
For upstreaming we migrated this test to 7xx (since that was already
upstream) move it back to 8xx where it can check the 4 GMACs since that
is the board this test was originally created for.
Signed-off-by: Nabih Estefan
Message-id: 20250508220718.735415-3-nabiheste...@googl
From: Philippe Mathieu-Daudé
ARMCPU typedef is declared in "cpu-qom.h". Include it in
order to avoid when refactoring unrelated headers:
target/arm/kvm_arm.h:54:29: error: unknown type name 'ARMCPU'
54 | bool write_list_to_kvmstate(ARMCPU *cpu, int level);
|
From: Guenter Roeck
Without psci_conduit, the Linux kernel crashes almost immediately.
psci: probing for conduit method from DT.
Internal error: Oops - Undefined instruction: 0200 [#1] PREEMPT
SMP
Fixes: ae0c4d1a1290 ("hw/arm: Add NPCM8XX SoC")
Cc: qemu-sta...@nongnu.org
Cc
From: Philippe Mathieu-Daudé
arm-qmp-cmds.c uses ARM_MAX_VQ, which is defined in "cpu.h".
Include the latter to avoid when refactoring unrelated headers:
target/arm/arm-qmp-cmds.c:83:19: error: use of undeclared identifier
'ARM_MAX_VQ'
83 | QEMU_BUILD_BUG_ON(ARM_MAX_VQ > 16);
|
From: Philippe Mathieu-Daudé
Since commit 538b764d341 ("target/arm: Move minor arithmetic
helpers out of helper.c") we only use the zlib helpers under
TCG.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Pierrick Bouvier
Message-id: 20250513173928.77376-4-phi...@linaro.org
Signed-off-by: Pe
From: Hao Wu
The GMAC was originally created for the 8xx machine. During upstreaming
both the GMAC and the 8XX we removed it so they would not depend on each
other for the process, that connection should be added back in.
Signed-off-by: Hao Wu
Signed-off-by: Nabih Estefan
Message-id: 202505082
From: Philippe Mathieu-Daudé
default_reset_secondary() uses address_space_stl_notdirty(),
itself declared in "system/memory.h". Include this header in
order to avoid when refactoring headers:
../hw/arm/boot.c:281:5: error: implicit declaration of function
'address_space_stl_notdirty' is inval
re available in the Git repository at:
https://git.linaro.org/people/pmaydell/qemu-arm.git
tags/pull-target-arm-20250530-2
for you to fetch changes up to e86c1f967a323165d13bcadfad4b92d0d34cdb08:
hw/block: Drop unused nand.c (2025-05-29
From: Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Pierrick Bouvier
Reviewed-by: Richard Henderson
Message-id: 20250513173928.77376-2-phi...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
>-Original Message-
>From: Steven Sistare
>Subject: Re: [PATCH V3 29/42] backends/iommufd: change process ioctl
>
>On 5/25/2025 10:31 PM, Duan, Zhenzhong wrote:
>>> -Original Message-
>>> From: Steven Sistare
>>> Subject: Re: [PATCH V3 29/42] backends/iommufd: change process ioc
On Wed, May 28, 2025 at 06:53:34PM +0800, Li Chen wrote:
> From: Li Chen
>
> (REPOST because the previous post failed to send to
> qemu-devel/qemu-riscv/qemu-arm,
> see
> https://lore.kernel.org/qemu-devel/1971648603b.dce1f5d22901195.6702025346547333607@linux.beauty/T/#u)
>
> This series intr
1 - 100 of 243 matches
Mail list logo
