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 -=|