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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.03.14 at 10:55, <Ian.Campbell@xxxxxxxxxx> wrote:
> 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?

Will do.

> 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?)

If s/pass/pad/, then this could also be done (albeit it's not directly
related to the work here). The value Andrew was referring to was
one in the middle of the structure though.

Jan


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