[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [V9 3/3] Differentiate IO/mem resources tracked by ioreq server
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 8192I'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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |