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

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

On 16-09-12 01:30:22, Jan Beulich wrote:
> >>> 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

So far, only two features and it would not be so many in the future. :)

Will add more callback function to set new value. Thanks!


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