[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v10 05/25] x86: refactor psr: L3 CAT: implement CPU init and free flow.
On 17-04-07 03:46:42, Jan Beulich wrote: > >>> On 07.04.17 at 11:08, <yi.y.sun@xxxxxxxxxxxxxxx> wrote: > > On 17-04-07 02:48:40, Jan Beulich wrote: > >> >>> On 07.04.17 at 07:17, <yi.y.sun@xxxxxxxxxxxxxxx> wrote: > >> > On 17-04-06 08:02:15, Jan Beulich wrote: > >> >> Okay, so not the context switch path then, But you must be > >> >> changing the MSRs _somewhere_, and the question is why this > >> >> somewhere isn't sufficient. > >> >> > >> > Besides the restore behavior in init process, I restore the MSRs when > >> > ref[cos] > >> > is reduced to 0. This behavior happens in two scenarios: > >> > 1. In a value setting process, restore MSR if the ref[old_cos] is > >> > reduced to 0. > >> > 2. When a domain is destroyed, its ref[cos] is reduced too. > >> > > >> > Reason to restore is below: > >> > For features, e.g. CDP, which cos_num is more than 1, we have to > >> > restore the old_cos value back to default when ref[old_cos] is 0. > >> > Otherwise, user will see wrong values when this COS ID is reused. E.g. > >> > user wants to set DATA to 0x3ff for a new domain. He hopes to see the > >> > DATA is set to 0x3ff and CODE should be the default value, 0x7ff. But > >> > if the COS ID picked for this action is the one that has been used by > >> > other domain and the CODE has been set to 0x1ff. Then, user will see > >> > DATA: 0x3ff, CODE: 0x1ff. So, we have to restore COS values for > >> > features > >> > using multiple COSs. > >> > >> I still don't feel my question being answered. Without a COS > >> ever allocated on a socket, how can values in MSRs other than > >> the first (index 0) one be used by anyone? I ask because if they > >> can't be used, their values don't matter (all you need to make > >> sure is to write them regardless of their currently cached value). > > > > The COS ID using is managed by domain (d->arch.psr_cos_ids[socket]). Even > > if a > > socket is offline, the COS ID saved in domain is still valid (domain is > > alive). > > When this socket is online again, the domain may be scheduled onto it to > > run. > > Then, the COS ID (e.g 2) will be used to get/set value for this domain. If > > we > > don't restore MSRs on the socket, we may get an unknown value. This the > > reason > > we have to restore MSRs in 'cat_init_feature' which is called when socket is > > online. > > No, it's not. At least that's not the only way to solve the problem: > As said, you could equally well make sure you always write the MSR > the first time a vCPU using a particular COS is being scheduled onto > the newly onlined pCPU. In fact most of the time it is better if > generic code can also deal with special cases than to introduce > special purpose code. Hence my insisting on you properly explaining > why generic code can't deal with the post-online situation here. > Then, I propose another simple solution to handle this case. When writing MSRs, check if all values in val_array are same as old values (kept in 'cos_reg_val[]'). If a value is different, the MSR will be written and the corresponding member in 'cos_reg_val[]' will be updated. Still use above sample, user wants to set DATA to 0x3ff for a new domain. After value array assembling, the val_array will be val[DATA]=0x3ff, val[CODE]=0x7ff. The cos_reg_val[DATA]=0x7ff and cos_reg_val[DATA]=0x1ff. So, both of them will be updated. > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |