Re: [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Yi Sun <yi.y.sun@linux.intel.com>]

On 17-04-18 05:46:43, Jan Beulich wrote:
> >>> On 18.04.17 at 12:55, <yi.y.sun@linux.intel.com> wrote:
> > I made a test patch based on v10 and attached it in mail. Could you please
> > help to check it? Thanks!
> 
> This looks reasonable at the first glance, albeit I continue to be
> unconvinced that this is the only (reasonable) way of solving the
> problem. After all we don't have to go through similar hoops for
> any other of the register state associated with a vCPU. There

Sorry, I do not understand your meaning clearly.
1. DYM the ASSOC register which is set in 'psr_ctxt_switch_to'? In this patch,
   we check 'dom_ids' array to know if the domain's cos id has not been set but
   its 'psr_cos_ids[socket]' already has a non zero value. This case means the
   socket offline has happened so that we have to restore the domain's
   'psr_cos_ids[socket]' to default value 0 which points to default COS MSR.
   I think we have discussed this in previous mails and achieved agreement on
   such logic. 
2. DYM the COS MSRs? We have discussed this before. Per your comments, when
   socket is online, the registers values may be modified by FW and others.
   So, we have to restore them to default value which is being done in
   'cat_init_feature'.

So, what is your exactly meaning here? Thanks!

> are a number of cosmetic issues, but commenting on an attached
> (rather than inlined) patch is a little difficult.
> 
Sorry for that, I will directly send patch out next time.

> One remark regarding the locking though: Acquiring a lock in the
> context switch path should be made as low risk of long stalls as
> possible. Therefore you will want to consider using r/w locks
> instead of spin locks here, which would allow parallelism on all
> cores of a socket as long as COS IDs aren't being updated.
> 
In 'psr_ctxt_switch_to', I use the lock only to protect 'write' actions.
So, I do not understand why read-write lock is better? Anything I don't
consider? Please help to point out. Thanks!

> Jan

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