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

Re: [Xen-devel] [PATCH] dom_ids array implementation.



>>> On 27.04.17 at 11:30, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> I have another solution now. We may move the psr_cos_ids[socket] restore 
> action
> into 'psr_get_val' and only set the bit of 'dom_ids[]' in 'psr_set_val'.
> 1. When socket is offline, the dom_ids[] is cleared.
> 2. When socket is online, we have four places to use psr_cos_ids[socket]:
>    a. psr_ctxt_, we can use test_bit() atomically check if the bit is set. If
>       not, that means the d->arch.psr_cos_ids[socket] is invalid at this time.
>       Then, we use 0 to set ASSOC register. But we don't restore psr_cos_ids
>       here and do not set dom_ids[]. So, we do not need the spin_lock.
>    b. psr_get_val, we use test_bit() to check if the bit is 0 and the
>       d->arch.psr_cos_ids[socket] is not 0. If yes, that means this domain's
>       cos id has not been restored yet. So we restore it to 0.
>    c. psr_set_val, we set the bit in dom_ids[] and set
>       d->arch.psr_cos_ids[socket]. As, psr_set_val cannot happen when
>       psr_get_val is called, so no protection is needed.
>    d. psr_free_cos, clear the bit and free d->arch.psr_cos_ids. This place
>       cannot happen at the same time that the above three functions called.
>       So, no protection needed.
> 
> Per above analysis, we do not need lock protection. So, the CPU serialization
> issue can be solved. How do you think?

Looks promising.

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