[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RESEND v5 03/24] x86: refactor psr: implement main data structures.



On 17-01-30 17:20:39, Konrad Rzeszutek Wilk wrote:
> > +struct psr_socket_info {
> > +    /*
> > +     * bit 0:   L3 CAT
> > +     * bit 1:   L3 CDP
> > +     * bit 2:   L2 CAT
> 
> Why not an enum? I am going to assume it is due to you programming
> this in the MSRs. If so, I would recommend you have #define instead
> of a comment.
> 
> #define L3_CAT (1U<<0)
> #define L3_CDP (1U<<1)
> 
> . and so on..
> 
> > +     */
> > +    unsigned int feat_mask;
> > +    unsigned int nr_feat;
> > +    struct list_head feat_list;
> > +    unsigned int cos_ref[MAX_COS_REG_CNT];
> > +    spinlock_t ref_lock;
> > +};
> > +
> > +enum psr_feat_type {
> > +    PSR_SOCKET_L3_CAT = 0,
> > +    PSR_SOCKET_L3_CDP,
> > +    PSR_SOCKET_L2_CAT,
> 
> Is there particular mapping between these and the feat_mask bit mask
> values?
> 
> It kind of begs to be combined (unless you really need the 'feat_mask'
> to be of specific order - in which case make sure you have BUILD_BUG_ON
> to make sure nobody moves the #define values around - or put a comment
> saying that you need the specific order of bits).
> 
Like what you mentioned in patch 5 review comments, the feat_mask bit mask
reuses 'enum psr_feat_type'. I will add comments to describe this. Thanks!

BRs,
Sun Yi

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

 


Rackspace

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