Re: [Libvir] Proposed remote protocol (XDR source file qemud/remote_protocol.x)
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 -=|