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). Roger. _______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xen.org/xen-devel