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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.04.17 at 07:17, <yi.y.sun@xxxxxxxxxxxxxxx> 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).
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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel