[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |