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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2014-04-23 at 14:03 +0100, Jan Beulich wrote:
> >>> On 23.04.14 at 14:50, <JBeulich@xxxxxxxx> wrote:
> >>>> On 23.04.14 at 14:39, <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> >> On Wed, 2014-04-23 at 13:35 +0100, Jan Beulich wrote:
> >>> >>> On 23.04.14 at 14:23, <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> >>> > All makes sense. Worth a comment though?
> >>> 
> >>> Not sure - it's no more subtle than other code in the handling of that
> >>> specific sub-hypercall. But yes, by my own argumentation elsewhere
> >>> maybe I shouldn't be extending badness - if only I saw ways of
> >>> describing things like this without just converting C to human language
> >>> (which doesn't seem all that helpful)...
> >> 
> >> Nothing the behaviour of msr_count you describe doesn't sound like just
> >> converting the C to human readable to me, unless you expect readers of
> >> this interface header to go digging into the implementation to figure
> >> this out, which shouldn't be needed (that's the point of docs after all!)
> > 
> > Oh, right, I didn't realize your comment was in the context of the
> > public header changes - I blindly assumed them to be on the code
> > implementing the interface extension. Will see to put something like
> > the above in there.
> 
>     /*
>      * When, for the "get" version, msr_count is too small to cover all MSRs
>      * the hypervisor needs to be saved, the call will return -ENOBUFS and
>      * set msr_count to the required (minimum) value. Furthermore, for both
>      * "get" and "set", that field as well as the msrs one only get looked at
>      * if the size field above covers the structure up to the entire msrs one.
>      */

From the ARM (complete lack of impact) and generic headers pov with this
comment in the appropriate place:
        Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>


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