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

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



On 17-04-27 03:39:02, Jan Beulich wrote:
> >>> 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.
> 
Thank you! Then, it seems we have addressed most issues. I will prepare v11 and
send it out in soon.

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