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