On Thu, 2020-12-31 at 11:46 +0800, Jason Wang wrote:
> On 2020/12/29 下午6:02, Elena Afanasova wrote:
> > Signed-off-by: Elena Afanasova<eafanasova@xxxxxxxxx>
> > ---
> > virt/kvm/ioregion.c | 157
> > ++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 157 insertions(+)
> >
> > diff --git a/virt/kvm/ioregion.c b/virt/kvm/ioregion.c
> > index a200c3761343..8523f4126337 100644
> > --- a/virt/kvm/ioregion.c
> > +++ b/virt/kvm/ioregion.c
> > @@ -4,6 +4,33 @@
> > #include <kvm/iodev.h>
> > #include "eventfd.h"
> >
> > +/* Wire protocol */
> > +struct ioregionfd_cmd {
> > + __u32 info;
> > + __u32 padding;
> > + __u64 user_data;
> > + __u64 offset;
> > + __u64 data;
> > +};
> > +
>
> I wonder do we need a seq in the protocol. It might be useful if we
> allow a pair of file descriptors to be used for multiple different
> ranges.
>
I think it might be helpful in the case of out-of-order requests.
In the case of in order requests seq field seems not to be necessary
since there will be cmds/replies serialization. I’ll include the
synchronization code in a RFC v2 series.
> Thanks
>
>
> > +struct ioregionfd_resp {
> > + __u64 data;
> > + __u8 pad[24];
> > +};
