Re: [Xen-devel] [PATCH 1/4] x86/domctl: Implement XEN_DOMCTL_{get, set}_vcpu_msrs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.06.14 at 15:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 05/06/14 13:46, Jan Beulich wrote:
>>>>> On 04.06.14 at 19:26, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> +        if ( domctl->cmd == XEN_DOMCTL_get_vcpu_msrs )
>>> +        {
>>> +            /* NULL guest handle is a request for max size. */
>>> +            if ( guest_handle_is_null(vmsrs->msrs) ||
>>> +                 (vmsrs->msr_count < nr_msrs) )
>>> +            {
>>> +                vmsrs->msr_count = nr_msrs;
>>> +                ret = guest_handle_is_null(vmsrs->msrs) ? 0 : -ENOBUFS;
>> I don't think you should be failing "get" if there is enough space in
>> the provided buffer to store the actually used number of MSRs. That
>> way the caller may make a first call with a few (rather than none at
>> all) entries, an grow the buffer only if this wasn't sufficient.
> 
> I am not sure I agree.  The MSRs are unordered in the buffer which the
> caller cannot control, and issuing a hypercall again with a larger
> buffer will rewrite it from the start again.

And I didn't suggest incremental use.

> The sole use of this hypercall needs to ensure that all MSRs are gotten,
> otherwise VM corruption will occur.  Permitting a partial get will make
> the return value ambiguous for making this hypercall a single time and
> guessing at the size to use, although I suspect we are less interested
> in this problem.

Why would the return value ambiguous? You'd get -ENOBUFS if you
provided too few slots, and you'd get to know the maximum number
at that point at once.

Jan


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