[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v13 08/23] x86: refactor psr: L3 CAT: set value: implement framework.
>>> Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx> 07/06/17 4:08 AM >>> >As set value flow is the most complicated one in psr, it will be >divided to some patches to make things clearer. This patch >implements the set value framework to show a whole picture firstly. > >It also changes domctl interface to make it more general. > >To make the set value flow be general and can support multiple features >at same time, it includes below steps: >1. Test and set dom_ids bit corresponding to the domain. If the old bit is 0 >which means the domain's COS ID is invalid, restore COS ID to 0. If the >COS ID is valid, get the COS ID that current domain is using. >2. Gather a value array to store all features current value >into it and replace the current value of the feature which is >being set to the new input value. >3. Find if there is already a COS ID on which all features' >values are same as the array. Then, we can reuse this COS >ID. >4. If fail to find, we need pick an available COS ID. Only COS ID which ref >is 0 or 1 can be picked. >5. Write the feature's MSRs according to the COS ID. >6. Update ref according to COS ID. >7. Save the COS ID into current domain's psr_cos_ids[socket] so that we >can know which COS the domain is using on the socket. > >So, some functions are abstracted and the callback functions will be >implemented in next patches. > >Here is an example to understand the process. The CPU supports >two featuers, e.g. L3 CAT and L2 CAT. User wants to set L3 CAT >of Dom1 to 0x1ff. >1. At the initial time, the old_cos of Dom1 is 0. The COS registers values >are below at this time. >------------------------------- >| COS 0 | COS 1 | COS 2 | ... | >------------------------------- >L3 CAT | 0x7ff | 0x7ff | 0x7ff | ... | >------------------------------- >L2 CAT | 0xff | 0xff | 0xff | ... | >------------------------------- > >2. Gather the value array and insert new value into it: >val[0]: 0x1ff >val[1]: 0xff > >3. It cannot find a matching COS. > >4. Pick COS 1 to store the value set. > >5. Write the L3 CAT COS 1 registers. The COS registers values are >changed to below now. >------------------------------- >| COS 0 | COS 1 | COS 2 | ... | >------------------------------- >L3 CAT | 0x7ff | 0x1ff | ... | ... | >------------------------------- >L2 CAT | 0xff | 0xff | ... | ... | >------------------------------- > >6. The ref[1] is increased to 1 because Dom1 is using it now. > >7. Save 1 to Dom1's psr_cos_ids[socket]. > >Then, user wants to set L3 CAT of Dom2 to 0x1ff too. The old_cos >of Dom2 is 0 too. Repeat above flow. > >The val array assembled is: >val[0]: 0x1ff >val[1]: 0xff > >So, it can find a matching COS, COS 1. Then, it can reuse COS 1 >for Dom2. > >The ref[1] is increased to 2 now because both Dom1 and Dom2 are >using this COS ID. Set 1 to Dom2's psr_cos_ids[socket]. > >There is one thing need to emphasize that we need restore domain's COS ID to >0 when socket is offline. Otherwise, a wrong COS ID will be used when the >socket is online again. That may cause user see the wrong CBM shown. But it >takes much time to iterate all domains to restore COS ID to 0. So, we define >a 'dom_ids[]' to represents all domains, one bit corresponds to one domain. >If the bit is 0 when entering 'psr_ctxt_switch_to', that means this is the >first time the domain is switched to this socket or domain's COS ID has not >been set since the socket is online. So, the COS ID set to ASSOC register on >this socket should be default value, 0. If not, that means the domain's COS >ID has been set when the socket was online. So, this COS ID is valid and we >can directly use it. We restore the domain's COS ID to 0 if the bit >corresponding to the domain is 0 but the domain's COS ID is not 0 when >'psr_get_val' and 'psr_set_val' is called. This can avoid CPU serialization >if restoring action is exectued in 'psr_ctxt_switch_to'. > >Signed-off-by: Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |