[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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.
     */

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.