Re: Xen Platform QoS design discussion

[George Dunlap <George.Dunlap@eu.citrix.com>]

On Thu, Jun 5, 2014 at 1:48 AM, Xu, Dongxiao <dongxiao.xu@intel.com> wrote:
>> -----Original Message-----
>> From: Jan Beulich [mailto:jbeulich@suse.com]
>> Sent: Friday, May 30, 2014 7:18 PM
>> To: ian.campbell@citrix.com
>> Cc: andrew.cooper3@citrix.com; george.dunlap@eu.citrix.com; Xu, Dongxiao;
>> Nakajima, Jun; Auld, Will; xen-devel@lists.xen.org
>> Subject: Re: RE: RE: [Xen-devel] Xen Platform QoS design discussion
>>
>> >>> Ian Campbell <ian.campbell@citrix.com> 05/30/14 11:11 AM >>>
>> >On Thu, 2014-05-29 at 10:11 +0100, Jan Beulich wrote:
>> >> >>> "Xu, Dongxiao" <dongxiao.xu@intel.com> 05/29/14 9:31 AM >>>
>> >> >Okay. If I understand correctly, you prefer to implement a pure MSR access
>> >> >hypercall for one CPU, and put all other CQM things in libxc/libxl layer.
>> >>
>> >> >In this case, if libvert/XenAPI is trying to query a domain's cache utilization
>> >> >in the system (say 2 sockets), then it will trigger _two_ such MSR access
>> >> >hypercalls for CPUs in the 2 different sockets.
>> >> >If you are okay with this idea, I am going to implement it.
>> >>
>> >> I am okay with it, but give it a couple of days before you start so that others
>> >> can voice their opinions too.
>> >
>> >Dom0 may not have a vcpu which is scheduled/schedulable on every socket.
>> >scheduled it can probably deal with by doing awful sounding temporary
>> >things to its affinity mask, but if it is not schedulable (e.g. due to
>> >cpupools etc) then that sounds even harder to sort...
>>
>> But that's why we're intending to add a helper hypercall in the first place. This
>> isn't intended to be a 'read MSR' one, but a 'read MSR in this CPU'.
>
> No more comments on this MSR access hypercall design now, so I assume people are mostly okay with it?

Yes -- I think everyone who commented before is satisfied with that
approach, and anyone who hasn't commented has had ample opportunity to
do so.

 -George