On Fri, Aug 16, 2024 at 11:13:20AM -0400, Steven Sistare wrote:
> On 8/15/2024 4:58 PM, Peter Xu wrote:
> > On Sun, Jun 30, 2024 at 12:44:03PM -0700, Steve Sistare wrote:
> > > Define functions to put/get file descriptors to/from a QEMUFile, for qio
> > > channels that support SCM_RIGHTS. Maintain ordering such that
> > > put(A), put(fd), put(B)
> > > followed by
> > > get(A), get(fd), get(B)
> > > always succeeds. Other get orderings may succeed but are not guaranteed.
> > >
> > > Signed-off-by: Steve Sistare <steven.sist...@oracle.com>
> >
> > It's a slight pity that we'll extend fd to qemufiles, rather than changing
> > qemufiles back to iochannels.. for the long term we want to remove qemufile.
>
> Thanks, I did not know that removing QEMUFile is a goal.
>
> Currently QEMUFile buffers I/O in userland to reduce system calls. Do you
> plan to eliminate that buffering, or move it to QIOChannel, perhaps in a
> new QIOChannelBuffered class?
>
> If you eliminate the buffering, then migration might take longer.
> If you keep the buffering, then this patch's logic will still be needed
> in the QIOChannelBuffered code.
+Dan.
Yes probably the buffering is still needed ultimately. It's just that it
currently involves qemufile which is (hopefully..) destined to be either
removed or updated.
For this cpr states, I'm not sure the buffered iochannel is a must, e.g. I
wonder what happens if we start with using iochannels directly without
buffering, then after replacing that with buffered iochannels, it'll simply
improve on top without changing much of the code - I mean, buffered
iochannel should still be able to be casted into an iochannel anyway.
>
> > Would you think we can start to introduce iochannel-compatible vmstate
> > loader from cpr-[exec/transfer] here? The idea is that we'd want
> > vmstate_load_iochannel() then take that from an iochannel and start getting
> > rid of qemufile API. It'll already bring two benefits:
> >
> > - We don't need this patch then I assume, but stick with iochannel API
> >
> > - We can have Error** as last parameter of vmstate_load_iochannel(), then
> > as we discussed in the other thread cpr_state_load() can fail with
> > explicit errors without error_report()s (and as you pointed out, the
> > load side of Error** support is yet missing)
> >
> > There's a 3rd potential benefit, and will come to play when we want to
> > allow multifd threads to load device states / VMSDs at some point, as
> > multifd doesn't maintain qemufiles, but only iochannels.
> >
> > I'm not sure whether it adds too much to you yet, but I'm curious how you
> > think about it.
>
> A decent idea, but the task quickly mushrooms. All of the VMSTATE macros used
> in cpr.c would need to be converted, and that stack is deep. eg:
>
> VMSTATE_INT32
> vmstate_info_int32
> put_int32
> qemu_put_sbe32s
> qemu_put_byte
> add_buf_to_iovec
> qemu_fflush
> qio_channel_writev_all
Right, right after I sent the email I noticed this too..
The chance is the new iochannel API only resolves whatever needed for cpr
early states, currently:
static const VMStateDescription vmstate_cpr_state = {
.name = CPR_STATE,
.version_id = 1,
.minimum_version_id = 1,
.pre_save = cpr_state_presave,
.fields = (VMStateField[]) {
VMSTATE_UINT32(mode, CprState),
VMSTATE_QLIST_V(fds, CprState, 1, vmstate_cpr_fd, CprFd, next),
VMSTATE_END_OF_LIST()
}
};
static const VMStateDescription vmstate_cpr_fd = {
.name = "cpr fd",
.version_id = 1,
.minimum_version_id = 1,
.fields = (VMStateField[]) {
VMSTATE_UINT32(namelen, CprFd),
VMSTATE_VBUFFER_ALLOC_UINT32(name, CprFd, 0, NULL, namelen),
VMSTATE_INT32(id, CprFd),
VMSTATE_FD(fd, CprFd),
VMSTATE_END_OF_LIST()
}
};
IIUC, a summary of a few things only so far: UINT32/INT32, VBUFFER, FD.
Here FD is the new one, which we'll need to support that anyway, either
with the qemufile API or iochannel API. Then the rest looks pretty
limited. IOW, the new iochannel-based vmstate_load() doesn't yet need to
know anything else but these types of fields. While I don't think I have a
full grasp yet on everything; that just sounds like the right direction to
go for the longer term.
Said that, as you said there can still be plenty of work there. Steve,
feel free to think about it and take whatever approach you like.
Thanks,
--
Peter Xu
