; > linux-aio: explain why max batch is checked in laio_io_unplug()
> >
> > block/linux-aio.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > --
> > 2.36.1
> >
>
> Thanks, applied to my block tree:
> https://gitlab.com/stefanha/qemu/commits/block
>
> Stefan
>
--
Mark Mielke
: Configure all host notifiers in a
single MR transaction")
Signed-off-by: Mark Mielke
---
hw/block/dataplane/virtio-blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
index 252c3a7a23..ee5a5352dc 1
Sorry... I missed copy maintainers and qemu-stable. This should be
considered a regression.
-- Forwarded message -
From: Mark Mielke
Date: Thu, Dec 2, 2021 at 11:26 AM
Subject: [PATCH] virtio-blk: Fix clean up of host notifiers for single
MR transaction.
To:
The code
On Fri, Jan 18, 2019 at 10:25 AM Paolo Bonzini wrote:
> On 18/01/19 14:41, Mark Mielke wrote:
> > It is useful to understand the risk. However, this is the same risk we
> > have been successfully living with for several years now, and it seems
> > abrupt to declare 3.
nt.
I'm totally fine with the understanding that any machine not restarted is
still broken under Qemu 3.2, just as it was broken under Qemu 2.12. New
machines will be correct, and the broken machines can be fixed
opportunistically and in discussion with the users.
And, we don't need a system-wide restart of the whole cluster to deploy
Qemu 3.2.
--
Mark Mielke
or if it should be left alone entirely and never used as the
lowest risk option (and what we have traditionally been doing anyways).
I do appreciate the warnings and details. Just not the enforcement piece.
Thanks!
--
Mark Mielke
tion has
been used before.
I'm concerned I will end up with a requirement for *all* guests to be
restarted in order to migrate them to the new hosts, rather than just the
ones that would have a problem.
Thoughts?
Thanks!
--
Mark Mielke
