Hi
On Tue, Aug 1, 2023 at 1:40 PM wrote:
>
> From: Marc-André Lureau
>
> It's weird to shift x & y without obvious reason. Let's make this more
> explicit and future-proof.
>
> Signed-off-by: Marc-André Lureau
ping
> ---
> hw/i386/vmmouse.c | 13 +++--
> 1 file changed, 11 insertions
On Wed, Sep 06, 2023 at 06:16:32AM -0300, Daniel Henrique Barboza wrote:
> All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU
> calls riscv_init_max_cpu_extensions(). Both can be moved to a common
> instance_post_init() callback, implemented in riscv_cpu_post_init(),
> called by a
On Wed, Sep 06, 2023 at 06:16:36AM -0300, Daniel Henrique Barboza wrote:
> This function is used for both accelerators. Make it public, and call it
> from kvm_riscv_cpu_add_kvm_properties(). This will make it easier to
> split KVM specific code for the KVM accelerator class in the next patch.
>
>
On 9/7/23 06:43, Nicholas Piggin wrote:
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
Use nested guest state specific struct for storing related info.
So this is the patch I would introduce the SpaprMachineStateNested
struct, with just the .ptrc member. Add other members to
Hi!
I noticed that linux-user binaries, when built separately (with
--enable-linux-user --disable-system) or when built as part of
system build (--enable-linux-user --enable-system) differ in size
and link with significantly more libraries which they shouldn't
link with. libnuma, liburing, libgn
On 06.09.23 14:04, David Hildenbrand wrote:
If there are no more comments, I'll queue this myself soon.
Queued to
https://github.com/davidhildenbrand/qemu.git mem-next
--
Cheers,
David / dhildenb
@MST, any comment on the vhost bits (mostly uncontroversial and only in
the memslot domain)?
I'm planning on queuing this myself (but will wait a bit more), unless
you want to take it.
On 08.09.23 16:21, David Hildenbrand wrote:
Quoting from patch #14:
Having large virtio-mem devices
On Wed, Sep 06, 2023 at 12:23:19PM +0200, Philippe Mathieu-Daudé wrote:
> On 6/9/23 11:16, Daniel Henrique Barboza wrote:
> > This file is not needed for some time now. All the stubs implemented in
> > it (kvm_riscv_reset_vcpu() and kvm_riscv_set_irq()) are wrapped in 'if
> > kvm_enabled()' blocks
From: Avihai Horon
Initialization of mig_stats, compression_counters and VFIO bytes
transferred is hard-coded in migration code path and snapshot code path.
Make the code cleaner by initializing them in migrate_init().
Suggested-by: Cédric Le Goater
Signed-off-by: Avihai Horon
Reviewed-by: Cé
From: Avihai Horon
Background snapshot allows creating a snapshot of the VM while it's
running and keeping it small by not including dirty RAM pages.
The way it works is by first stopping the VM, saving the non-iterable
devices' state and then starting the VM and saving the RAM while write
prote
From: Joao Martins
QEMU computes the DMA logging ranges for two predefined ranges: 32-bit
and 64-bit. In the OVMF case, when the dynamic MMIO window is enabled,
QEMU includes in the 64-bit range the RAM regions at the lower part
and vfio-pci device RAM regions which are at the top of the address
From: Avihai Horon
VFIO migration is not compatible with postcopy migration. A VFIO device
in the destination can't handle page faults for pages that have not been
sent yet.
Doing such migration will cause the VM to crash in the destination:
qemu-system-x86_64: VFIO_MAP_DMA failed: Bad address
From: Avihai Horon
Changing the device state from STOP_COPY to STOP can take time as the
device may need to free resources and do other operations as part of the
transition. Currently, this is done in vfio_save_complete_precopy() and
therefore it is counted in the migration downtime.
To avoid th
From: Avihai Horon
Now that P2P support has been added to VFIO migration, allow migration
of multiple devices if all of them support P2P migration.
Single device migration is allowed regardless of P2P migration support.
Signed-off-by: Avihai Horon
Signed-off-by: Joao Martins
Reviewed-by: Cédr
From: Avihai Horon
VFIO migration uAPI defines an optional intermediate P2P quiescent
state. While in the P2P quiescent state, P2P DMA transactions cannot be
initiated by the device, but the device can respond to incoming ones.
Additionally, all outstanding P2P transactions are guaranteed to have
From: Avihai Horon
The functions in target.c are not static, yet they don't have a proper
migration prefix. Add such prefix.
Signed-off-by: Avihai Horon
Reviewed-by: Cédric Le Goater
Signed-off-by: Cédric Le Goater
---
migration/migration.h | 4 ++--
migration/migration.c | 6 +++---
migrati
From: Avihai Horon
Add a new .save_prepare() handler to struct SaveVMHandlers. This handler
is called early, even before migration starts, and can be used by
devices to perform early checks.
Refactor migrate_init() to be able to return errors and call
.save_prepare() from there.
Suggested-by: P
From: Avihai Horon
Add qdev_add_vm_change_state_handler_full() variant that allows setting
a prepare callback in addition to the main callback.
This will facilitate adding P2P support for VFIO migration in the
following patches.
Signed-off-by: Avihai Horon
Signed-off-by: Joao Martins
Reviewed
From: Avihai Horon
Add prepare callback to struct VMChangeStateEntry.
The prepare callback is optional and can be set by the new function
qemu_add_vm_change_state_handler_prio_full() that allows setting this
callback in addition to the main callback.
The prepare callbacks and main callbacks are
The following changes since commit c5ea91da443b458352c1b629b490ee6631775cb4:
Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into
staging (2023-09-08 10:06:25 -0400)
are available in the Git repository at:
https://github.com/legoater/qemu/ tags/pull-vfio-2023091
From: Avihai Horon
If a device with enable-migration=on is added and it causes a migration
blocker, adding the device should fail with a proper error.
This is not the case with multiple device migration blocker when the
blocker already exists. If the blocker already exists and a device with
enab
From: Joao Martins
Move the PRE_COPY and RUNNING state checks to helper functions.
This is in preparation for adding P2P VFIO migration support, where
these helpers will also test for PRE_COPY_P2P and RUNNING_P2P states.
Signed-off-by: Joao Martins
Signed-off-by: Avihai Horon
Reviewed-by: Céd
On Wed, Sep 06, 2023 at 06:16:38AM -0300, Daniel Henrique Barboza wrote:
> Add a KVM accelerator class like we did with TCG. The difference is
> that, at least for now, we won't be using a realize() implementation for
> this accelerator.
>
> We'll start by assiging kvm_riscv_cpu_add_kvm_properties
On Wed, Sep 06, 2023 at 06:16:41AM -0300, Daniel Henrique Barboza wrote:
> We'll move riscv_init_max_cpu_extensions() to tcg-cpu.c in the next
> patch and set_misa() needs to be usable from there.
>
> Rename it to riscv_cpu_set_misa() and make it public.
>
> Signed-off-by: Daniel Henrique Barboza
On Wed, Sep 06, 2023 at 06:16:43AM -0300, Daniel Henrique Barboza wrote:
> The array isn't marked as 'const' because we're initializing their
> elements in riscv_cpu_add_misa_properties(), 'name' and 'description'
> fields.
>
> In a closer look we can see that we're not using these 2 fields after
There's one commit, tagged v7.2.2, without Signed-off-by line.
Due to this, check-dco test always fail on 7.2. Since this is
a stable branch with almost all commits coming from master
already with S-o-b (except of the version bumps and very rare
stable-specific commits), and v7.2.2 is already cast
From: Alexander Bulekov
As the code is designed for re-entrant calls from raven_io_ops to
pci-conf, mark raven_io_ops as reentrancy-safe.
Signed-off-by: Alexander Bulekov
Message-Id: <20230427211013.2994127-8-alx...@bu.edu>
Signed-off-by: Thomas Huth
(cherry picked from commit 6dad5a6810d9c60c
From: Alexander Bulekov
Advise authors to use the _guarded versions of the APIs, instead.
Signed-off-by: Alexander Bulekov
Reviewed-by: Darren Kenny
Message-Id: <20230427211013.2994127-4-alx...@bu.edu>
Signed-off-by: Thomas Huth
(cherry picked from commit ef56ffbdd6b0605dc1e305611287b948c970e
From: John Snow
The pipenv tool was nice in theory, but in practice it's just too hard
to update selectively, and it makes using it a pain. The qemu.qmp repo
dropped pipenv support a while back and it's been functioning just fine,
so I'm backporting that change here to qemu.git.
Signed-off-by: J
From: Alexander Bulekov
Devices can pass their MemoryReentrancyGuard (from their DeviceState),
when creating new BHes. Then, the async API will toggle the guard
before/after calling the BH call-back. This prevents bh->mmio reentrancy
issues.
Signed-off-by: Alexander Bulekov
Reviewed-by: Darren
From: Alexander Bulekov
As lpc-hc is designed for re-entrant calls from xscom, mark it
re-entrancy safe.
Reported-by: Thomas Huth
Signed-off-by: Alexander Bulekov
[clg: mark opb_master_regs as re-entrancy safe also ]
Signed-off-by: Cédric Le Goater
Reviewed-by: Frederic Barrat
Tested-by: Tho
From: Alexander Bulekov
loongarch_ipi_iocsr MRs rely on re-entrant IO through the ipi_send
function. As such, mark these MRs re-entrancy-safe.
Fixes: a2e1753b80 ("memory: prevent dma-reentracy issues")
Signed-off-by: Alexander Bulekov
Reviewed-by: Song Gao
Message-Id: <20230506112145.3563708-1
From: Alexander Bulekov
Add a flag to the DeviceState, when a device is engaged in PIO/MMIO/DMA.
This flag is set/checked prior to calling a device's MemoryRegion
handlers, and set when device code initiates DMA. The purpose of this
flag is to prevent two types of DMA-based reentrancy issues:
1
From: Niklas Cassel
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
Successfully means ERR_STAT, BUSY and DRQ are all cleared.
A command that has ERR_STAT set, does not get to clear PxCI.
See AHCI 1.3.1, section 5.3.8, stat
From: Alexander Bulekov
As the code is designed for re-entrant calls from bcm2835_property to
bcm2835_mbox and back into bcm2835_property, mark iomem as
reentrancy-safe.
Signed-off-by: Alexander Bulekov
Reviewed-by: Thomas Huth
Message-Id: <20230427211013.2994127-7-alx...@bu.edu>
Signed-off-by
From: Alexander Bulekov
A BH callback can free the BH, causing a use-after-free in aio_bh_call.
Fix that by keeping a local copy of the re-entrancy guard pointer.
Buglink: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58513
Fixes: 9c86c97f12 ("async: Add an optional reentrancy guard to t
From: Thomas Huth
While trying to use a SCSI disk on the LSI controller with an
older version of Fedora (25), I'm getting:
qemu: warning: Blocked re-entrant IO on MemoryRegion: lsi-mmio at addr: 0x34
and the SCSI controller is not usable. Seems like we have to
disable the reentrancy checker fo
The following patches are queued for QEMU stable v7.2.6:
https://gitlab.com/qemu-project/qemu/-/commits/staging-7.2
Patch freeze is 2023-09-19, and the release is planned for 2023-09-21:
https://wiki.qemu.org/Planning/7.2
Please respond here or CC qemu-sta...@nongnu.org on any additional pa
From: Alexander Bulekov
As the code is designed to use the memory APIs to access the script ram,
disable reentrancy checks for the pseudo-RAM ram_io MemoryRegion.
In the future, ram_io may be converted from an IO to a proper RAM MemoryRegion.
Reported-by: Fiona Ebner
Signed-off-by: Alexander B
From: Alexander Bulekov
This protects devices from bh->mmio reentrancy issues.
Thanks: Thomas Huth for diagnosing OS X test failure.
Signed-off-by: Alexander Bulekov
Reviewed-by: Darren Kenny
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Paul Durrant
Reviewed-by
Hi
On Fri, Sep 8, 2023 at 3:55 AM Laszlo Ersek wrote:
>
> On 9/8/23 01:47, Laszlo Ersek wrote:
>
> > I don't know why qemu_console_is_multihead() used a lot of QOM
> > trickery for this in the first place, but here's what I'd propose as
> > fix -- simply try to locate a QemuGraphicConsole in "con
From: Alexander Bulekov
As the code is designed for re-entrant calls to apic-msi, mark apic-msi
as reentrancy-safe.
Signed-off-by: Alexander Bulekov
Reviewed-by: Darren Kenny
Message-Id: <20230427211013.2994127-9-alx...@bu.edu>
Signed-off-by: Thomas Huth
(cherry picked from commit 50795ee051a
Hi
On Fri, Sep 8, 2023 at 3:47 AM Laszlo Ersek wrote:
>
> Question for Gerd below:
>
> On 9/7/23 14:29, Philippe Mathieu-Daudé wrote:
> > On 7/9/23 13:25, Laszlo Ersek wrote:
> >> This is with QEMU v8.1.0-391-gc152379422a2.
> >>
> >> I use the command line from (scroll to the bottom):
> >>
> >>
On 9/7/23 07:05, Nicholas Piggin wrote:
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
With this patch, isolating kvm-hv nested api code to be executed only
when cap-nested-hv is set. This helps keeping api specific logic
mutually exclusive.
Changelog needs a bit of improveme
Warner, Kyle, can you take a look please?
https://patchew.org/QEMU/20230909131258.354675-1-...@tls.msk.ru/20230909131258.354675-2-...@tls.msk.ru/
09.09.2023 16:12, Michael Tokarev:
Signed-off-by: Michael Tokarev
---
bsd-user/errno_defs.h| 2 +-
bsd-user/freebsd/target_os_sig
On Mon, Sep 11, 2023 at 12:12:43PM +0400, Marc-André Lureau wrote:
> > Gerd, here's the question for you: why are "device" and "head" QOM
> > properties in the first place? What are they needed for?
> >
>
> You get QOM tree introspection (ex: (qemu) qom-get
> /backend/console[0]/device type). Oth
Paolo, Michael, can you take a quick look please?
https://patchew.org/QEMU/20230909131258.354675-1-...@tls.msk.ru/20230909131258.354675-3-...@tls.msk.ru/
09.09.2023 16:12, Michael Tokarev:
Signed-off-by: Michael Tokarev
---
host/include/i386/host/cpuinfo.h | 2 +-
hw/i386/acpi-build.c
On Sun, 10 Sept 2023 at 22:01, Michael Tokarev wrote:
>
> Hi!
>
> For quite some time I'm collecting stuff for stable, pocking various
> people with questions about stable, etc, so has become somewhat more
> visible and somewhat annoying too :) Especially when I publish the
> next stable patch ro
Daniel, Cédric, can you take a quick look please?
https://patchew.org/QEMU/20230909131258.354675-1-...@tls.msk.ru/20230909131258.354675-4-...@tls.msk.ru/
09.09.2023 16:12, Michael Tokarev:
Signed-off-by: Michael Tokarev
---
host/include/ppc/host/cpuinfo.h | 2 +-
hw/ppc/ppc.c
>-Original Message-
>From: qemu-devel-bounces+zhenzhong.duan=intel@nongnu.org devel-bounces+zhenzhong.duan=intel@nongnu.org> On Behalf Of Joao
>Martins
>Sent: Friday, September 8, 2023 5:30 PM
>Subject: [PATCH v1] vfio/common: Separate vfio-pci ranges
>
>QEMU computes the DMA logg
Add virtio-mmio bus support for LoongArch, so that devices
could be added in the virtio-mmio bus.
Signed-off-by: Tianrui Zhao
Change-Id: Ib882005106562e0dfe74122a7fa2430fa081bfb2
---
hw/loongarch/Kconfig | 1 +
hw/loongarch/acpi-build.c | 25 +
hw/loongarch/virt.c
On Mon, Sep 11, 2023 at 09:49:06AM +0200, Andrew Jones wrote:
> On Wed, Sep 06, 2023 at 12:23:19PM +0200, Philippe Mathieu-Daudé wrote:
> > On 6/9/23 11:16, Daniel Henrique Barboza wrote:
> > > This file is not needed for some time now. All the stubs implemented in
> > > it (kvm_riscv_reset_vcpu()
On 11/09/2023 09:57, Duan, Zhenzhong wrote:
>> -Original Message-
>> From: qemu-devel-bounces+zhenzhong.duan=intel@nongnu.org > devel-bounces+zhenzhong.duan=intel@nongnu.org> On Behalf Of Joao
>> Martins
>> Sent: Friday, September 8, 2023 5:30 PM
>> Subject: [PATCH v1] vfio/common:
On 9/9/23 15:12, Michael Tokarev wrote:
Signed-off-by: Michael Tokarev
LGTM,
Reviewed-by: Cédric Le Goater
Thanks,
C.
---
host/include/ppc/host/cpuinfo.h | 2 +-
hw/ppc/ppc.c| 2 +-
hw/ppc/prep_systemio.c | 2 +-
hw/ppc/spapr.c
On 9/10/23 23:34, Alistair Francis wrote:
On Sat, Sep 2, 2023 at 5:48 AM Daniel Henrique Barboza
wrote:
Hi,
This new version contains suggestions made by Andrew Jones in v8.
Most notable change is the removal of the opensbi.py test in patch 11,
which was replaced by a TuxBoot test. It's m
On Fri, 8 Sep 2023 20:02:41 +0300
Michael Tokarev wrote:
> 08.08.2023 17:44, Jonathan Cameron:
>
> > Sorry, I'm running a bit behind. Have this one a few other fixes
> > still queued up - I didn't consider any of them particularly critical
> > for the release so wasn't rushing.
> >
> > I'll ai
This patch solves two problem:
First, when we suspended guest VM, it called into Qemu to call
virtio_reset->__virtio_queue_reset, this cleared all virtuqueue
information of virtgpu on Qemu end. As a result, after guest
resumed, guest sended ctrl/cursor requests to Qemu through
virtqueue, but Qemu
Hi all,
I hope you’ll forgive me if this disturb you. Since it has been almost two
months since the latest patch was sent out, I didn't receive any reply, so I
rebase the latest master branch and sent it again. I am looking forward to
getting your response.
Best regards,
Jiqian Chen
v3:
Hi all,
T
On 8/9/23 19:45, Jonathan Perkin wrote:
qemu 8.1.0 breaks on illumos platforms due to _XOPEN_SOURCE and others
no longer being set correctly, leading to breakage such as:
https://us-central.manta.mnx.io/pkgsrc/public/reports/trunk/tools/20230908.1404/qemu-8.1.0/build.log
Paolo if you don'
On 11/9/23 01:28, Gavin Shan wrote:
Hi Philippe,
On 9/8/23 21:22, Philippe Mathieu-Daudé wrote:
Add a field to return the QOM type name of a CPU class.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 2 ++
hw/core/cpu-common.c | 2 +-
target/alpha/cpu.c | 1 +
The previous parts of the graph locking changes focussed mostly on the
BlockDriver side and taking reader locks while performing I/O. This
series focusses more on the functions managing the graph structure, i.e
adding, removing and replacing nodes and updating their permissions.
Many of these plac
This field has been unused since commit 72373e40fbc ('block:
bdrv_reopen_multiple: refresh permissions on updated graph').
Remove it.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
block.c | 1 -
1 file changed, 1 del
Instead of taking the writer lock internally, require callers to already
hold it when calling bdrv_unref_child(). These callers will typically
already hold the graph lock once the locking work is completed, which
means that they can't call functions that take it internally.
Signed-off-by: Kevin Wo
When the permission related BlockDriver callbacks are called, we are in
the middle of an operation traversing the block graph. Polling in such a
place is a very bad idea because the graph could change in unexpected
ways. In the future, callers will also hold the graph lock, which is
likely to turn
The functions read the parents list in the generic block layer, so we
need to hold the graph lock already there. The BlockDriver
implementations actually modify the graph, so it has to be a writer
lock.
Signed-off-by: Kevin Wolf
Reviewed-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnocz
Instead of taking the writer lock internally, require callers to already
hold it when calling bdrv_replace_child_tran(). These callers will
typically already hold the graph lock once the locking work is
completed, which means that they can't call functions that take it
internally.
While a graph lo
Don't assume specific parameter names like 'bs' or 'blk' in the
generated code, but use the actual name.
Signed-off-by: Kevin Wolf
Reviewed-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
scripts/block-coroutine-wrapper.py | 7 ---
1 file changed, 4 insertions(+), 3 deletio
bdrv_unref() is called by a lot of places that need to hold the graph
lock (it naturally happens in the context of operations that change the
graph). However, bdrv_unref() takes the graph writer lock internally, so
it can't actually be called while already holding a graph lock without
causing a dea
The documentation for bdrv_append() says that the caller must hold the
AioContext lock for bs_top. Change all callers to actually adhere to the
contract.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
tests/unit/test-
Instead of taking the writer lock internally, require callers to already
hold it when calling bdrv_attach_child_common(). These callers will
typically already hold the graph lock once the locking work is
completed, which means that they can't call functions that take it
internally.
Signed-off-by:
The function reads the parents list, so it needs to hold the graph lock.
Signed-off-by: Kevin Wolf
Reviewed-by: Emanuele Giuseppe Esposito
---
block.c | 4
1 file changed, 4 insertions(+)
diff --git a/block.c b/block.c
index e024a6ccec..8e589bb2e4 100644
--- a/block.c
+++ b/block.c
@@ -76
Instead of taking the writer lock internally, require callers to already
hold it when calling bdrv_root_unref_child(). These callers will
typically already hold the graph lock once the locking work is
completed, which means that they can't call functions that take it
internally.
Signed-off-by: Kev
The function reads the parents list, so it needs to hold the graph lock.
This happens to result in BlockDriver.bdrv_set_perm() to be called with
the graph lock held. For consistency, make it the same for all of the
BlockDriver callbacks for updating permissions and annotate the function
pointers w
Instead of taking the writer lock internally, require callers to already
hold it when calling bdrv_attach_child_common(). These callers will
typically already hold the graph lock once the locking work is
completed, which means that they can't call functions that take it
internally.
Note that the t
The function reads the parents list, so it needs to hold the graph lock.
Signed-off-by: Kevin Wolf
Reviewed-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
include/block/block_int-common.h| 6 ++---
include/block/block_int-global-state.h | 8 +++---
include/s
Add a new wrapper type for GRAPH_WRLOCK functions that should be called
from coroutine context.
Signed-off-by: Kevin Wolf
Reviewed-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
include/block/block-common.h | 4
scripts/block-coroutine-wrapper.py | 11 +++
It's essentially the same code in preallocate_check_perm() and
preallocate_close(), except that the latter ignores errors.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
block/preallocate.c | 48 +-
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_child_perm() need to hold a reader lock for the graph because
some implementations access the children list of a node.
The callers of bdrv_child_perm() conveniently already hold the lock.
Signed-off-by: Kevin Wolf
Reviewed-by: Em
Instead of taking the writer lock internally, require callers to already
hold it when calling bdrv_replace_child_noperm(). These callers will
typically already hold the graph lock once the locking work is
completed, which means that they can't call functions that take it
internally.
Signed-off-by:
>-Original Message-
>From: Joao Martins
>Sent: Monday, September 11, 2023 5:07 PM
>Subject: Re: [PATCH v1] vfio/common: Separate vfio-pci ranges
>
>On 11/09/2023 09:57, Duan, Zhenzhong wrote:
>>> -Original Message-
>>> From: qemu-devel-bounces+zhenzhong.duan=intel@nongnu.org
In previous patches, we changed some transactionable functions to be
marked as GRAPH_WRLOCK, but required that tran_finalize() is still
called without the lock. This was because all callbacks that can be in
the same transaction need to follow the same convention.
Now that we don't have conflicting
The function reads the parents list, so it needs to hold the graph lock.
Signed-off-by: Kevin Wolf
Reviewed-by: Emanuele Giuseppe Esposito
---
block.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block.c b/block.c
index 06d2a1b256..e024a6ccec 100644
--- a/block.c
+++ b/block.c
@@ -5938
The function reads the parents list, so it needs to hold the graph lock.
Signed-off-by: Kevin Wolf
Reviewed-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
block.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 0f7f78f8de..06d2a
Stefan, can you take a quick look please?
https://patchew.org/QEMU/20230909131258.354675-1-...@tls.msk.ru/20230909131258.354675-7-...@tls.msk.ru/
Most of this is s/Familiy/Family/ in a few places, I guess it's
some copy-paste error.
09.09.2023 16:12, Michael Tokarev:
Signed-off-by: Michael T
Hi all,
I hope you’ll forgive me if this disturb you. Since it has been almost two
months since the latest patch was sent out, I didn't receive any reply, so I
rebase the latest master branch and sent it again. I am looking forward to
getting your response.
Best regards,
Jiqian Chen
v3:
Hi all,
T
When we suspend/resume guest on Xen, the display can't come back.
This is because when guest suspended, it called into Qemu. Then
Qemu destroyed all resources which is used for display. So that
guest's display can't come back to the time when it was suspended.
To solve above problem, I added a new
On 8/9/23 17:47, Stefan Hajnoczi wrote:
I wonder how it passed CI?
https://gitlab.com/qemu-project/qemu/-/pipelines/996175923/
The conditions are:
- x86 host
- both system / user emulation enabled
- KVM disabled
- debug enabled
We have jobs with 3 of the 4, but none with
all the 4.
Is it wort
On 8/9/23 21:21, Paolo Bonzini wrote:
On Fri, Sep 8, 2023 at 7:28 PM Kevin Wolf wrote:
Maybe the calls aren't eliminated because --enable-debug implies -O0?
My experience is that it will still fold simple dead code like "0 &&
foo()" or even "if (0) { ... }", but maybe it's a GCC vs. clang
dif
Michael Tokarev writes:
> Hi!
>
> I noticed that linux-user binaries, when built separately (with
> --enable-linux-user --disable-system) or when built as part of
> system build (--enable-linux-user --enable-system) differ in size
> and link with significantly more libraries which they shouldn'
On 11/09/2023 10:48, Duan, Zhenzhong wrote:
>> -Original Message-
>> From: Joao Martins
>> Sent: Monday, September 11, 2023 5:07 PM
>> Subject: Re: [PATCH v1] vfio/common: Separate vfio-pci ranges
>>
>> On 11/09/2023 09:57, Duan, Zhenzhong wrote:
-Original Message-
From:
I am working on aarch64/sbsa-ref machine so people can have virtual
machine to test their OS against something reminding standards compliant
system.
One of tools I use is BSA ACS (Base System Architecture - Architecture
Compliance Suite) [1] written by Arm. It runs set of tests to check does
syst
On 11/09/2023 10:48, Duan, Zhenzhong wrote:
+static bool vfio_section_is_vfio_pci(MemoryRegionSection *section,
+ VFIOContainer *container)
+{
+VFIOPCIDevice *pcidev;
+VFIODevice *vbasedev;
+VFIOGroup *group;
+Ob
On 11/9/23 12:10, Philippe Mathieu-Daudé wrote:
On 8/9/23 17:47, Stefan Hajnoczi wrote:
I wonder how it passed CI?
https://gitlab.com/qemu-project/qemu/-/pipelines/996175923/
The conditions are:
- x86 host
- both system / user emulation enabled
- KVM disabled
- debug enabled
Oh, I forgot:
-
After suspending and resuming guest VM, you will get
a black screen, and the display can't come back.
This is because when guest did suspending, it called
into qemu to call virtio_gpu_gl_reset. In function
virtio_gpu_gl_reset, it destroyed resources and reset
renderer, which were used for display.
Hi all,
I hope you’ll forgive me if this disturb you. Since it has been almost two
months since the latest patch was sent out, I didn't receive any reply, so I
rebase the latest master branch and sent it again. I am looking forward to
getting your response.
Best regards,
Jiqian Chen
v4:
Hi all,
T
Since commits 3adce820cf..ef1cf6890f, When building on
a x86 host configured as:
$ ./configure --cc=clang \
--target-list=x86_64-linux-user,x86_64-softmmu \
--enable-debug
we get:
[71/71] Linking target qemu-x86_64
FAILED: qemu-x86_64
/usr/bin/ld: libqemu-x86_64-linux-user.fa.p/t
Example output has extra end curly bracket. Remove it.
Signed-off-by: Victor Toso
Reviewed-by: Daniel P. Berrangé
---
qapi/migration.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qapi/migration.json b/qapi/migration.json
index 9385b9f87c..2658cdbcbe 100644
--- a/qapi/
Example output has property name with single quotes. Fix it.
Signed-off-by: Victor Toso
Reviewed-by: Daniel P. Berrangé
---
qapi/migration.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qapi/migration.json b/qapi/migration.json
index 2658cdbcbe..45dac41f67 100644
--- a
Example output has a comment embedded in the array. Remove it.
The end result is a list of size 2.
Signed-off-by: Victor Toso
---
qapi/ui.json | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/qapi/ui.json b/qapi/ui.json
index 006616aa77..6ed36c45ea 100644
--- a/qapi/ui.json
Example output has a comment embedded in the array. Remove it.
The end result is a list of size 1.
Signed-off-by: Victor Toso
---
qapi/rocker.json | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/qapi/rocker.json b/qapi/rocker.json
index 31ce0b36f6..858e4f4a45 100644
--- a/q
1 - 100 of 296 matches
Mail list logo
