On May 2, 2016 09:40, "Jan Beulich" <jbeul...@suse.com> wrote:
>
> >>> On 02.05.16 at 17:35, <ta...@tklengyel.com> wrote:
> > On May 2, 2016 07:12, "Jan Beulich" <jbeul...@suse.com> wrote:
> >>
> >> >>> On 29.04.16 at 20:07, <ta...@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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
