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

[Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx>]

On 17-04-21 00:18:27, Jan Beulich wrote:
> >>> On 20.04.17 at 04:14, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> > On 17-04-19 03:00:29, Jan Beulich wrote:
> >> >>> On 19.04.17 at 10:22, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> >> > On 17-04-18 05:46:43, Jan Beulich wrote:
> >> >> >>> On 18.04.17 at 12:55, <yi.y.sun@xxxxxxxxxxxxxxx> 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
> > 
> > Do you have any other suggestion on this? Thanks!
> > 
> >> >> 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!
> >> 
> >> Neither of the two. I'm comparing with COS/PSR-_unrelated_
> >> handling of register state. After all there are other MSRs which
> >> we need to put into the right state after a core comes online.
> >> 
> > For PSR feature, the 'cos_reg_val[]' of the feature is destroied when socket
> > is offline. The values in it are all 0 when socket is online again. This 
> > causes
> > error when user shows the CBMs. So, we have two options when socket is 
> > online:
> > 1. Read COS MSRs values and save them into 'cos_reg_val[]'.
> > 2. Restore COS MSRs values and 'cos_reg_val[]' values to default CBM.
> > 
> > Per our discussion on v9 patch 05, we decided to adopt option 2.
> 
> Btw., having thought some more about this, putting code into the
> context switch path when there is an alternative is probably the
> wrong thing after all, i.e. if special treatment _is_ really needed,
> doing it in less frequently executed code would likely be better.
> But as before - much depends on clarifying why special treatment
> is needed here, but not elsewhere (and to avoid questions, with
> "elsewhere" I mean outside of PSR/CAT code - there's plenty of
> other CPU register state to take as reference).
> 
Hi, Jan,

As what we talked on IRC last Friday, I have got answers for your
two final questions below:
1. Why domain setting is designed to per-socket, any reason? 
Answer: There is a real case from Intel's customer. HSX (Haswell server)
and BDX (Broadwell server) processors are plugged into each socket of a
Grantley platform. HSX does not support CAT but BDX does.

You and Chao Peng discussed this before for CAT feature enabling patches.
The asymmetry supporting is agreed.
http://markmail.org/message/xcq5odezfngszvcb#query:+page:1+mid:smfz7fbatbnxs3ti+state:results
http://markmail.org/message/xcq5odezfngszvcb#query:+page:1+mid:wlovqpg7oj63ejte+state:results

2. Why cannot the previous setting to the domains be kept when socket is online?
Answer: If the asymmetry system is supported, we cannot assume the configuration
can be applied to new socket.

BRs,
Sun Yi

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