[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
>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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.