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 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.

Per explanation above (in previous mail), we have to restore MSRs when ref[cos]
is reduced to 0.

Those are all sencarios and reasons to restore MSRs. I don't know if the
explanations are precise enough. Any unclear, please let me know. Thanks!

> If syncing MSR and cached values at init time is to make sure
> those writes won#t be bypassed, that would be a legitimate
> explanation (if the alternatives, like introducing a separate flag,
> would be overall more expensive or uglier). But the reason(s)
> need(s) to be properly explained (and by "properly" I don't
> mean a _long_ code comment, but a _precise_ one).
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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