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

Re: [Xen-devel] [PATCH-for-4.13 v5] Rationalize max_grant_frames and max_maptrack_frames handling



On 29.11.2019 11:39, Durrant, Paul wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: 29 November 2019 10:29
>> To: Durrant, Paul <pdurrant@xxxxxxxxxx>
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Anthony PERARD
>> <anthony.perard@xxxxxxxxxx>; George Dunlap <george.dunlap@xxxxxxxxxx>;
>> Roger Pau Monné <roger.pau@xxxxxxxxxx>; Volodymyr Babchuk
>> <Volodymyr_Babchuk@xxxxxxxx>; George Dunlap <George.Dunlap@xxxxxxxxxxxxx>;
>> Ian Jackson <ian.jackson@xxxxxxxxxxxxx>; Marek Marczykowski-Górecki
>> <marmarek@xxxxxxxxxxxxxxxxxxxxxx>; Stefano Stabellini
>> <sstabellini@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Konrad Rzeszutek
>> Wilk <konrad.wilk@xxxxxxxxxx>; Julien Grall <julien@xxxxxxx>; Wei Liu
>> <wl@xxxxxxx>
>> Subject: Re: [PATCH-for-4.13 v5] Rationalize max_grant_frames and
>> max_maptrack_frames handling
>>
>> On 29.11.2019 11:22, Jan Beulich wrote:
>>> On 28.11.2019 17:52, Paul Durrant wrote:
>>>> --- a/xen/common/grant_table.c
>>>> +++ b/xen/common/grant_table.c
>>>> @@ -84,11 +84,40 @@ struct grant_table {
>>>>      struct grant_table_arch arch;
>>>>  };
>>>>
>>>> +static int parse_gnttab_limit(const char *param, const char *arg,
>>>> +                              unsigned int *valp)
>>>> +{
>>>> +    const char *e;
>>>> +    unsigned long val;
>>>> +
>>>> +    val = simple_strtoul(arg, &e, 0);
>>>> +    if ( *e )
>>>> +        return -EINVAL;
>>>> +
>>>> +    if ( val > INT_MAX )
>>>> +        return -ERANGE;
>>>> +
>>>> +    return 0;
>>>> +}
>>>
>>> *valp doesn't get written to anymore.
> 
> That was intentional, given Juergen's comment...
> 
>> With this fixed (and no new
>>> issues introduced ;-) ) hypervisor side
>>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> And I guess I should have clarified: I'd be fine adding the missing
>> assignment while committing, provided the tools side won't require
>> any changes.
> 
> ...but if we want to allow dom0 to set itself up for INT_MAX frames
> in the event of a bad value then I'm not objecting.

Looks like you're misunderstanding, or I'm missing something:
The command line options right now won't take any effect, as
the opt_* global variables won't be written to at all. I'm not
taking about falling back to using INT_MAX when we've noticed
an out of bounds value.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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