Hi,
On Tue, 23 Jul 2024 at 10:33, Prasad Pandit wrote:
> On Sun, 21 Jul 2024 at 01:11, Michael S. Tsirkin wrote:
> > > > > On Wed, Jul 17, 2024 at 04:55:52AM -0400, Michael S. Tsirkin wrote:
> > > > > > I just want to understand how we managed to have two thr
On Sun, 21 Jul 2024 at 01:11, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 17, 2024 at 04:55:52AM -0400, Michael S. Tsirkin wrote:
> > > > > I just want to understand how we managed to have two threads
> > > > > talking in parallel. BQL is normally enough, which path
> > > > > manages to invoke
On Sun, 21 Jul 2024 at 01:11, Michael S. Tsirkin wrote:
> So it's not a rw lock. It's just a mutex.
> Lock should be named after what they protect, not
> after where they are held.
> In this case, this ensures only 1 request is
> outstanding at a time.
> So vhost_user_request_reply_lock
Okay,
On Mon, 15 Jul 2024 at 18:57, Peter Xu wrote:
> I think it shouldn't be a major deal in most cases, if the extended cycles
> only cover a bunch of instructions. In special case we can still use
> WITH_QEMU_LOCK_GUARD, but I'd start with the simple first and only switch
> if necessary.
* Okay,
Hello Peter,
On Mon, 15 Jul 2024 at 19:10, Peter Xu wrote:
> IMHO it's better we debug and fix all the issues before merging this one,
> otherwise we may overlook something.
* Well we don't know where the issue is, not sure where the fix may go
in, ex. if the issue turns out to be how virsh(1)
On Thu, 11 Jul 2024 at 20:11, Michael S. Tsirkin wrote:
> Could you supply a Fixes tag here? What commit introduced the race?
'postcopy_end' message was added by:
->
https://github.com/qemu/qemu/commit/46343570c06e63b4499f619011df80f91349cd49
Not sure if its race condition also began with
On Thu, 11 Jul 2024 at 21:08, Peter Xu wrote:
> Hmm, I thought it was one of the vcpu threads that invoked
> vhost_dev_start(), rather than any migration thread?
[QEMU=vhost-user-front-end] <===> [QEMU=vhost-user-front-end]
^
On Thu, 11 Jul 2024 at 21:12, Peter Xu wrote:
> I apologize if I suggested WITH_QEMU_LOCK_GUARD when we talked.. I don't
> remember which one I suggested, but in this case IIUC it'll be much easier
> to review if you use the other sister function QEMU_LOCK_GUARD()
> instead.. That should make the
From: Prasad Pandit
While starting a vhost device, updating iotlb entries
via 'vhost_device_iotlb_miss' may return an error.
qemu-kvm: vhost_device_iotlb_miss:
700871,700871: Fail to update device iotlb
Fail device start when such an error occurs.
Signed-off-by: Prasad Pandit
---
hw
From: Prasad Pandit
QEMU threads use vhost_user_write/read calls to send
and receive messages from a vhost-user device. When multiple
threads communicate with the same vhost-user device, they can
receive each other's messages, resulting in an erroneous state.
vhost_user_read_header
From: Prasad Pandit
Hello,
* virsh(1) offers multiple options to initiate Postcopy migration:
1) virsh migrate --postcopy --postcopy-after-precopy
2) virsh migrate --postcopy + virsh migrate-postcopy
3) virsh migrate --postcopy --timeout --timeout-postcopy
When Postcopy migration
On Thu, 30 May 2024 at 13:17, Nicholas Piggin wrote:
>
> Reviewed-by: Thomas Huth
> Signed-off-by: Nicholas Piggin
> ---
* No commit log message?
---
- Prasad
controller not being migrated or
> + * reconstructed post-migration. Disable it until the problem is
> resolved.
> */
> if (g_str_equal(arch, "s390x") && !has_kvm) {
> g_test_message("Skipping tests: s390x host with KVM is required");
> --
> 2.43.0
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
e the 'tmpfs' variable needs to be renamed to indicate that it
uses '/tmp/' or '/var/tmp' directory to create temporary files. And it
is not in memory tmpfs(5) used for shared memory '/dev/shm'. Commit
message above says 'tmpfs mount is too small' and above calls continue
to use 'tmpfs' variable to create te
t;enable for TCG" indeed.
>
Ack with commit message changes:
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
Hi,
On Sat, 25 May 2024 at 18:44, Nicholas Piggin wrote:
> s390x is more stable now. Enable it.
>
> Signed-off-by: Nicholas Piggin
> ---
> tests/qtest/migration-test.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/tests/qtest/migration-test.c
Hi,
On Fri, 24 May 2024 at 16:23, Yong Huang wrote:
> I'm not testing the latest QEMU version while theoretically it is
> reproducible, I'll check it and give a conclusion.
* Yes, that'll help. Thank you.
> I'm not sure this usage is common but in our production environment, it is
> used.
*
On Fri, 24 May 2024 at 18:00, Fabiano Rosas wrote:
> That's the point. If offset==0 we truncate all the way, if not, we truncate
> to the offset.
* Yes, I was wondering if the migration file has some data, but still
'offset' ends up being zero(0). If that's unlikely to happen, then we
are good.
object_unref(OBJECT(fioc));
> +return;
> +}
> +
* Should 'offset' be checked for > zero while ftruncating? Else it'll
be same as O_TRUNC. Otherwise it looks fine.
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
Hello Hyman,
* Is this the same patch series as sent before..?
-> https://lists.nongnu.org/archive/html/qemu-devel/2024-04/msg00816.html
On Fri, 24 May 2024 at 12:02, Hyman Huang wrote:
> For VMs configured with the USB CDROM device:
>
> -drive
From: Prasad Pandit
Libaio defines IO_CMD_FDSYNC command to sync all outstanding
asynchronous I/O operations, by flushing out file data to the
disk storage. Enable linux-aio to submit such aio request.
When using aio=native without fdsync() support, QEMU creates
pthreads, and destroying
On Wednesday, 24 April, 2024 at 03:36:01 pm IST, Philippe Mathieu-Daudé wrote:
>On 1/6/23 05:18, Akihiko Odaki wrote:
>> Recently MemReentrancyGuard was added to DeviceState to record that the
>> device is engaging in I/O. The network device backend needs to update it
>> when delivering a packet
Hello,
On Mon, 18 Mar 2024 at 13:23, Zhao Liu wrote:
> Indeed, as you say, these items are initialized to 0 by default.
>
> I think, however, that the initialization is so far away from where the
> smp is currently parsed that one can't easily confirm it (thanks for
> your confirmation!).
>
>
From: Prasad Pandit
Rearrange BRDVRawState structure fields to avoid memory
fragments in its object's memory and save some(~8) bytes
per object.
Signed-off-by: Prasad Pandit
---
block/file-posix.c | 39 +++
1 file changed, 19 insertions(+), 20 deletions
From: Prasad Pandit
Libaio defines IO_CMD_FDSYNC command to sync all outstanding
asynchronous I/O operations, by flushing out file data to the
disk storage.
Enable linux-aio to submit such aio request. This helps to
reduce latency induced via pthread_create calls by
thread-pool (aio=threads
On Wed, 13 Mar 2024 at 20:48, Stefan Hajnoczi wrote:
> > +extern bool laio_has_fdsync(int);
> Please declare this in include/block/raw-aio.h alongside the other laio APIs.
>
> FDSYNC support should be probed at open() time and the result should be
> stored in a new bool field like
Hello Zhao,
> (Communicating with you also helped me to understand the QAPI related parts.)
* I'm also visiting QAPI code parts for the first time. Thanks to you. :)
On Mon, 11 Mar 2024 at 10:36, Zhao Liu wrote:
> SMPConfiguration is created and set in machine_set_smp().
> Firstly, it is
From: Prasad Pandit
Libaio defines IO_CMD_FDSYNC command to sync all outstanding
asynchronous I/O operations, by flushing out file data to the
disk storage.
Enable linux-aio to submit such aio request. This helps to
reduce latency induced via pthread_create calls by
thread-pool (aio=threads
Hello,
On Tue, 12 Mar 2024 at 15:15, Kevin Wolf wrote:
> Am 11.03.2024 um 20:36 hat Stefan Hajnoczi geschrieben:
> > > > That can be avoided with a variable that keeps track of whether -EINVAL
> > > > was seen before and skips Linux AIO in that
> > > > case.
> > > >
> > > > Fallback should be
Hello Kevin,
On Fri, 8 Mar 2024 at 17:38, Prasad Pandit wrote:
> I'm trying to test it against the Fedora-26 kernel, which was < 4.13.0, and
> did not support the AIO_FDSYNC call.
[PATCH v2] ->
https://lists.nongnu.org/archive/html/qemu-devel/2024-03/msg02495.html
*
From: Prasad Pandit
Libaio defines IO_CMD_FDSYNC command to sync all outstanding
asynchronous I/O operations, by flushing out file data to the
disk storage.
Enable linux-aio to submit such aio request. This helps to
reduce latency induced via pthread_create calls by
thread-pool (aio=threads
Hi,
On Fri, 8 Mar 2024 at 20:50, Zhao Liu wrote:
> On Fri, Mar 08, 2024 at 02:20:45PM +0100, Thomas Huth wrote:
> > Can we always rely on that? ... or is this just by luck due to the current
> > implementation? In the latter case, I'd maybe rather drop this patch again.
>
> Thanks for the
Hello Kevin,
On Fri, 8 Mar 2024 at 14:35, Kevin Wolf wrote:
> Hm... This might make it more challenging because then not only one
> specific request fails, but the whole submission batch.
* Yes exactly.
* I've updated yesterday's patch to return an error (-EINVAL) from
ioq_submit to
Hi,
On Thu, 7 Mar 2024 at 19:21, Kevin Wolf wrote:
> Kernel support for this is "relatively" new, added in 2018. Should we
> fall back to the thread pool if we receive -EINVAL?
laio_co_submit
laio_do_submit
ioq_submit
io_submit
* When an aio operation is not supported by the
From: Prasad Pandit
Libaio defines IO_CMD_FDSYNC command to sync all outstanding
asynchronous I/O operations, by flushing out file data to the
disk storage.
Enable linux-aio to submit such aio request. This helps to
reduce latency induced via pthread_create calls by
thread-pool (aio=threads
most difficult skill to master. :))
* If you plan to send a separate patch for above refactoring, then I'd
add Reviewed-by for this one.
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
Hi,
On Tue, 5 Mar 2024 at 12:59, Zhao Liu wrote:
> After simple test, if user sets maxcpus as 0, the has_maxcpus will be
> true as well...I think it's related with QAPI code generation logic.
* Right.
[Maybe we digressed a bit in the discussion, so I snipped much of the
details here. Sorry
Error *local_err = NULL;
> SaveStateEntry *se;
>
> if (!migration_in_colo_state()) {
> @@ -1776,8 +1780,10 @@ int qemu_save_device_state(QEMUFile *f)
> if (se->is_ram) {
> continue;
> }
> -ret = vmstate_save(f, se, NULL);
> +ret = vmstate_save(f, se, NULL, _err);
> if (ret) {
> +migrate_set_error(ms, local_err);
> +error_report_err(local_err);
> return ret;
> }
> }
> --
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
On Mon, 4 Mar 2024 at 18:01, Cédric Le Goater wrote:
> This will prepare ground for futur changes adding an Error** argument
* futur -> future
> +ret = qemu_fflush(f);
> +if (ret) {
* if (ret) -> if (ret < 0)
Thank you.
---
- Prasad
rn ret;
> }
>
> Then cap is updated with host cap value tmp_cap. This update only happen
> before machine creation done.
* After iommufd_device_get_info() ret is != 0. So s->cap won't be
updated then. Hope that is intended.
* With the above tweaks included:
Reviewed-by: Prasad Pandit
Thank you.
---
- Prasad
Hello Zhao,
On Mon, 4 Mar 2024 at 12:19, Zhao Liu wrote:
> > unsigned maxcpus = config->has_maxcpus ? config->maxcpus : 0;
>
> This indicates the default maxcpus is initialized as 0 if user doesn't
> specifies it.
* 'has_maxcpus' should be set only if maxcpus > 0. If maxcpus == 0,
then setting
On Wed, 28 Feb 2024 at 15:17, Zhenzhong Duan wrote:
> When there is VFIO device and vIOMMU cap/ecap is updated based on host
* cap/ecap -> capability/extended capability registers are updated ...
> IOMMU cap/ecap, migration should be blocked.
* It'll help to mention why migration should be
On Mon, 4 Mar 2024 at 10:02, Zhao Liu wrote:
> diff --git a/hw/core/machine-smp.c b/hw/core/machine-smp.c
> index 25019c91ee36..96533886b14e 100644
> --- a/hw/core/machine-smp.c
> +++ b/hw/core/machine-smp.c
> @@ -105,8 +105,9 @@ void machine_parse_smp_config(MachineState *ms,
>
On Mon, 4 Mar 2024 at 06:00, Peter Xu wrote:
> Yes I think you're looking at the right path, it's just that the relevant
> patches haven't yet landed upstream but is planned. I normally use
> "Based-on" tag for such patch that has a dependency outside master, like:
>
> Based-on:
Hello Petr,
On Fri, 1 Mar 2024 at 14:46, wrote:
> + * An explicitly close() on the channel here is normally not
explicitly -> explicit
> + * required, but can be helpful for "file:" iochannels, where it
> + * will include an fdatasync() to make sure the data is flushed
Hello Peter, all
On Thu, 25 May 2023 at 18:33, Peter Xu wrote:
> IIRC this bug used to only reproduce on rt kernels, is it still the case?
>
* Yes, it's a same crash.
> Here besides doing correct unregister, does it also mean that even if
> event_notifier_init() failed there's totally no
46 matches
Mail list logo
