Re: [Xen-devel] [PATCH v3 06/15] x86: implement get value interface for MBA

[Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx>]

On 17-09-20 09:43:40, Roger Pau Monn� wrote:
> On Wed, Sep 20, 2017 at 01:09:06PM +0800, Yi Sun wrote:
> > On 17-09-19 10:15:42, Roger Pau Monn� wrote:
> > > On Tue, Sep 05, 2017 at 05:32:28PM +0800, Yi Sun wrote:
> > > > diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> > > > index 696eff2..7902af7 100644
> > > > --- a/xen/arch/x86/domctl.c
> > > > +++ b/xen/arch/x86/domctl.c
> > > > @@ -1496,6 +1496,13 @@ long arch_do_domctl(
> > > >              copyback = true;
> > > >              break;
> > > >  
> > > > +        case XEN_DOMCTL_PSR_ALLOC_GET_MBA_THRTL:
> > > > +            ret = psr_get_val(d, domctl->u.psr_alloc.target,
> > > > +                              &val32, PSR_TYPE_MBA_THRTL);
> > > > +            domctl->u.psr_alloc.data = val32;
> > > 
> > > Hm, why does psr_get_val take a uint32_t * instead of a uint64_t *? So
> > > that you can directly pass &domctl->u.psr_alloc.data.
> > > 
> > > Or the other way around, why is domctl->u.psr_alloc.data a uint64_t
> > > instead of a uint32_t?
> > > 
> > There is a historical reason. The COS MSR is 64bit. So, the original codes
> > in L3 CAT (submitted years ago) used uint64_t.
> > 
> > But during L2 CAT review, per Jan's comment, the uint64_t is not necessary
> > in psr.c. So, we convert it to uint32_t in psr.c and make the codes you see
> > here.
> 
> Since this is a DOMCTL, you can change the type of the structure to be
> an uint32_t, so that you can pass it directly (unless I'm missing
> something else that requires this to be uint64_t).
> 
The tools layer implementation uses uint64_t according to SDM definition. So,
we have to do a convertion here or in tools/. Or, we need modify interfaces in
tools layer.

As CAT interfaces in tools layer have been released and it is a natural choice
to make it same as SDM, I think should keep uint64_t in tools at least. If so,
we must do the convertion somewhere. Then, I think it is not so necessary to
change current codes. Is that good to you?

> Roger.

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