Re: [Xen-devel] Xen Platform QoS design discussion

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 05/22/2014 09:39 AM, Jan Beulich wrote:
> > > > On 22.05.14 at 10:19, <dongxiao.xu@xxxxxxxxx> wrote:
> > > From: xen-devel-bounces@xxxxxxxxxxxxx
> > > And without seeing the need for any advanced access mechanism,
> > > I'm continuing to try to promote D - implement simple, policy free
> > > (platform or sysctl) hypercalls providing MSR access to the tool stack
> > > (along the lines of the msr.ko Linux kernel driver).
> > Do you mean some hypercall implementation like following:
> > In this case, Dom0 toolstack actually queries the real physical CPU MSRs.
> >
> > struct xen_sysctl_accessmsr      accessmsr
> > {
> >      unsigned int cpu;
> >      unsigned int msr;
> >      unsigned long value;
> > }
> >
> > do_sysctl () {
> > ...
> > case XEN_SYSCTL_accessmsr:
> >      /* store the msr value in accessmsr.value */
> >      on_selected_cpus(cpumask_of(cpu), read_msr, &(op->u.accessmsr), 1);
> > }
> Yes, along those lines, albeit slightly more sophisticated based on
> the specific kind of operations needed for e.g. QoS (Andrew had
> some comments to the effect that simple read and write operations
> alone may not suffice).
That sounds nice and clean, and hopefully would be flexible enough to do 
stuff in the future.
But fundamentally that doesn't address Andrew's concerns that if callers 
are going to make repeated calls into libxl for each domain, this won't 
scale.
On the other hand, there may be an argument for saying, "We'll optimize 
that if we find it's a problem."
Dongxiao, is this functionality implemented for KVM yet?  Do you know 
how they're doing it?
 -George

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