From: Jeuk Kim
This patch fixes invalid ufs register fields.
This fixes an issue reported by Bin Meng that
caused ufs to fail over riscv.
Fixes: bc4e68d362ec ("hw/ufs: Initial commit for emulated
Universal-Flash-Storage")
Signed-off-by: Jeuk Kim
Reported-by: Bin Meng
Reviewed-by: Bin Meng
On 09/10/2023 12.02, Philippe Mathieu-Daudé wrote:
Rename the (unused) 'allow' argument, following the pattern
used by the other tests in this file. This fixes:
tests/qtest/virtio-scsi-test.c:159:61: error: declaration shadows a variable
in the global scope [-Werror,-Wshadow]
static void
On 09/10/2023 12.02, Philippe Mathieu-Daudé wrote:
Rename the variable to fix:
softmmu/qtest.c:869:13: error: declaration shadows a variable in the global
scope [-Werror,-Wshadow]
Object *qtest;
^
softmmu/qtest.c:53:15: note: previous declaration is here
static
Peter Xu writes:
> On Wed, Oct 11, 2023 at 06:28:26AM +0200, Markus Armbruster wrote:
[...]
>> >> If the migration object is accessible with qom-set, then that's another
>> >> way to assign null values.
>> >
>> > I see what you meant. IMHO we just don't need to worry on breaking that as
>> >
Peter Xu writes:
> On Wed, Oct 11, 2023 at 04:21:02PM +0200, Markus Armbruster wrote:
>> > I'll have another look at the schema change, and how the types are used.
>>
>> Schema changes:
>>
>> 1. Change MigrationParameters members @tls-creds, @tls-hostname,
>>@tls-authz from 'str' to
On 2023/10/13 14:00, Jason Wang wrote:
On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki wrote:
On 2023/10/13 10:38, Jason Wang wrote:
On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki wrote:
It was necessary since an Linux older than 2.6.35 may implement the
virtio-net header but may not allow
On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki wrote:
>
> On 2023/10/13 10:38, Jason Wang wrote:
> > On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki
> > wrote:
> >>
> >> It was necessary since an Linux older than 2.6.35 may implement the
> >> virtio-net header but may not allow to change its
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
"target/foo/cpu-qom.h" can not use any target specific definitions.
Currently "target/mips/cpu-qom.h" defines TYPE_MIPS_CPU depending
on the mips(32)/mips64 build type. This doesn't scale in a
heterogeneous context where we need to access both
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
"target/foo/cpu-qom.h" can not use any target specific definitions.
Currently "target/i386/cpu-qom.h" defines TYPE_X86_CPU depending
on the i386/x86_64 build type. This doesn't scale in a heterogeneous
context where we need to access both types
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
Since the OBJECT_DECLARE_CPU_TYPE() macro uses the abstract ArchCPU
type, when declaring multiple CPUs of the same ArchCPU type we get
an error related to the indirect G_DEFINE_AUTOPTR_CLEANUP_FUNC()
use within OBJECT_DECLARE_TYPE():
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
When multiple QOM types are registered in the same file,
it is simpler to use the the DEFINE_TYPES() macro. In
particular because type array declared with such macro
are easier to review.
In few commits we are going to add more types, so replace
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
When multiple QOM types are registered in the same file,
it is simpler to use the the DEFINE_TYPES() macro. In
particular because type array declared with such macro
are easier to review.
In few commits we are going to add more types, so replace
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
When multiple QOM types are registered in the same file,
it is simpler to use the the DEFINE_TYPES() macro. In
particular because type array declared with such macro
are easier to review.
In few commits we are going to add more types, so replace
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
When multiple QOM types are registered in the same file,
it is simpler to use the the DEFINE_TYPES() macro. In
particular because type array declared with such macro
are easier to review.
In few commits we are going to add more types, so replace
On 2023/10/13 10:38, Jason Wang wrote:
On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki wrote:
It was necessary since an Linux older than 2.6.35 may implement the
virtio-net header but may not allow to change its length. Remove it
since such an old Linux is no longer supported.
Where can I
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
TYPE_RISCV_CPU_BASE depends on the TARGET_RISCV32/TARGET_RISCV64
definitions which are target specific. Such target specific
definition taints "cpu-qom.h".
Since "cpu-qom.h" must be target agnostic, remove its target
specific definition uses by
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
TARGET_DEFAULT_CPU_TYPE depends on the TARGET_X86_64 definition
which is target specific. Such target specific definition taint
"cpu-qom.h".
Since "cpu-qom.h" must be target agnostic, remove this target
specific definition uses by inlining
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
"target/foo/cpu.h" contains the target specific declarations.
A heterogeneous setup need to access target agnostic declarations
(at least the QOM ones, to instantiate the objects).
Our convention is to add such target agnostic QOM declarations
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
Hegerogeneous code needs access to the FOO_CPU_TYPE_NAME()
macro to resolve target CPU types. Move the declaration
(along with the required FOO_CPU_TYPE_SUFFIX) to "cpu-qom.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/alpha/cpu-qom.h
Hi Salil Mehta via:
Virtual CPU hotplug support is being added across various architectures[1][3].
This series adds various code bits common across all architectures:
1. vCPU creation and Parking code refactor [Patch 1]
2. Update ACPI GED framework to support vCPU Hotplug [Patch 4,6,7]
3. ACPI
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
CPU_RESOLVING_TYPE is a per-target definition, and is
irrelevant for other targets. Move it to "cpu.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/riscv/cpu-qom.h | 1 -
target/riscv/cpu.h | 2 ++
2 files changed, 2 insertions(+),
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
CPU_RESOLVING_TYPE is a per-target definition, and is
irrelevant for other targets. Move it to "cpu.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/ppc/cpu-qom.h | 3 +--
target/ppc/cpu.h | 2 ++
2 files changed, 3 insertions(+), 2
On 10/10/23 02:28, Philippe Mathieu-Daudé wrote:
"target/foo/cpu-qom.h" is supposed to be target agnostic
(include-able by any target). Add such mention in the
header.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
r~
Ping.
On 10/3/23 12:20, Richard Henderson wrote:
More signal cleanups. Mostly tested by temporarily adding an
abort, divide by zero, undefined instruction, null dereference,
within the implementation of a guest syscall to induce an error.
Changes for v5:
* Remap guest abort, which means we
On 10/5/23 09:53, Philippe Mathieu-Daudé wrote:
On 3/10/23 19:43, Richard Henderson wrote:
Signed-off-by: Richard Henderson
---
tcg/arm/tcg-target.c.inc | 203 +++
1 file changed, 97 insertions(+), 106 deletions(-)
@@ -356,14 +354,8 @@ static bool
Hello Pbonzini and QEMU community,
I submitted a patch titled "target/i386/kvm: Refine VMX controls setting for
backward compatibility" on the 25th of September 2023. I noticed that it
hasn't received any replies yet. Here's a link to the patch on lore.kernel.org:
void cxl_component_register_block_init(Object *obj,
CXLComponentState *cxl_cstate,
const char *type)
{
ComponentRegisters *cregs = _cstate->crb;
...
memory_region_init_io(>cache_mem, obj, _mem_ops, cregs,
On 2023/10/12 20:38, Rob Bradford wrote:
On Thu, 2023-10-12 at 17:05 +0800, LIU Zhiwei wrote:
On 2023/10/11 22:45, Rob Bradford wrote:
Using a mask instead of the number of PMU devices supports the
accurate
emulation of platforms that have a discontinuous set of PMU
On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki wrote:
>
> It was necessary since an Linux older than 2.6.35 may implement the
> virtio-net header but may not allow to change its length. Remove it
> since such an old Linux is no longer supported.
Where can I see this agreement?
Thanks
在 2023/10/12 下午5:51, Xiaojuan Yang 写道:
I haven't really been working on LoongArch for some time now,
so let's remove myself from this entry.
Signed-off-by: Xiaojuan Yang
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
Acked-by: Song Gao
Thanks.
Song Gao
diff --git
Am 11. Oktober 2023 20:18:00 UTC schrieb "Michael S. Tsirkin" :
>On Wed, Oct 11, 2023 at 06:57:07PM +, Bernhard Beschow wrote:
>>
>>
>> Am 8. Oktober 2023 17:56:48 UTC schrieb Chuck Zmudzinski :
>> >On 10/7/23 8:38 AM, Bernhard Beschow wrote:
>> >> This series consolidates the
Scale factor needs to be applied when calculating width/height of the
GTK windows.
Cc: Marc-André Lureau
Signed-off-by: Dongwon Kim
---
ui/gtk-egl.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index a1060fd80f..45c7544337
When turning on or off full-screen menu, all detached windows should
be full-screened or un-full-screened altogether.
Cc: Marc-André Lureau
Signed-off-by: Dongwon Kim
---
ui/gtk.c | 44 ++--
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git
On Tue, 2023-10-10 at 23:02 +1030, Joel Stanley wrote:
> On Fri, 6 Oct 2023 at 07:23, Glenn Miles
> wrote:
> > Allow external devices to drive pca9552 input pins by adding
> > input GPIO's to the model. This allows a device to connect
> > its output GPIO's to the pca9552 input GPIO's.
> >
> >
On 2023/10/13 4:10, Daniel Henrique Barboza wrote:
On 10/11/23 04:02, Akihiko Odaki wrote:
MISA limits are common for all instances of a RISC-V CPU class so they
are better put into class.
Signed-off-by: Akihiko Odaki
---
This patch and patches 2 and 3 from this version (v9) got dropped
On 2023/10/13 2:04, Alex Bennée wrote:
We already do a couple of "info registers" for specific tests but this
is a more comprehensive multiarch test. It also has some output
helpful for debugging the gdbstub by showing which XML features are
advertised and what the underlying register numbers
On Mon, Oct 9, 2023 at 6:03 AM Philippe Mathieu-Daudé wrote:
>
> Rename the variable to fix:
>
> tests/qtest/cdrom-test.c:40:50: error: declaration shadows a variable in
> the global scope [-Werror,-Wshadow]
> static int prepare_image(const char *arch, char *isoimage)
>
Fiona Ebner writes:
> This is intended to be a semantic revert of commit 9b09503752
> ("migration: run setup callbacks out of big lock"). There have been so
> many changes since that commit (e.g. a new setup callback
> dirty_bitmap_save_setup() that also needs to be adapted now), it's
> easier
From: Cédric Le Goater
Wires up three I2C controller instances to the powernv9 chip
XSCOM address space.
Each controller instance is wired up to a single I2C bus of
its own. No other I2C devices are connected to the buses
at this time.
Signed-off-by: Cédric Le Goater
[milesg: Split wiring
From: Cédric Le Goater
The more recent IBM power processors have an embedded I2C
controller that is accessible by software via the XSCOM
address space.
Each instance of the I2C controller is capable of controlling
multiple I2C buses (one at a time). Prior to beginning a
transaction on an I2C
Upstreams the PowerNV I2C controller model originally
authored by Cédric Le Goater with minor changes by
myself to split the actual addition of the model from
wiring it up to a power processor model.
This series only attaches the controller to the powernv9
chip model, but is expected to
On Thu, Oct 12, 2023 at 09:20:28PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> We now have a problem in downstream:
>
> We have a vhost-user server, which doesn't support
> VHOST_USER_SET_VRING_ENABLE. As I understand, vhost-user specification allows
> it. So the server behaves as
On Wed, Oct 11, 2023 at 04:21:02PM +0200, Markus Armbruster wrote:
> > I'll have another look at the schema change, and how the types are used.
>
> Schema changes:
>
> 1. Change MigrationParameters members @tls-creds, @tls-hostname,
>@tls-authz from 'str' to 'StrOrNull'
>
> 2. Replace
On 10/11/23 04:02, Akihiko Odaki wrote:
MISA limits are common for all instances of a RISC-V CPU class so they
are better put into class.
Signed-off-by: Akihiko Odaki
---
This patch and patches 2 and 3 from this version (v9) got dropped from the later
versions of the series. Can I assume
On 10/11/23 00:01, Alistair Francis wrote:
On Sat, Oct 7, 2023 at 12:23 AM Daniel Henrique Barboza
wrote:
Hi,
Several design changes were made in this version after the reviews and
feedback in the v1 [1]. The high-level summary is:
- we'll no longer allow users to set profile flags for
On 10/3/23 04:04, Philippe Mathieu-Daudé wrote:
kvm_get_radix_page_info() is only defined for ppc targets (in
target/ppc/kvm.c). The declaration is not useful in other targets,
reduce its scope.
Rename using the 'kvmppc_' prefix following other declarations
from target/ppc/kvm_ppc.h.
On 3/10/23 09:04, Philippe Mathieu-Daudé wrote:
Since v1:
- Addressed Michael review comments,
- Added Daniel R-b tag.
Implement Kevin's suggestion to remove KVM declarations
for user emulation builds, so if KVM prototype are used
we directly get a compile failure.
Philippe Mathieu-Daudé (4):
On 10/10/23 23:51, Alistair Francis wrote:
On Fri, Oct 6, 2023 at 11:23 PM Daniel Henrique Barboza
wrote:
zicntr is the Base Counters and Timers extension described in chapter 12
of the unprivileged spec. It describes support for RDCYCLE, RDTIME and
RDINSTRET.
QEMU already implements it
On Thu, Oct 12, 2023 at 1:52 PM Vladimir Sementsov-Ogievskiy
wrote:
>
> On 12.10.23 01:04, John Snow wrote:
> > On Fri, Oct 6, 2023 at 11:41 AM Vladimir Sementsov-Ogievskiy
> > wrote:
> >>
> >> Hi all!
> >>
> >> Let's get rid of pattern
> >>
> >> result = self.vm.qmp(...)
> >>
Hi all!
We now have a problem in downstream:
We have a vhost-user server, which doesn't support VHOST_USER_SET_VRING_ENABLE.
As I understand, vhost-user specification allows it. So the server behaves as
follows:
1. in GET_FEATURES, it sets VHOST_USER_F_PROTOCOL_FEATURES, to report support
Hi Miguel,
> From: Miguel Luis
> Sent: Thursday, October 12, 2023 6:02 PM
> To: Salil Mehta
> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; Marc Zyngier
> ; jean-phili...@linaro.org; Jonathan Cameron
> ; lpieral...@kernel.org; Peter Maydell
> ; Richard Henderson
> ; imamm...@redhat.com;
>
On 12.10.23 01:04, John Snow wrote:
On Fri, Oct 6, 2023 at 11:41 AM Vladimir Sementsov-Ogievskiy
wrote:
Hi all!
Let's get rid of pattern
result = self.vm.qmp(...)
self.assert_qmp(result, 'return', {})
And switch to just
self.vm.cmd(...)
v7: add r-bs and small
On Tue, 2023-10-10 at 22:10 +0200, Cédric Le Goater wrote:
> On 10/10/23 19:19, Glenn Miles wrote:
> > From: Cédric Le Goater
> >
> > The more recent IBM power processors have an embedded I2C
> > controller that is accessible by software via the XSCOM
> > address space.
> >
> > Each instance of
On Tue, 2023-10-10 at 22:14 +0200, Cédric Le Goater wrote:
> On 10/10/23 19:19, Glenn Miles wrote:
> > From: Cédric Le Goater
> >
> > Wires up three I2C controller instances to the powernv9 chip
> > XSCOM address space.
> >
> > Each controller instance is wired up to a single I2C bus of
> > its
t; are available in the Git repository at:
>
> https://gitlab.com/jeuk20.kim/qemu.git tags/pull-ufs-20231012
>
> for you to fetch changes up to 8466aa53d623377e114895c6563face25370d7da:
>
> hw/ufs: Fix incorre
We already do a couple of "info registers" for specific tests but this
is a more comprehensive multiarch test. It also has some output
helpful for debugging the gdbstub by showing which XML features are
advertised and what the underlying register numbers are.
My initial motivation was to see if
Hi Salil,
> On 26 Sep 2023, at 10:03, Salil Mehta wrote:
>
> [ *REPEAT: Sent patches got held at internal server yesterday* ]
>
> PROLOGUE
>
>
> To assist in review and set the right expectations from this RFC, please first
> read below sections *APPENDED AT THE END* of this cover
From: Yuval Shaia
Guest driver allocates and initialize page tables to be used as a ring
of descriptors for CQ and async events.
The page table that represents the ring, along with the number of pages
in the page table is passed to the device.
Currently our device supports only one page table
This job is failing since weeks. Let's mark it as manual until
it gets fixed.
Message-Id: <82aa015a-ca94-49ce-beec-679cc175b...@redhat.com>
Acked-by: Michael Tokarev
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/container-cross.yml | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Chris Rauer
npcm7xx_timer-test occasionally fails due to the state of the timers
from the previous test iteration. Advancing the clock step after the
reset resolves this issue.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1897
Signed-off-by: Chris Rauer
Message-ID:
From: Klaus Jensen
Associate i2c-echo with TEST_DEVICES and add a dependency on I2C.
Signed-off-by: Klaus Jensen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Message-ID: <20230823-i2c-echo-fixes-v1-2-ccc05a602...@samsung.com>
Signed-off-by: Thomas Huth
---
hw/misc/Kconfig
The following changes since commit a51e5124a655b3dad80b36b18547cb1eca2c5eb2:
Merge tag 'pull-omnibus-111023-1' of https://gitlab.com/stsquad/qemu into
staging (2023-10-11 09:43:10 -0400)
are available in the Git repository at:
https://gitlab.com/thuth/qemu.git tags/pull-request-2023-10-12
From: Klaus Jensen
Add missing copyright and license notice. Also add a short description
of the device.
Signed-off-by: Klaus Jensen
Message-ID: <20230823-i2c-echo-fixes-v1-1-ccc05a602...@samsung.com>
Signed-off-by: Thomas Huth
---
hw/misc/i2c-echo.c | 10 ++
1 file changed, 10
This subsystem is said to be in a bad shape (see e.g. [1], [2]
and [3]), and nobody seems to feel responsible to pick up patches
for this and send them via a pull request. For example there is
a patch for a CVE-worthy bug posted more than half a year ago [4]
which has never been merged. Thus let's
We already list system/qtest.c in the qtest section, so the
corresponding header file should be listed here, too.
Message-ID: <20231012111401.871711-1-th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Thomas Huth
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff
On 12/10/23 18:26, Peng Liang wrote:
On 10/12/2023 18:53, Philippe Mathieu-Daudé wrote:
Hi Martin, Paolo, Markus, Marc-André,
With the following changes:
-- >8 --
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 137276bcb9..291495f798 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -245,6
Add a leading 'z' to improve grepping. When one wants to search for uses
of zicbom they're more likely to do 'grep -i zicbom' than 'grep -i
icbom'.
Suggested-by: Andrew Jones
Signed-off-by: Daniel Henrique Barboza
---
hw/riscv/virt.c | 2 +-
target/riscv/cpu.c
Add a leading 'z' to improve grepping. When one wants to search for uses
of zicboz they're more likely to do 'grep -i zicboz' than 'grep -i
icboz'.
Suggested-by: Andrew Jones
Signed-off-by: Daniel Henrique Barboza
---
hw/riscv/virt.c | 2 +-
target/riscv/cpu.c
Add a leading 'z' to improve grepping. When one wants to search for uses
of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'.
Suggested-by: Andrew Jones
Signed-off-by: Daniel Henrique Barboza
---
hw/riscv/boot.c| 2 +-
target/riscv/cpu.c | 22
Add a leading 'z' to improve grepping. When one wants to search for uses
of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i
ifencei'.
Suggested-by: Andrew Jones
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 22 +++---
Hi,
This series renames the following internal extensions flags:
ext_ifencei, ext_icsr, ext_icbom, ext_icboz
To add a leading 'z':
ext_zifencei, ext_zicsr, ext_zicbom, ext_zicboz
This was proposed by Andrew Jones. The motivation, in his own words:
"I'd prefer we name the booleans with their
From: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Paolo Bonzini
Message-ID: <20230904100306.156197-5-pbonz...@redhat.com>
Reviewed-by: Kevin Wolf
Signed-off-by: Kevin Wolf
---
block/copy-before-write.c | 2 +-
block/copy-on-read.c | 8
block/io.c| 6
This adds GRAPH_RDLOCK annotations to declare that callers of
qcow2_inactivate() need to hold a reader lock for the graph because it
calls bdrv_get_device_or_node_name(), which accesses the parents list of
a node.
qcow2_do_close() is a bit strange because it is called from different
contexts. If
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_primary_child() need to hold a reader lock for the graph
because it accesses the children list of a node.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-12-kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_get_specific_info() need to hold a reader lock for the graph.
This removes an assume_graph_lock() call in vmdk's implementation.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-20-kw...@redhat.com>
Reviewed-by: Stefan
Almost all functions that access the parent link already take the graph
lock now. Add locking to the remaining user in a test case and finally
annotate the struct field itself as protected by the graph lock.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-21-kw...@redhat.com>
Reopen isn't easy with respect to locking because many of its functions
need to iterate the graph, some change it, and then you get some drains
in the middle where you can't hold any locks.
Therefore just documents most of the functions to be unlocked, and take
locks internally before accessing
Almost all functions that access the child links already take the graph
lock now. Add locking to the remaining users and finally annotate the
struct field itself as protected by the graph lock.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-22-kw...@redhat.com>
Reviewed-by: Stefan
AIO callbacks are effectively coroutine_mixed_fn. If AIO requests don't
return immediately, their callback is called from the request coroutine.
This means that in AIO callbacks, we can't call no_coroutine_fns such as
bdrv_graph_wrlock(). Unfortunately test-bdrv-drain does so.
Change the test to
The function reads the parents list, so it needs to hold the graph lock.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-4-kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
block.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_refresh_filename() need to hold a reader lock for the graph
because it accesses the children list of a node.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-11-kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi
bdrv_graph_wrlock() can't run in a coroutine (because it polls) and
requires holding the BQL. We already have GLOBAL_STATE_CODE() to assert
the latter. Assert the former as well and add a no_coroutine_fn marker.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-23-kw...@redhat.com>
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_get_parent_name() need to hold a reader lock for the graph
because it accesses the parents list of a node.
For some places, we know that they will hold the lock, but we don't have
the GRAPH_RDLOCK annotations yet. In this case,
On 10/12/2023 18:53, Philippe Mathieu-Daudé wrote:
> Hi Martin, Paolo, Markus, Marc-André,
>
> With the following changes:
>
> -- >8 --
> diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
> index 137276bcb9..291495f798 100644
> --- a/hw/ppc/prep.c
> +++ b/hw/ppc/prep.c
> @@ -245,6 +245,7 @@ static
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_first_blk() and bdrv_is_root_node() need to hold a reader lock
for the graph. These functions are the only functions in block-backend.c
that access the parent list of a node.
Signed-off-by: Kevin Wolf
Message-ID:
From: Emanuele Giuseppe Esposito
Draining recursively traverses the graph, therefore we need to make sure
that also such accesses to the graph are protected by the graph rdlock.
There are 3 different drain callers to consider:
1. drain in the main loop: no issue at all, rdlock is nop.
2. drain
From: Paolo Bonzini
Include both coroutine and non-coroutine versions, the latter being
co_wrapper_mixed_bdrv_rdlock of the former.
Reviewed-by: Eric Blake
Signed-off-by: Paolo Bonzini
Message-ID: <20230904100306.156197-3-pbonz...@redhat.com>
Reviewed-by: Kevin Wolf
Signed-off-by: Kevin Wolf
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_snapshot_fallback() need to hold a reader lock for the graph
because it accesses the children list of a node.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-8-kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_parent_cb_resize() need to hold a reader lock for the graph.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-7-kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
block/io.c | 12
From: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Paolo Bonzini
Message-ID: <20230904100306.156197-4-pbonz...@redhat.com>
Reviewed-by: Kevin Wolf
Signed-off-by: Kevin Wolf
---
include/block/block-io.h | 12 +
block/io.c | 53
It still has an assume_graph_lock() call, but all of its callers are now
properly annotated to hold the graph lock. Update the function to be
GRAPH_RDLOCK as well and remove the assume_graph_lock().
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-17-kw...@redhat.com>
Reviewed-by:
Add a new wrapper type for GRAPH_RDLOCK functions that should be called
from coroutine context.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-3-kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
include/block/block-common.h | 7 +--
This adds GRAPH_RDLOCK annotations to declare that callers of
qcow2_signal_corruption() need to hold a reader lock for the graph
because it calls bdrv_get_node_name(), which accesses the parents list
of a node.
For some places, we know that they will hold the lock, but we don't have
the
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_op_is_blocked() need to hold a reader lock for the graph
because it calls bdrv_get_device_or_node_name(), which accesses the
parents list of a node.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-18-kw...@redhat.com>
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_get_xdbg_block_graph() need to hold a reader lock for the graph
because it accesses the children list of a node.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-10-kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_amend_options() need to hold a reader lock for the graph. This
removes an assume_graph_lock() call in crypto's implementation.
Signed-off-by: Kevin Wolf
Message-ID: <20230929145157.45443-14-kw...@redhat.com>
Reviewed-by: Stefan
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_apply_auto_read_only() need to hold a reader lock for the graph
because it calls bdrv_can_set_read_only(), which indirectly accesses the
parents list of a node.
Signed-off-by: Kevin Wolf
Message-ID:
The following changes since commit a51e5124a655b3dad80b36b18547cb1eca2c5eb2:
Merge tag 'pull-omnibus-111023-1' of https://gitlab.com/stsquad/qemu into
staging (2023-10-11 09:43:10 -0400)
are available in the Git repository at:
https://repo.or.cz/qemu/kevin.git tags/for-upstream
for you to
From: Paolo Bonzini
bdrv_block_status exists as a wrapper for bdrv_block_status_above, but
the name of the (hypothetical) coroutine version, bdrv_co_block_status,
is squatted by a random static function. Rename it to
bdrv_co_do_block_status.
Signed-off-by: Paolo Bonzini
Message-ID:
Hello,
For modularity reasons the P10 processor chip is split into multiple
chiplets individually controlled and managed by the pervasive logic.
The boundaries of these chiplets are defined based on physical design
parameters like clock grids, the nature of the functional units as well
as their
1 - 100 of 315 matches
Mail list logo
