Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.03.17 at 09:18, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> On 17-03-15 01:40:06, Jan Beulich wrote:
>> >>> On 15.03.17 at 03:52, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
>> > Sorry, I may not fully understand your meaning. My thoughts are below.
>> > 1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';
>> > 
>> > 2. After that, we get valid cpumask through cpupool_domain_cpumask();
>> > 
>> > 3. If the actual valid cpumask changed after that, the new cpu is valid so
>> >    that the context switch happens. Then 'psr_ctxt_switch_to' is called to
>> >    update the new cpu's ASSOC register with the new COS ID which has been
>> >    set in step 1.
>> > 
>> > 4. Send IPI to all cpus on cpumask got in step 2. They will update their
>> >    ASSOC registers according to their domains psr_cos_ids[].
>> > 
>> > So I think this flow can cover all cpus which ASSOC registers need be 
>> > updated.
>> 
>> You writing it down this way makes me realize that the IPI approach
>> can't work this way at all: It leaves a time window (between 1 and 2)
>> where the domain may have vCPU-s running with the wrong COS ID.
>> I think pausing the vCPU is unavoidable, unless it can be explained
>> that running with the wrong COS ID for a brief period of time is not
>> really a problem. I do realize that the pausing approach has its own
>> difficulty wrt Dom0, but I think that's solvable (e.g. by doing the
>> actual work in a tasklet instead of in the context of a Dom0 vCPU).
>> 
> I have below thoughts.
> 1. We can use domain_pause for all domains except Dom0 to update COS ID.
> 2. PSR features are to set cache capacity for a domain. The setting to
>    cache is progressively effective. When the cache setting becomes really
>    effective, the time slice to schedule a domain may have passed. Moreover,
>    even a wrong COS ID is used to set ASSOC, only another CBM be effective
>    for a short time. In next Dom0 schedule, the correct CBM will take effect.
>    So can we just leave Dom0 setting as current implementation?

If at all possible I'd like to avoid special casing Dom0. Please keep in
mind that in disaggregated environments domctl-s may be issued by
other than Dom0. So either the argumentation above to use the
current implementation is okay for all domains (and is reasonable to
expect to hold for possible future extensions), or all domains need
to be taken care of by a changed approach.

Jan


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