On May 2, 2016 09:40, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>> On 02.05.16 at 17:35, <tamas@tklengyel.com> wrote:
> > On May 2, 2016 07:12, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>
> >> >>> On 29.04.16 at 20:07, <tamas@tklengyel.com> wrote:
> >> > @@ -229,8 +231,15 @@ struct vm_event_write_ctrlreg {
> >> >      uint64_t old_value;
> >> >  };
> >> >
> >> > +struct vm_event_singlestep {
> >> > +    uint64_t gfn;
> >> > +};
> >> > +
> >> >  struct vm_event_debug {
> >> >      uint64_t gfn;
> >> > +    uint8_t type;        /* HVMOP_TRAP_* */
> >> > +    uint8_t insn_length;
> >> > +    uint8_t _pad[6];
> >> >  };
> >>
> >> This being an incompatible change - didn't you mean to increment some
> >> version number?
> >
> > I'm not sure. It would still work with clients compiled with the older
> > version of the header as the layout of the debug struct didnt change,
was
> > just appended. The size of the request/response struct didn't change
either
> > so technically this would still be backwards compatible.
>
> But you also need to consider the other direction: Code compiled
> against the new variant, but running on an older hypervisor would
> expect the new fields to be valid, yet they can't be, and the caller
> has no way to know.

Fair point, will incrementnthe version.

Thanks!
Tamas