On Mon, 2021-01-04 at 13:37 +0800, Jason Wang wrote:
> On 2021/1/4 上午4:37, Elena Afanasova wrote:
> > 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.
>
> See my reply to V1. It might be helpful for the case of using single
> ioregionfd for multiple ranges.
>
Ok, thank you!
> Thanks
>
>
> > > Thanks
> > >
> > >
> > > > +struct ioregionfd_resp {
> > > > + __u64 data;
> > > > + __u8 pad[24];
> > > > +};
