On Mon, Apr 30, 2007 at 06:42:01PM +0100, Richard W.M. Jones wrote: > Attached are the args (*_args) and return structures (*_ret) for all the > calls covered by the remote protocol, that is to say everything except > Save, Restore and CoreDump (see previous email). > > The only problem area are the upper limits imposed on the lengths of > various strings and arrays. The upper limits seem to be required for > safely decoding messages from untrusted sources. Some of them however > would impose limits on such things as the number of CPUs supported, and > perhaps those limits are too low (or too high)? I don't really have any > experience of the sort of huge machines that people might be running > libvirt on. SGI did a preso at the Xen summit about their 1024 CPU monster ia64 box. So given that such a thing already exists, we need biggger to account for future developments. One thing I'm not clear - are these limits actually applied at the protocol level, or is the protocol completely variable length and these limits enforced during decoding ? If the latter, then this isn't so critical to get perfect, because we can do updates without breaking back-compat. > /*----- Data types. -----*/ > > /* Maximum total message size (serialised). */ > const REMOTE_MESSAGE_MAX = 262144; > > /* Length of long, but not unbounded, strings. > * This is an arbitrary limit designed to stop the decoder from trying > * to allocate unbounded amounts of memory when fed with a bad message. > */ > const REMOTE_STRING_MAX = 65536; > > /* A long string, which may NOT be NULL. */ > typedef string remote_nonnull_string<REMOTE_STRING_MAX>; > > /* A long string, which may be NULL. */ > typedef remote_nonnull_string *remote_string; > > /* This just places an upper limit on the length of lists of > * domain IDs which may be sent via the protocol. > */ > const REMOTE_DOMAIN_ID_LIST_MAX = 4096; On Xen, domain id is a 16 bit quantity. How many concurrent guests should we account for ? > /* Upper limit on lists of domain names. */ > const REMOTE_DOMAIN_NAME_LIST_MAX = 256; However many active guests we support, we need to match that, since every active guest has a config file somewhere. > /* Upper limit on cpumap (bytes) passed to virDomainPinVcpu. */ > const REMOTE_CPUMAP_MAX = 256; Guess this should be 1/8 of number of CPUs we support. So this gives us 2048 currently. > /* Upper limit on number of info fields returned by virDomainGetVcpus. */ > const REMOTE_VCPUINFO_MAX = 2048; So this is basically the max # of VCPUs we support. 2048 sounds like way more than enough for virtual CPUs, since one huge machines the ratio of phys / virt CPUs is likely to be quite large. > /* Upper limit on cpumaps (bytes) passed to virDomainGetVcpus. */ > const REMOTE_CPUMAPS_MAX = 16384; This needs to be based off # phys * # vcpus we support from the earlier two constants for consistency. > /* Upper limit on lists of network names. */ > const REMOTE_NETWORK_NAME_LIST_MAX = 256; Reasonable. I wonder what max # of bridge devices Linux supports is. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|