Re: [Xen-devel] [PATCH v2 RFC 2/4] x86/PV: support data breakpoint extension registers

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-03-28 at 08:05 +0000, Jan Beulich wrote:
> >>> On 27.03.14 at 18:29, <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Thu, 2014-03-27 at 16:44 +0000, Jan Beulich wrote:
> >> >>> On 27.03.14 at 17:23, <Ian.Campbell@xxxxxxxxxx> wrote:
> >> > On Thu, 2014-03-27 at 16:03 +0000, Jan Beulich wrote:
> >> >> >>> On 27.03.14 at 16:28, <Ian.Campbell@xxxxxxxxxx> wrote:
> >> >> > How does N->N+1 migration work out?
> >> >> 
> >> >> Since the structure size grows, and that size is embedded in the
> >> >> structure, input coming from N will be treated as not having any
> >> >> MSRs.
> >> > 
> >> > This is the size of the "extv" block in the header phase?
> >> 
> >> No, the "size" member of struct xen_domctl_ext_vcpucontext.
> > 
> > OK, that makes sense.
> > 
> > Are you also breaking the 128b limit on the data returned by this
> > struct?
> 
> Indirectly, not directly (by adding this pointer to outside the
> structure). The 128-byte limit is the fundamental reason why a
> separate array needs to be used here, and why therefore extra
> data needs to follow the base structure in the save/restore
> stream.

Ah I see.

So am I correct that the xen_domctl_ext_vcpucontext is sent in its
entirety, including whatever the existing pointer is, which will
certainly be bogus on the other end. The receiver will naturally
overwrite it, but perhaps it should be poisoned on the wire just for
belt-and-braces sake?

In fact -- it seems that 128 bytes are sent regardless of
sizeof(xen_domctl_ext_vcpucontext) (which doesn't look to be == 128
yet). The code is already this way, but for a future cleanup perhaps
pass to 128 with some known value? (I guess this was the stack value
which Andrew was referring too?)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel