Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN

[Tim Deegan <tim@xxxxxxx>]

At 14:09 +0800 on 19 Dec (1418994579), Chao Peng wrote:
> On Thu, Dec 18, 2014 at 05:40:28PM +0100, Tim Deegan wrote:
> > Hi,
> >
> > Thanks for posting this - it's very useful.  I have a couple of
> > questions about the interface design.
> Thanks Tim.
> >
> > At 20:27 +0800 on 12 Dec (1418412477), Chao Peng wrote:
> > > Design Overview
> > > When enforcing cache allocation for VMs, the minimum granularity is
> > > defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> > > same COS, and therefore, correspond to the same CBM. COS is used only in
> > > hypervisor and is transparent to tool stack/user. System administrator
> > > can specify the initial CBM for each domain or change it at runtime using
> > > tool stack. Hypervisor then choses a free COS to associate it with that
> > > CBM or find a existed COS which has the same CBM.
> >
> > What happens if there is no existing COS that matches, and all COSes
> > are in use?  Does Xen return an error?  Or try to change COS->CMB
> > mappings during context switches?
> 
> In the initial implementation, error is returned. It??s possible for
> hypervisor to share COS for different CBMes and not to return error
> here. But the problem is that COS shortage may still happen during
> context switch. At that time we will have no idea for what to do. So I??d
> prefer to return error directly here and leave the decision to user
> space, e.g. if error is returned then it can clear CBM for some domain
> and get free COS.

Righto, thanks. 

> > Is it OK to assume that in the common case all CPUs have the same CAT
> > capabilities?  Then Xen can just report the smallest set of
> > capabilities of any socket in the system, and the toolstack doesn't
> > have to mess about with per-socket settings.
> >
> > I guess you can add that syntactic sugar on the tools if you want and
> > leave the more powerful hypecall interface in case it's useful. :)
> 
> Agreed, this is what I want to do. Basically the socketId is optional
> for the caller. If more than one socket exists, omitting socketId means
> the specified CBM applied to all sockets. While we still maintain
> per-socket CBM in hypervisor internally and provide per-socket hypercall
> interface in case it??s needed. In this way the interface should be user
> friendly for most cases.

Sounds good.  Thanks for clarifying.

Cheers,

Tim.

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