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

["Yu, Zhang" <yu.c.zhang@xxxxxxxxxxxxxxx>]

On 1/6/2016 4:59 PM, Jan Beulich wrote:
> > > > On 31.12.15 at 10:33, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
> > On 12/21/2015 10:45 PM, Jan Beulich wrote:
> > > > > > On 15.12.15 at 03:05, <shuai.ruan@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel