On 1/29/26 22:18, Avihai Horon wrote:
On 1/29/2026 4:31 PM, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
On 1/29/26 06:11, Avihai Horon wrote:
On 1/28/2026 7:38 PM, Peter Xu wrote:
External email: Use caution opening links or attachments
On Wed, Jan 28, 2026 at 07:13:43PM +0200, Avihai Horon wrote:
In our case we only use the PRE_COPY_P2P prepare event. The prepare events
for the other states are ignored.
For re-enabling the timeout mechanism we indeed use the "regular" (not
prepare) events.
However, this new event can be used by anyone for any purpose, so I didn't
want to limit it only for my use case.
I see your point.
Said that, in this specific case, my worry is nobody will consume the rest
events, and then after a few years nobody can even tell why it ever
existed. Then QEMU needs to emits some never-used events forever, worrying
about breaking anyone, even if in reality they're always ignored.
Personally I think it makes more sense to add one explicit message as you
explicitly need. Then, that message can be as generic as possible on its
own. But I'll leave that to you and VFIO maintainers to decide.
So you suggest adding the prepare event only for the PRE_COPY_P2P state (which
is used in my use case)?
Cedric, any opinion from your side?
I agree with Peter. Let's not over specify the feature for the first
use case. Let's keep it simple and well documented.
It is not a problem if the mgmt layer is not libvirt. Diversity is a
good thing anyway. Just mention it.
Let's see v2.
Sure.
So I'm planning to send v2 that only adds a new PRE_COPY_P2P_PREPARE state to
the existing event.
Please tell me if you had something else in mind.
That's fine.
Thanks,
C.
