Re: [PATCH v10 05/25] x86: refactor psr: L3 CAT: implement CPU init and free flow.

[Yi Sun <yi.y.sun@linux.intel.com>]

On 17-04-07 03:46:42, Jan Beulich wrote:
> >>> On 07.04.17 at 11:08, <yi.y.sun@linux.intel.com> wrote:
> > On 17-04-07 02:48:40, Jan Beulich wrote:
> >> >>> On 07.04.17 at 07:17, <yi.y.sun@linux.intel.com> wrote:
> >> > On 17-04-06 08:02:15, Jan Beulich wrote:
> >> >> Okay, so not the context switch path then, But you must be
> >> >> changing the MSRs _somewhere_, and the question is why this
> >> >> somewhere isn't sufficient.
> >> >> 
> >> > Besides the restore behavior in init process, I restore the MSRs when 
> >> > ref[cos]
> >> > is reduced to 0. This behavior happens in two scenarios:
> >> > 1. In a value setting process, restore MSR if the ref[old_cos] is reduced to 0.
> >> > 2. When a domain is destroyed, its ref[cos] is reduced too.
> >> > 
> >> > Reason to restore is below:
> >> >   For features,  e.g. CDP, which cos_num is more than 1, we have to
> >> >   restore the old_cos value back to default when ref[old_cos] is 0.
> >> >   Otherwise, user will see wrong values when this COS ID is reused. E.g.
> >> >   user wants to set DATA to 0x3ff for a new domain. He hopes to see the
> >> >   DATA is set to 0x3ff and CODE should be the default value, 0x7ff. But
> >> >   if the COS ID picked for this action is the one that has been used by
> >> >   other domain and the CODE has been set to 0x1ff. Then, user will see
> >> >   DATA: 0x3ff, CODE: 0x1ff. So, we have to restore COS values for features
> >> >   using multiple COSs.
> >> 
> >> I still don't feel my question being answered. Without a COS
> >> ever allocated on a socket, how can values in MSRs other than
> >> the first (index 0) one be used by anyone? I ask because if they
> >> can't be used, their values don't matter (all you need to make
> >> sure is to write them regardless of their currently cached value).
> > 
> > The COS ID using is managed by domain (d->arch.psr_cos_ids[socket]). Even if a
> > socket is offline, the COS ID saved in domain is still valid (domain is alive).
> > When this socket is online again, the domain may be scheduled onto it to run.
> > Then, the COS ID (e.g 2) will be used to get/set value for this domain. If we
> > don't restore MSRs on the socket, we may get an unknown value. This the reason
> > we have to restore MSRs in 'cat_init_feature' which is called when socket is
> > online.
> 
> No, it's not. At least that's not the only way to solve the problem:
> As said, you could equally well make sure you always write the MSR
> the first time a vCPU using a particular COS is being scheduled onto
> the newly onlined pCPU. In fact most of the time it is better if
> generic code can also deal with special cases than to introduce
> special purpose code. Hence my insisting on you properly explaining
> why generic code can't deal with the post-online situation here.
> 
Then, I propose another simple solution to handle this case. When writing
MSRs, check if all values in val_array are same as old values (kept in
'cos_reg_val[]'). If a value is different, the MSR will be written and the
corresponding member in 'cos_reg_val[]' will be updated. Still use above
sample, user wants to set DATA to 0x3ff for a new domain. After value array
assembling, the val_array will be val[DATA]=0x3ff, val[CODE]=0x7ff. The
cos_reg_val[DATA]=0x7ff and cos_reg_val[DATA]=0x1ff. So, both of them will
be updated.

> Jan

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