Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.09.16 at 05:26, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> On 16-09-09 02:32:25, Jan Beulich wrote:
>> >>> On 09.09.16 at 10:09, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
>> > First time, user wants to set L3 CAT of Dom1 to 0x1ff for example. The 
>> > old_cos
>> > of Dom1 is 0. L3 CAT is the first element of feature list. The COS 
>> > registers
>> > values are below at this time.
>> > 
>> >         -------------------------------
>> >         | COS 0 | COS 1 | COS 2 | ... |
>> >         -------------------------------
>> > L3 CAT  | 0x7ff | ...   | ...   | ... |
>> >         -------------------------------
>> > L2 CAT  | 0xff  | ...   | ...   | ... |
>> >         -------------------------------
>> > 
>> > The mask array assembled in get_old_set_new() is:
>> > mask[0]: 0x1ff
>> > mask[1]: 0xff
>> > 
>> > It cannot find a matching COS so allocate COS 1 to store the value set.
>> > The COS registers values are changed to below now.
>> > 
>> >         -------------------------------
>> >         | COS 0 | COS 1 | COS 2 | ... |
>> >         -------------------------------
>> > L3 CAT  | 0x7ff | 0x1ff | ...   | ... |
>> >         -------------------------------
>> > L2 CAT  | 0xff  | 0xff  | ...   | ... |
>> >         -------------------------------
>> > 
>> > Then, user wants to set L3 CAT of Dom2 to 0x1ff too. The old_cos of Dom2
>> > is 0 too.
>> > 
>> > The mask array assembled in get_old_set_new() is:
>> > mask[0]: 0x1ff
>> > mask[1]: 0xff
>> > 
>> > So, it can find a matching COS, COS 1. Then, it can reuse COS 1 for Dom2.
>> 
>> So the lookup is then to find an entry with all current values except
>> for the one intended to be changed. If that's a correct understanding
>> of mine, then I think the primitives should be more primitive, making
>> the overall operation
>> 1) get all current values into an array,
>> 2) update the one array slot that's meant to get changed,
>> 3) look for matching entries,
>> 4) allocate new entry if none found.
>> And with that I'm then not even sure how many of these steps
>> actually need hooks, as most if not all of this looks pretty
>> independent of the aspects of the specific CAT variant. Hooks
>> should be introduced solely for cases where behavior necessarily
>> differs between variants.
>> 
>> Jan
> By analyzing the behaviors and requirements of different CAT features, I
> divide COS find/allocate process to three steps.
> 1) get_old_set_new(): get all current values into an array and the value of
> the changed feature is replaced by the input value(m). Here, you get an 
> array
> which contains all features old value and the new value for changed feature.
> 2) find_cos(): find if there is a matching COS combination which can match
> the input array.
> 3) alloc_new_cos(): if find_cos() cannot find a matching one, allocate a new
> COS id or reuse the one which is only occupied by current domain.
> 
> So, our ideas are almost same. Only one exception to split get_old_set_new()
> function into two parts. That increases one loop to traverse all features and
> most features "set new value" callback functions will return directly because
> the type cannot match. And, I think to put value array assembling work into 
> one
> function is reasonable. What do you think? Thanks!

How many iterations do you expect these loops to have? If it's only
a few, I think the simpler and more clear abstraction would outweigh
the performance benefits, the more that I hope none of this ends up
sitting on a performance critical path in the first place.

Jan


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