Re: [Xen-devel] [PATCH v12 15/23] x86: refactor psr: CDP: implement set value callback function.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.07.17 at 08:33, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> On 17-06-30 06:02:32, Jan Beulich wrote:
>> >>> Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx> 06/30/17 1:30 PM >>>
>> >The input 'type' is CODE. The props->type[0] is DATA and props->type[1] is 
>> >CODE.
>> >In the first iteration, the props->type[0] is DATA so that it does not match
>> >'type' and the second check is false too. If we use else branch here, it 
>> >will
>> >enter the branch and return -EVINVAL. But this is not we want, right? We 
>> >hope
>> >the second iteration should be executed to set CODE.
>>  
>> I see. That'll then call for yet another solution; I don't think the code 
>> should
>> stay as is.
>> 
> Then, how about ASSERT() at the beginning to check if input 'type' is 
> correct?
>     enum cbm_type {
>         PSR_CBM_TYPE_L3,
>         PSR_CBM_TYPE_L3_DATA,
>         PSR_CBM_TYPE_L3_CODE,
>         PSR_CBM_TYPE_L2,
>     };
> 
>     ASSERT((type >= props->type[0] && type <= props->type[props->cos_num - 
> 1]) ||
>            type == props->alt_type);

Baking in ordering assumptions? No, please don't.

> We don't need 'ret' anymore with above check.

So in a release build you'd then do what in case of a bad type finding
its way in?

Jan


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