Re: Xen Platform QoS design discussion

["Xu, Dongxiao" <dongxiao.xu@intel.com>]

> -----Original Message-----
> From: Jan Beulich [mailto:jbeulich@suse.com]
> Sent: Friday, May 30, 2014 2:23 PM
> To: andrew.cooper3@citrix.com; george.dunlap@eu.citrix.com; Xu, Dongxiao
> Cc: Ian.Campbell@citrix.com; Nakajima, Jun; Auld, Will; xen-devel@lists.xen.org
> Subject: Re: RE: [Xen-devel] Xen Platform QoS design discussion
> 
> >>> "Xu, Dongxiao" <dongxiao.xu@intel.com> 05/30/14 3:07 AM >>>
> >> While I can see the use and attraction of a generic MSR access
> >> hypercalls, using this method for getting QoS data is going to have
> >> subsantitally higher overhead than even the original domctl suggestion.
> >>
> >> I do not believe it will be an effective means of getting large
> >> quantities of data from ring0 MSRs into dom0 userspace.  This is not to
> >> say that having a generic MSR interface is a bad thing, but I don't
> >> think it should be used for this purpose.
> >
> >They are the two directions to implement this feature:
> >
> >Generic MSR access hypercall: It removes most of the policy in hypervisor
> > and put them in Dom0 userspace, which makes the implementation in
> > hypervisor very simple, with slightly higher cost (more hypercalls).
> >Sysctl hypercall: Hypervisor needs to consolidate all the CQM data which
> > burdens the implementation, with more memory allocation, data sharing
> > mechanism (2-level, page's address page, and page itself), also more
> > policies in hypervisor, etc. While its cost is slightly less.
> 
> >In my opinion, domctl is a compromise between two approaches, with
> > moderate policies in hypervisor, moderate size of memory allocation, with
> > moderate cost.
> 
> >I would prefer domctl or generic MSR access way, which makes the
> > implementation in hypervisor simple enough, but with only slightly higher cost.
> 
> Andrew and I talked a little more about this yesterday, and I think we agreed
> that until there is a proven need for the sysctl and/or the domctl approach, the
> generic MSR access route should be good enough. Suitably batched the
> number of hypercalls doesn't even need to be much higher than either of the
> other approaches.

Okay, I will wait several days to see whether other people have more comments about this MSR access hypercall. If no, I will start to implement it.

> 
> Question is whether this mechanism (which I'd like to be done so it can also
> later get added support for e.g. port I/O: see Linux'es dcdbas_smi_request()
> for where this might be useful) should become a sysctl op or - to be
> easily usable by the kernel too - a platform one.

For CQM, this MSR access hypercall may be somewhat specific, because it requires one MSR write and one MSR read, which cannot be split into two separate hypercalls to avoid preemption in the middle.

Thanks,
Dongxiao

> 
> Jan