Re: [PATCH for-8.0] ide: Fix manual in-flight count for TRIM BH

Am 09.03.23 um 18:46 schrieb Kevin Wolf: > Am 09.03.2023 um 14:59 hat Paolo Bonzini geschrieben: >> On 3/9/23 13:31, Hanna Czenczek wrote: >>> On 09.03.23 13:08, Paolo Bonzini wrote: On Thu, Mar 9, 2023 at 1:05 PM Paolo Bonzini wrote: > I think having to do this is problematic, because

Re: [PATCH v6 1/4] memory: prevent dma-reentracy issues

Am 05.02.23 um 05:07 schrieb 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

Deadlock with ide_issue_trim and draining

Hi, I am suspecting that commit 7e5cdb345f ("ide: Increment BB in-flight counter for TRIM BH") introduced an issue in combination with draining. >From a debug session on a costumer's machine I gathered the following information: * The QEMU process hangs in aio_poll called during draining and

Re: [PATCH for-8.0] ide: Fix manual in-flight count for TRIM BH

Am 10.03.23 um 16:13 schrieb Paolo Bonzini: > On Fri, Mar 10, 2023 at 3:25 PM Kevin Wolf wrote: >>> 1. The TRIM operation should be completed on the IDE level before >>> draining ends. >>> 2. Block layer requests issued after draining has begun are queued. >>> >>> To me, the conclusion seems to

Re: [PATCH v2] vl: defuse PID file path resolve error

Am 24.01.23 um 14:55 schrieb Fiona Ebner: > Am 31.10.22 um 10:47 schrieb Fiona Ebner: >> Commit 85c4bf8aa6 ("vl: Unlink absolute PID file path") introduced a >> critical error when the PID file path cannot be resolved. Before this >> commit, it was possible t

[PATCH] hw/ide/ahci: trace ncq write command as write instead of read

Fixes: e4baa9f00b ("AHCI: Replace DPRINTF with trace-events") Signed-off-by: Fiona Ebner --- Or should it be sorted alphabetically below execute_ncq_command_unsup? I felt read and write belong close together and this reflects the positions in the code. hw/ide/ahci.c | 4 ++

Re: Lost partition tables on ide-hd + ahci drive

ll be addressed by [1]. Any chance that it could be related? [0]: https://gitlab.com/qemu-project/qemu/-/issues/62 [1]: https://lists.nongnu.org/archive/html/qemu-devel/2023-02/msg01141.html Best Regards, Fiona > On Thu, Feb 16, 2023 at 6:25 PM Fiona Ebner wrote: >> >> Am 16.02.23

Re: Lost partition tables on ide-hd + ahci drive

Am 16.02.23 um 15:17 schrieb Mike Maslenkin: > Does additional comparison make a sense here: check for LBA == 0 and > then check MBR signature bytes. > Additionally it’s easy to check buffer_is_zero() result or even print > FIS contents under these conditions. > Data looks like a part of guest

Re: [PATCH 3/9] mirror: implement mirror_change method

Am 01.03.23 um 16:18 schrieb Vladimir Sementsov-Ogievskiy: > On 24.02.23 17:48, Fiona Ebner wrote: >> which allows switching the @copy-mode from 'background' to >> 'write-blocking'. >> >> Once the job is in active mode, no new writes need to be registered in &

Re: [PATCH 8/9] mirror: return the remaining dirty bytes upon query

Am 02.03.23 um 11:13 schrieb Vladimir Sementsov-Ogievskiy: > On 02.03.23 13:00, Fiona Ebner wrote: >> Am 01.03.23 um 17:31 schrieb Vladimir Sementsov-Ogievskiy: >>> On 24.02.23 17:48, Fiona Ebner wrote: >>>> This can be used by management applications starting with

Re: [PATCH 8/9] mirror: return the remaining dirty bytes upon query

Am 01.03.23 um 17:31 schrieb Vladimir Sementsov-Ogievskiy: > On 24.02.23 17:48, Fiona Ebner wrote: >> This can be used by management applications starting with a job in >> background mode to determine when the switch to active mode should >> happen. >> >> Suggested

Re: [PATCH 8/9] mirror: return the remaining dirty bytes upon query

Am 02.03.23 um 17:31 schrieb Vladimir Sementsov-Ogievskiy: > On 02.03.23 15:34, Fiona Ebner wrote: >> Am 02.03.23 um 11:13 schrieb Vladimir Sementsov-Ogievskiy: >>> On 02.03.23 13:00, Fiona Ebner wrote: >>>> Am 01.03.23 um 17:31 schrieb Vladimir Sementsov-Ogievskiy:

Re: [PATCH] scsi: megasas: Internal cdbs have 16-byte length

quot;), this results in failures to boot Linux from affected > SCSI drives because cdb_len is set to 0 by the host driver. > Set the cdb length to its actual size to solve the problem. > Tested-by: Fiona Ebner But I do have a question: > Signed-off-by: Guenter Roeck > --- >

Re: [PATCH] scsi: megasas: Internal cdbs have 16-byte length

Am 03.03.23 um 16:10 schrieb Guenter Roeck: > On 3/3/23 01:02, Fiona Ebner wrote: >> Am 28.02.23 um 18:11 schrieb Guenter Roeck: >>> Host drivers do not necessarily set cdb_len in megasas io commands. >>> With commits 6d1511cea0 ("scsi: Reject commands if th

Re: Lost partition tables on ide-hd + ahci drive

Am 15.02.23 um 22:47 schrieb John Snow: > Hm, I'm not sure I see any pattern that might help. Could be that AHCI > is just bugged during load, but it's tough to know in what way. If we ever get a backtrace where the bad write actually goes through QEMU, I'll let you know. We are considering

Re: Lost partition tables on ide-hd + ahci drive

Am 16.02.23 um 15:17 schrieb Mike Maslenkin: > Does additional comparison make a sense here: check for LBA == 0 and > then check MBR signature bytes. > Additionally it’s easy to check buffer_is_zero() result or even print > FIS contents under these conditions. > Data looks like a part of guest

[PATCH 7/9] mirror: return mirror-specific information upon query

-by: Fiona Ebner --- block/mirror.c | 10 ++ qapi/block-core.json | 15 ++- 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/block/mirror.c b/block/mirror.c index 961aaa5cd6..02b5bd8bd2 100644 --- a/block/mirror.c +++ b/block/mirror.c @@ -1253,6 +1253,15 @@ static

[PATCH 2/9] block/mirror: set actively_synced even after the job is ready

In preparation to allow switching from background to active mode. This ensures that setting actively_synced will not be missed when the switch happens after the job is ready. Signed-off-by: Fiona Ebner --- block/mirror.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 8/9] mirror: return the remaining dirty bytes upon query

This can be used by management applications starting with a job in background mode to determine when the switch to active mode should happen. Suggested-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Fiona Ebner --- block/mirror.c | 1 + qapi/block-core.json | 4 +++- 2 files changed, 4

[PATCH 0/9] mirror: allow switching from background to active mode

tal data sent, and the remaining dirty bytes. Initially, I tried to go for a more general 'job-change' command, but I couldn't figure out a way to avoid mutual inclusion between block-core.json and job.json. Fiona Ebner (9): blockjob: introduce block-job-change QMP command block/mirror:

[PATCH 4/9] qapi/block-core: use JobType for BlockJobInfo's type

In preparation to turn BlockJobInfo into a union with @type as the discriminator. That requires it to be an enum. No functional change is intended. Signed-off-by: Fiona Ebner --- block/monitor/block-hmp-cmds.c | 4 ++-- blockjob.c | 2 +- qapi/block-core.json | 2

[PATCH 9/9] mirror: return the total number of bytes sent upon query

to be relative to @len only and @len is documented to be able to change in both directions while the job runs. Suggested-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Fiona Ebner --- block/mirror.c | 6 ++ qapi/block-core.json | 5 - 2 files changed, 10 insertions(+), 1 deletion(-) diff

[PATCH 6/9] blockjob: query driver-specific info via a new 'query' driver method

Signed-off-by: Fiona Ebner --- blockjob.c | 4 include/block/blockjob_int.h | 5 + 2 files changed, 9 insertions(+) diff --git a/blockjob.c b/blockjob.c index 9bd51bc6ae..5570890001 100644 --- a/blockjob.c +++ b/blockjob.c @@ -349,6 +349,7 @@ BlockJobInfo

[PATCH 1/9] blockjob: introduce block-job-change QMP command

which will allow changing job-type-specific options after job creation. In the JobVerbTable, the same allow bits as for set-speed are used, because set-speed could be considered an existing change command. Signed-off-by: Fiona Ebner --- Tried to go more general at first with a 'job-change

[PATCH 3/9] mirror: implement mirror_change method

for those criteria is a bit limited, so the plan is to extend quering of block jobs to return more information relevant for mirror. Signed-off-by: Fiona Ebner --- Sorry, I still haven't fully grasped the drained logic. Is my rationale for the drained section correct? There also are some yield

[PATCH 5/9] qapi/block-core: turn BlockJobInfo into a union

In preparation to additionally return job-type-specific information. Signed-off-by: Fiona Ebner --- qapi/block-core.json | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/qapi/block-core.json b/qapi/block-core.json index c1ac6de238..adb43a4592 100644 --- a/qapi/block

Re: [PATCH 0/9] mirror: allow switching from background to active mode

Am 01.03.23 um 15:34 schrieb Vladimir Sementsov-Ogievskiy: > On 24.02.23 17:48, Fiona Ebner wrote: >> With active mode, the guest write speed is limited by the synchronous >> writes to the mirror target. For this reason, management applications >> might want to start o

Re: [PATCH] block/mirror: add 'write-blocking-after-ready' copy mode

Am 14.02.23 um 17:19 schrieb Vladimir Sementsov-Ogievskiy: > On 02.02.23 16:27, Fiona Ebner wrote: >> Am 02.02.23 um 12:34 schrieb Kevin Wolf: >>> But having to switch the mirror job to sync mode just to avoid doing I/O >>> on an inactive device sounds wrong to me. It

Re: [PULL 03/11] block/iscsi: fix double-free on BUSY or similar statuses

Am 08.02.23 um 18:19 schrieb Paolo Bonzini: > Commit 8c460269aa77 ("iscsi: base all handling of check condition on > scsi_sense_to_errno", 2019-07-15) removed a "goto out" so that the > same coroutine is re-entered twice; once from iscsi_co_generic_cb, > once from the timer callback

Re: [PULL 19/54] acpi: pc: isa bridge: use AcpiDevAmlIf interface to build ISA device descriptors

Am 12.04.23 um 14:18 schrieb Igor Mammedov: > On Thu, 30 Mar 2023 13:58:22 +0200 > Fiona Ebner wrote: > >> Am 30.03.23 um 10:22 schrieb Igor Mammedov: >>> On Tue, 28 Mar 2023 14:58:21 +0200 >>> Fiona Ebner wrote: >>> >>>> >>>

Re: QMP (without OOB) function running in thread different from the main thread as part of aio_poll

Am 27.04.23 um 13:03 schrieb Kevin Wolf: > Am 26.04.2023 um 16:31 hat Fiona Ebner geschrieben: >> Am 20.04.23 um 08:55 schrieb Paolo Bonzini: >>> >>> >>> Il gio 20 apr 2023, 08:11 Markus Armbruster >> <mailto:arm...@redhat.com>> ha scritto:

Re: QMP (without OOB) function running in thread different from the main thread as part of aio_poll

Am 27.04.23 um 16:36 schrieb Juan Quintela: > Fiona Ebner wrote: >> Am 27.04.23 um 13:03 schrieb Kevin Wolf: >>> Am 26.04.2023 um 16:31 hat Fiona Ebner geschrieben: >>>> Am 20.04.23 um 08:55 schrieb Paolo Bonzini: > > Hi > >> Our function is a

Re: QMP (without OOB) function running in thread different from the main thread as part of aio_poll

Am 27.04.23 um 16:56 schrieb Peter Xu: > On Thu, Apr 27, 2023 at 04:36:14PM +0200, Juan Quintela wrote: >> Fiona Ebner wrote: >>> Am 27.04.23 um 13:03 schrieb Kevin Wolf: >>>> Am 26.04.2023 um 16:31 hat Fiona Ebner geschrieben: >>>>> Am 20.04.23 um 08:

Re: QMP (without OOB) function running in thread different from the main thread as part of aio_poll

Am 20.04.23 um 08:55 schrieb Paolo Bonzini: > > > Il gio 20 apr 2023, 08:11 Markus Armbruster > ha scritto: > > So, splicing in a bottom half unmoored monitor commands from the main > loop.  We weren't aware of that, as our commit messages show. > > I

QMP (without OOB) function running in thread different from the main thread as part of aio_poll

Hi, while debugging a completely different issue, I was surprised to see do_qmp_dispatch_bh being run in a vCPU thread. I was under the impression that QMP functions are supposed to be executed in the main thread. Is that wrong? I managed to reproduced the scenario with a build of upstream QEMU

Re: [PULL 19/54] acpi: pc: isa bridge: use AcpiDevAmlIf interface to build ISA device descriptors

of the installation/upgrades? Best Regards, Fiona > > BTW I couldn't reproduce problem as well. > > On Thu, Apr 13, 2023 at 3:10 PM Fiona Ebner wrote: >> >> Am 13.04.23 um 13:46 schrieb Mike Maslenkin: >>> Sorry for the noise, but just curious, how did you shutdo

Re: QMP (without OOB) function running in thread different from the main thread as part of aio_poll

Am 02.05.23 um 12:35 schrieb Juan Quintela: > Fiona Ebner wrote: >> Am 02.05.23 um 12:03 schrieb Fiona Ebner: >>> Am 28.04.23 um 18:54 schrieb Juan Quintela: >>>> Kevin Wolf wrote: >>>>> Am 28.04.2023 um 10:38 hat Juan Quintela geschrieben: >>

Re: QMP (without OOB) function running in thread different from the main thread as part of aio_poll

Am 28.04.23 um 18:54 schrieb Juan Quintela: > Kevin Wolf wrote: >> Am 28.04.2023 um 10:38 hat Juan Quintela geschrieben: >>> Kevin Wolf wrote: > I am perhaps a bit ingenuous here, but it is there a way to convince > qemu that snapshot_save_job_bh *HAS* to run on the main thread?

Re: QMP (without OOB) function running in thread different from the main thread as part of aio_poll

Am 02.05.23 um 12:03 schrieb Fiona Ebner: > Am 28.04.23 um 18:54 schrieb Juan Quintela: >> Kevin Wolf wrote: >>> Am 28.04.2023 um 10:38 hat Juan Quintela geschrieben: >>>> Kevin Wolf wrote: >>>>>> I am perhaps a bit ingenuous her

Re: [PULL 19/54] acpi: pc: isa bridge: use AcpiDevAmlIf interface to build ISA device descriptors

Am 30.03.23 um 10:22 schrieb Igor Mammedov: > On Tue, 28 Mar 2023 14:58:21 +0200 > Fiona Ebner wrote: > >> Am 10.06.22 um 09:57 schrieb Michael S. Tsirkin: >>> From: Igor Mammedov >>> >>> replaces ad-hoc build_isa_devices_aml() with generic AcpiDevAmlIf

Re: [PULL 19/54] acpi: pc: isa bridge: use AcpiDevAmlIf interface to build ISA device descriptors

Am 10.06.22 um 09:57 schrieb Michael S. Tsirkin: > From: Igor Mammedov > > replaces ad-hoc build_isa_devices_aml() with generic AcpiDevAmlIf > way to build bridge AML including all devices that are attached to > its ISA bus. > > Later when PCI is converted to AcpiDevAmlIf,

Re: [PULL 19/54] acpi: pc: isa bridge: use AcpiDevAmlIf interface to build ISA device descriptors

Am 13.04.23 um 13:46 schrieb Mike Maslenkin: > Sorry for the noise, but just curious, how did you shutdown Windows? > Did you use 'shutdown /s' or just press power button? > Could it be that Windows was actually hibernated. > So, when you try to boot it on the new (old) QEMU version with changed >

Re: [PATCH] block/mirror: add 'write-blocking-after-ready' copy mode

Am 02.02.23 um 12:09 schrieb Denis V. Lunev: > On 2/2/23 11:19, Fiona Ebner wrote: >> Am 31.01.23 um 19:18 schrieb Denis V. Lunev: >>> Frankly speaking I do not like this. I'd better would not >>> rely on the enable/disable of the whole bitmap but encode >>>

Re: [PATCH] block/mirror: add 'write-blocking-after-ready' copy mode

Am 02.02.23 um 12:34 schrieb Kevin Wolf: > Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben: >> Am 31.01.23 um 19:18 schrieb Denis V. Lunev: >>> Frankly speaking I would say that this switch could be considered >>> NOT QEMU job and we should just

Lost partition tables on ide-hd + ahci drive

Hi, over the years we've got 1-2 dozen reports[0] about suddenly missing/corrupted MBR/partition tables. The issue seems to be very rare and there was no success in trying to reproduce it yet. I'm asking here in the hope that somebody has seen something similar. The only commonality seems to be

Re: [PATCH] block/mirror: add 'write-blocking-after-ready' copy mode

Am 02.02.23 um 12:34 schrieb Kevin Wolf: > Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben: >> Am 31.01.23 um 19:18 schrieb Denis V. Lunev: >>> Frankly speaking I would say that this switch could be considered >>> NOT QEMU job and we should just

Re: Lost partition tables on ide-hd + ahci drive

Am 14.02.23 um 19:21 schrieb John Snow: > On Thu, Feb 2, 2023 at 7:08 AM Fiona Ebner wrote: >> >> Hi, >> over the years we've got 1-2 dozen reports[0] about suddenly >> missing/corrupted MBR/partition tables. The issue seems to be very rare >> and there was

Re: Lost partition tables on ide-hd + ahci drive

Am 14.06.23 um 16:48 schrieb Simon J. Rowe: > On 02/02/2023 12:08, Fiona Ebner wrote: >> Hi, >> over the years we've got 1-2 dozen reports[0] about suddenly >> missing/corrupted MBR/partition tables. The issue seems to be very rare >> and there was no success in tryi

[PATCH] qemu_cleanup: begin drained section after vm_shutdown()

c:1505 > #1 0x5569810e8f36 in blk_wait_while_drained (blk=0x556982e42880) at > ../block/block-backend.c:1312 > #2 0x5569810e9231 in blk_co_do_pwritev_part (blk=0x556982e42880, > offset=3422961664, bytes=4096, qiov=0x556983028060, qiov_offset=0, flags=0) > at ../block/block-backend.c:140

Re: [PATCH v3] migration: hold the BQL during setup

Ping Am 30.06.23 um 16:18 schrieb Fiona Ebner: > 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_s

strace showing QEMU process doing >99% ppoll

Hi, since a while we have about a dozen people reporting [0] VMs rarely getting stuck with the QEMU process looping and just doing ppoll() and not much else (example strace [1] output and stacktrace [2]). Just wanted to ask if anybody here has seen something similar or ideas what could go wrong?

Re: strace showing QEMU process doing >99% ppoll

Am 10.07.23 um 14:56 schrieb Daniel P. Berrangé: > On Mon, Jul 10, 2023 at 02:34:10PM +0200, Fiona Ebner wrote: > >>> Thread 14 (Thread 0x7efd24d54700 (LWP 1153824) "iou-wrk-50948"): >>> #0 0x in ?? () >>> Backtrace stopped: Cannot acc

Re: [PULL 09/12] migration: Use migration_transferred_bytes() to calculate rate_limit

Am 26.05.23 um 10:55 schrieb Juan Quintela: > Fiona Ebner wrote: >> Am 18.05.23 um 19:13 schrieb Juan Quintela: >>> diff --git a/migration/migration-stats.c b/migration/migration-stats.c >>> index feec7d7369..97759a45f3 100644 >>> --- a/migration/migration-s

Re: [PATCH v2] migration: hold the BQL during setup

Am 26.05.23 um 12:16 schrieb Juan Quintela: > Nak > > Sometimes it works, and sometimes it hangs. Sorry, I originally only ran the tests for x86_64 (native for me). I now ran into the hang too, with qtest-aarch64/migration-test and qtest-i386/migration-test. > Can you take a look? Will do!

Re: [PATCH v2] migration: hold the BQL during setup

Am 26.05.23 um 15:47 schrieb Fiona Ebner: > Am 26.05.23 um 12:16 schrieb Juan Quintela: >> Nak >> >> Sometimes it works, and sometimes it hangs. > > Sorry, I originally only ran the tests for x86_64 (native for me). I now > ran into the hang too, with qtest-aarch64/m

[PATCH] migration: stop tracking ram writes when cancelling background migration

Currently, it is only done when the iteration finishes successfully. Not cleaning up the userfaultfd write protection can lead to symptoms/issues such as the process hanging in memmove or GDB not being able to attach. Signed-off-by: Fiona Ebner --- For the success case, the stuff in between

Re: [PATCH v2 00/20] Next round of migration atomic counters

Am 30.05.23 um 20:39 schrieb Juan Quintela: > Hi > > On this v2: > > - dropped qemu_fflush() assert for read only files (make Richard > happy) > > - Update documentation for qemu_file_transferred (make Fabiano happy) > > - migration/rdma: Remove qemu_fopen_rdma() and make it look like >

[PATCH v2] migration: hold the BQL during setup

introduced by 4987783400 ("migration: fix incorrect memory_global_dirty_log_start outside BQL") and is removed, because it referred to the qemu_mutex_lock_iothread() call. Signed-off-by: Fiona Ebner --- include/migration/register.h | 2 +- migration/block-dirty-bitmap.c | 3 --

Re: [PULL 09/12] migration: Use migration_transferred_bytes() to calculate rate_limit

Am 18.05.23 um 19:13 schrieb Juan Quintela: > diff --git a/migration/migration-stats.c b/migration/migration-stats.c > index feec7d7369..97759a45f3 100644 > --- a/migration/migration-stats.c > +++ b/migration/migration-stats.c > @@ -24,7 +24,9 @@ bool migration_rate_exceeded(QEMUFile *f) >

Re: [PATCH] migration: for snapshots, hold the BQL during setup callbacks

Am 10.05.23 um 08:31 schrieb Juan Quintela: > I am more towards revert completely > 9b0950375277467fd74a9075624477ae43b9bb22 > > and call it a day. On migration we don't use coroutines on the sending > side (I mean the migration code, the block layer uses coroutines for > everything/anything). >

Re: [RFC] migration/block-dirty-bitmap: make loading bitmap for device with iothread future-proof

Am 31.07.23 um 09:35 schrieb Juan Quintela: > Fiona Ebner wrote: >> The bdrv_create_dirty_bitmap() function (which is also called by >> bdrv_dirty_bitmap_create_successor()) uses bdrv_getlength(bs). This is >> a wrapper around a coroutine, and when not called in coroutine

Re: [PATCH v3 1/5] vhost: fix the fd leak

t; Reviewed-by: Raphael Norwitz Tested-by: Fiona Ebner Thank you for the fix! CC-ing stable, because the issue is present since 8.0.0.

Re: [PULL 09/12] migration: Use migration_transferred_bytes() to calculate rate_limit

Am 23.05.23 um 14:31 schrieb Fiona Ebner: > Am 18.05.23 um 19:13 schrieb Juan Quintela: >> diff --git a/migration/migration-stats.c b/migration/migration-stats.c >> index feec7d7369..97759a45f3 100644 >> --- a/migration/migration-stats.c >> +++ b/migration/migratio

[RFC] migration/block-dirty-bitmap: make loading bitmap for device with iothread future-proof

qemu_savevm_state_iterate() will always return 0, meaning the call to iterate will be repeated over and over again without ever reaching the completion phase. Still, this would make the code more robust for the future. Signed-off-by: Fiona Ebner --- We ran into this issue downstream, because we have a custom snapshot

[PATCH v3] migration: hold the BQL during setup

it_bitmaps() was introduced by 4987783400 ("migration: fix incorrect memory_global_dirty_log_start outside BQL") and is removed, because it referred to the qemu_mutex_lock_iothread() call. Signed-off-by: Fiona Ebner --- Changes in v3: * Add unlocked section around multifd_send_sync_ma

[PATCH] migration: for snapshots, hold the BQL during setup callbacks

at the BQL is held during setup. To avoid changing the behavior for migration too, introduce conditionals for the setup callbacks that need the BQL and only take the lock if it's not already held. Signed-off-by: Fiona Ebner --- include/migration/register.h | 2 +- migration/block-dirty-bit

Question about issue #1576: Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails

Hi, I'm trying to fix issue #1576 [0], but having a bit of a hard time. The issue was introduced by commit 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") and the migration error is: > qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 > device: 0

Re: [PATCH v1 1/1] hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0

the register is not set and when 8.0 sends a nonzero value for the register, the error condition in get_pci_config_device() will trigger again. Is it necessary to also handle that? Maybe by special casing the error condition in get_pci_config_device() to be prepared to accept such a stream from 8.0? If that is considered not worth it, consider this: Tested-by: Fiona Ebner Best Regards, Fiona

Re: [PATCH v3 3/3] migration/doc: We broke backwards compatibility

Am 15.05.23 um 10:32 schrieb Juan Quintela: > When we detect that we have broken backwards compantibility in a compatibility (...) > + > +In qemu-8.0 we got this commit: :: > + > +commit 9a6ef182c03eaa138bae553f0fbb5a123bef9a53 > +Author: Jonathan Cameron > +Date: Thu Mar 2

Question about graph locking preconditions regarding qemu_in_main_thread()

Hi, I noticed that the bdrv_graph_co_rd_lock() and bdrv_graph_co_rd_unlock() functions use qemu_in_main_thread() as a conditional to return early. What high-level requirements ensure that qemu_in_main_thread() will evaluate to the same value during locking and unlocking? This paragraph assumes no

Re: Question about graph locking preconditions regarding qemu_in_main_thread()

Am 08.05.23 um 12:40 schrieb Kevin Wolf: > Am 05.05.2023 um 11:35 hat Fiona Ebner geschrieben: >> Hi, >> I noticed that the bdrv_graph_co_rd_lock() and bdrv_graph_co_rd_unlock() >> functions use qemu_in_main_thread() as a conditional to return early. >> What hig

Re: Question about graph locking preconditions regarding qemu_in_main_thread()

Am 09.05.23 um 15:53 schrieb Kevin Wolf: > Am 09.05.2023 um 12:26 hat Fiona Ebner geschrieben: >> Am 08.05.23 um 12:40 schrieb Kevin Wolf: >>> Am 05.05.2023 um 11:35 hat Fiona Ebner geschrieben: >>>> Hi, >>>> I noticed that the bdrv_graph_co_rd_lock() an

[PATCH v3 2/2] ui/clipboard: add asserts for update and request

Should an issue like CVE-2023-6683 ever appear again in the future, it will be more obvious which assumption was violated. Suggested-by: Marc-André Lureau Signed-off-by: Fiona Ebner --- Changes in v3: * Turn check for update into an assertion. * Split out into a separate patch. ui

[PATCH v3 1/2] ui/clipboard: mark type as not available when there is no data

e 0 differently. In particular, mark in the clipboard info that the type is not available. While at it, switch to g_memdup2(), because g_memdup() is deprecated. Cc: qemu-sta...@nongnu.org Fixes: CVE-2023-6683 Reported-by: Markus Frank Suggested-by: Marc-André Lureau Signed-off-by: Fiona Eb

Re: [PATCH v2 3/4] qapi: blockdev-backup: add discard-source parameter

Am 17.01.24 um 17:07 schrieb Vladimir Sementsov-Ogievskiy: > Add a parameter that enables discard-after-copy. That is mostly useful > in "push backup with fleecing" scheme, when source is snapshot-access > format driver node, based on copy-before-write filter snapshot-access > API: > > [guest]

Re: double free or corruption (out) in iscsi virtual machine

Am 17.01.24 um 08:23 schrieb M_O_Bz: > Basic Info: > 1. Issue: I got a " double free or corruption (out)", head for > attachment debug.log for details, the debug.log print the backtrace of > one virtual machine > 2. Reproduce: currently I cann't destribe how to reproduce this bug, > because it's

[PATCH] iotests: adapt to output change for recently introduced 'detached header' field

Failure was noticed when running the tests for the qcow2 image format. Fixes: 0bd779e27e ("crypto: Introduce 'detached-header' field in QCryptoBlockInfoLUKS") Signed-off-by: Fiona Ebner --- tests/qemu-iotests/198.out | 2 ++ tests/qemu-iotests/206.out | 1 + 2 files changed, 3

[RFC 3/4] mirror: move some checks to qmp

] Signed-off-by: Fiona Ebner --- block/mirror.c | 28 +--- blockdev.c | 29 + 2 files changed, 34 insertions(+), 23 deletions(-) diff --git a/block/mirror.c b/block/mirror.c index 84155b1f78..15d1c060eb 100644 --- a/block/mirror.c +++ b/block

[RFC 4/4] iotests: add test for bitmap mirror

vm.command -> vm.cmd, specifying explicit image format for rebase, adapt to new behavior of qemu_img(), dropping of 'status' field in output, etc. rename test from '384' to 'bitmap-sync-mirror'] Signed-off-by: Fiona Ebner --- tests/qemu-iotests/tests/bitmap-sync-mirror |

[RFC 0/4] mirror: implement incremental and bitmap modes

Previous discussion from when this was sent upstream [0] (it's been a while). I rebased the patches and re-ordered and squashed like suggested back then [1]. This implements two new mirror modes: - bitmap mirror mode with always/on-success/never bitmap sync mode - incremental mirror mode as

[RFC 1/4] drive-mirror: add support for sync=bitmap mode=never

mprecht [FE: rebase for 9.0 update version and formatting in QAPI] Signed-off-by: Fiona Ebner --- block/mirror.c | 96 -- blockdev.c | 38 +- include/block/block_int-global-state.h | 4 +- qapi/block-core.json

[RFC 2/4] drive-mirror: add support for conditional and always bitmap sync modes

-by: Fiona Ebner --- The original patch this was based on came from a WIP git branch and thus has no Signed-off-by trailer from John, see [0]. I added an Originally-by trailer for now. Let me know if I should drop that and wait for John's Signed-off-by instead. [0] https://lore.kernel.org/qemu

Re: [RFC 1/4] drive-mirror: add support for sync=bitmap mode=never

Am 21.02.24 um 07:55 schrieb Markus Armbruster: >> diff --git a/qapi/block-core.json b/qapi/block-core.json >> index ab5a93a966..ac05483958 100644 >> --- a/qapi/block-core.json >> +++ b/qapi/block-core.json >> @@ -2181,6 +2181,15 @@ >> # destination (all the disk, only the sectors allocated

[PATCH v2] qemu_init: increase NOFILE soft limit on POSIX

gzilla.proxmox.com/show_bug.cgi?id=4507 Signed-off-by: Fiona Ebner --- Changes in v2: * avoid the redundant setrlimit call when cur == max include/sysemu/os-posix.h | 1 + include/sysemu/os-win32.h | 5 + os-posix.c| 22 ++ system/vl.c | 2 ++ 4

Re: [RFC 0/3] aio-posix: call ->poll_end() when removing AioHandler

Am 14.12.23 um 20:53 schrieb Stefan Hajnoczi: > > I will still try the other approach that Hanna and Paolo have suggested. > It seems more palatable. I will send a v2. > FYI, what I already tried downstream (for VirtIO SCSI): > diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c > index

Re: [RFC 0/3] aio-posix: call ->poll_end() when removing AioHandler

Am 18.12.23 um 15:49 schrieb Paolo Bonzini: > On Mon, Dec 18, 2023 at 1:41 PM Fiona Ebner wrote: >> I think it's because of nested drains, because when additionally >> checking that the drain count is zero and only executing the loop then, >> that issue doesn't seem to ma

Re: [RFC 0/3] aio-posix: call ->poll_end() when removing AioHandler

Am 13.12.23 um 22:15 schrieb Stefan Hajnoczi: > But there you have it. Please let me know what you think and try your > reproducers to see if this fixes the missing io_poll_end() issue. Thanks! > Thanks to you! I applied the RFC (and the series it depends on) on top of 8.2.0-rc4 and this fixes

[PATCH] qemu_init: increase NOFILE soft limit on POSIX

OK with working with file > descriptors above 1023, Buglink: https://bugzilla.proxmox.com/show_bug.cgi?id=4507 Signed-off-by: Fiona Ebner --- include/sysemu/os-posix.h | 1 + include/sysemu/os-win32.h | 5 + os-posix.c| 18 ++ system/vl.c | 2 ++ 4

Re: [PULL 29/32] virtio-blk: implement BlockDevOps->drained_begin()

Am 08.12.23 um 09:32 schrieb Kevin Wolf: > > I'm not involved in it myself, but the kind of theme reminds me of this > downstream bug that Hanna analysed recently: > > https://issues.redhat.com/browse/RHEL-3934 > > Does it look like the same root cause to you? > Thank you for the reference!

Re: [RFC 0/3] aio-posix: call ->poll_end() when removing AioHandler

Am 02.01.24 um 16:24 schrieb Hanna Czenczek: > > I’ve attached the preliminary patch that I didn’t get to send (or test > much) last year.  Not sure if it has the same CPU-usage-spike issue > Fiona was seeing, the only functional difference is that I notify the vq > after attaching the notifiers

Re: [RFC 0/3] aio-posix: call ->poll_end() when removing AioHandler

Am 03.01.24 um 14:35 schrieb Paolo Bonzini: > On 1/3/24 12:40, Fiona Ebner wrote: >> I'm happy to report that I cannot reproduce the CPU-usage-spike issue >> with the patch, but I did run into an assertion failure when trying to >> verify that it fixes my original stuck-gues

Re: [RFC 0/3] aio-posix: call ->poll_end() when removing AioHandler

Am 05.01.24 um 14:43 schrieb Fiona Ebner: > Am 03.01.24 um 14:35 schrieb Paolo Bonzini: >> On 1/3/24 12:40, Fiona Ebner wrote: >>> I'm happy to report that I cannot reproduce the CPU-usage-spike issue >>> with the patch, but I did run into an assertion failur

Re: [PATCH] ui/clipboard: avoid crash upon request when clipboard peer is not initialized

Am 12.01.24 um 14:55 schrieb Fiona Ebner: > > Then when noVNC sends a VNC_MSG_CLIENT_CUT_TEXT message (it did set > the feature correctly, so the check added by your patch passes), Sorry, forgot to adapt this part. This should read "it did set the VNC_FEATURE_CLIPBOARD_EXT feature

[PATCH] ui/clipboard: avoid crash upon request when clipboard peer is not initialized

original segfault still happens. Fixes: CVE-2023-6683 Reported-by: Markus Frank Signed-off-by: Fiona Ebner Tested-by: Markus Frank --- This is just a minimal fix. Happy to add some warning/error to not hide the issue with the missing initialization completely and/or go for a different

Re: [PATCH] ui/clipboard: avoid crash upon request when clipboard peer is not initialized

Am 14.01.24 um 14:51 schrieb Marc-André Lureau: >> >> diff --git a/ui/clipboard.c b/ui/clipboard.c >> index 3d14bffaf8..c13b54d2e9 100644 >> --- a/ui/clipboard.c >> +++ b/ui/clipboard.c >> @@ -129,7 +129,8 @@ void qemu_clipboard_request(QemuClipboardInfo *info, >> if (info->types[type].data

Re: [PATCH] ui/clipboard: avoid crash upon request when clipboard peer is not initialized

Am 15.01.24 um 12:15 schrieb Marc-André Lureau: > Hi > > On Mon, Jan 15, 2024 at 2:45 PM Fiona Ebner wrote: >> >> Am 14.01.24 um 14:51 schrieb Marc-André Lureau: >>>> >>>> diff --git a/ui/clipboard.c b/ui/clipboard.c >>>> index 3d14bffaf

Re: [PATCH] ui/clipboard: avoid crash upon request when clipboard peer is not initialized

Am 15.01.24 um 12:33 schrieb Marc-André Lureau: > Hi > > On Mon, Jan 15, 2024 at 3:26 PM Fiona Ebner wrote: >> >> Am 15.01.24 um 12:15 schrieb Marc-André Lureau: >>> Hi >>> >>> On Mon, Jan 15, 2024 at 2:45 PM Fiona Ebner wrote: >>

[PATCH] block/io: clear BDRV_BLOCK_RECURSE flag after recursing in bdrv_co_block_status

ot;, "node-name": "node3" } } > {"execute": "blockdev-add", "arguments": { "driver": "snapshot-access", > "file": "node3", "node-name": "snap0" } } > {"execute": "b

Re: [PATCH] ui/clipboard: avoid crash upon request when clipboard peer is not initialized

Am 15.01.24 um 13:00 schrieb Marc-André Lureau: >>> >>> The trouble is when qemu_clipboard_update() is called without data & >>> without a request callback set. We shouldn't allow that as we have no >>> means to get the clipboard data then. >>> >> >> In the above scenario, I'm pretty sure

[PATCH v2] ui/clipboard: ensure data is available or request callback is set upon update

a similar issue appear in the future. Fixes: CVE-2023-6683 Reported-by: Markus Frank Suggested-by: Marc-André Lureau Signed-off-by: Fiona Ebner --- Changes in v2: * Different approach as suggested by Marc-André: Instead of quietly returning in qemu_clipboard_request() when no

<    1   2   3   >