Re: [V9 3/3] Differentiate IO/mem resources tracked by ioreq server

["Yu, Zhang" <yu.c.zhang@linux.intel.com>]

On 1/6/2016 4:59 PM, Jan Beulich wrote:
>>>> On 31.12.15 at 10:33, <yu.c.zhang@linux.intel.com> wrote:
>> On 12/21/2015 10:45 PM, Jan Beulich wrote:
>>>>>> On 15.12.15 at 03:05, <shuai.ruan@linux.intel.com> wrote:
>>>> --- a/xen/include/asm-x86/hvm/domain.h
>>>> +++ b/xen/include/asm-x86/hvm/domain.h
>>>> @@ -48,8 +48,8 @@ struct hvm_ioreq_vcpu {
>>>>        bool_t           pending;
>>>>    };
>>>>
>>>> -#define NR_IO_RANGE_TYPES (HVMOP_IO_RANGE_PCI + 1)
>>>> -#define MAX_NR_IO_RANGES  256
>>>> +#define NR_IO_RANGE_TYPES (HVMOP_IO_RANGE_WP_MEM + 1)
>>>> +#define MAX_NR_IO_RANGES  8192
>>>
>>> I'm sure I've objected before to this universal bumping of the limit:
>>> Even if I were to withdraw my objection to the higher limit on the
>>> new kind of tracked resource, I would continue to object to all
>>> other resources getting their limits bumped too.
>>>
>>
>> Hah. So how about we keep MAX_NR_IO_RANGES as 256, and use a new value,
>> say MAX_NR_WR_MEM_RANGES, set to 8192 in this patch? :)
>
> That would at least limit the damage to the newly introduced type.
> But I suppose you realize it would still be a resource consumption
> concern. In order for this to not become a security issue, you
> might e.g. stay with the conservative old limit and allow a command
> line or even better guest config file override to it (effectively making
> the admin state his consent with the higher resource use).

Thanks, Jan. I'll try to use the guest config file to set this limit. :)

Yu
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>