[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.