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 11:08, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> On 17-04-07 02:48:40, Jan Beulich wrote:
>> >>> 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).
> 
> 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.

Jan


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