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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 06/06/14 16:09, Jan Beulich wrote:
>>
>> Having tried to implement these improvements, I hit problems so would
>> like to decide upon an interface before hacking futher.
>>
>> Currently behaviour for get:
>> * Null guest handle returns msr_count set to maximum number of msrs Xen
>> might write
>> * msr_count < max_msrs fails with -ENOBUFS
>> * if msrs are written, msr_count reflects the number written (likely
>> less than max_msrs)
>>
>> Current behaviour for set:
>> * msr_count > max_msrs fails with -EINVAL
>> * problems with individual msrs fail with -EINVAL
>>
>> Suggestions:
>> * for get, msr_count < max_msrs should perform a partial write,
>> returning -ENOBUFS if Xen needs to write more than msr_count msrs.
>>
>> This reduces the amount of code added to xc_domain_save() to fail
>> migrations actually using PV msrs.  I am not too concerned about this
>> code, as it will be rm'd in the migration-v2 series which implements PV
>> MSR migration properly.  I am a little bit hesitant about supporting
>> partial writes, although I suppose it is plausible to want to know "how
>> many MSRs is the vcpu currently using", and doing that with a single
>> hypercall is preferable to requiring two.
> Yes. I didn't see above what problem you found with this.

Not a problem purse, just a concern.

>
>> * for set, in the case of a bad msr, identify it back to the caller to
>> aid with debugging.
>>
>> This is useful to help debugging, but needs disambiguating against the
>> other cases which fail with -EINVAL, including the paths which would
>> fail before having a chance to set msr_count to the index of the bad
>> msr.  Therefore, msr_count *can't* be overloaded for this purpose.
> Actually it can - the caller will know the number it put there, and if it's
> unchanged then the failure was not associated with a particular array
> entry (all possible values on error would be smaller than the value
> originally there).

Ah yes - quite correct.  That make the set-side debugging trivial.

I will see about making these alterations.

~Andrew