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 10:43 +0000, Jan Beulich wrote:
> >>> 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.

Thanks.
> 
> > 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/,

Yes, sorry, fingers on autopilot.

>  then this could also be done (albeit it's not directly
> related to the work here).

Agreed, it's a future cleanup if anything.

>  The value Andrew was referring to was
> one in the middle of the structure though.

Which makes me think -- on N->N+1 migration might the offset of the
existing struct hvm_vmce_vcpu change? I think the answer is no because
you've inserted it into a hole in the struct. But that is the
uninitialised value Andy meant. But as you say accesses to it are gated
on the total sizeof of the struct so we know we won't look at it under
N->N+1 circumstances. (one for the docs I'd say!)

I think I may have been retreading a previous conversation there, but I
think I've not got it straight in my head!

Ian.


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