[Libvir] Proposed remote protocol (XDR source file qemud/remote_protocol.x)

[Daniel P. Berrange]

On Mon, Apr 30, 2007 at 06:48:26PM +0100, Richard W.M. Jones wrote:
> Richard W.M. Jones wrote:
> >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 also on number of domains.
> 
> >/* For each call we may have a 'remote_CALL_args' and 'remote_CALL_ret'
> > * type.  These are omitted when they are NULL.
> 
> Instead of "NULL" that should read "void".
> 
> >struct remote_get_max_vcpus_args {
> >    /* The only backend which supports this call is Xen HV, and
> >     * there the type is ignored so it could be NULL.
> >     */
> >    remote_string type;
> >};
> 
> AFAICS the 'type' parameter to GetMaxVcpus is never used.

We never implemeneted this API for QEMU - when we do, then this parameter will
be used.

> >struct remote_domain_lookup_by_name_ret {
> >    /* XXX "Not found" semantic is ill-defined. */
> >    remote_nonnull_domain dom;
> >};
> 
> There are various of these FooLookupByBar functions and as far as I can 
> see no one has given much thought to a semantic for "Not found" which 
> differs from some other error.  Am I missing something?
> 
> 
> >struct remote_domain_get_info_ret {
> >    unsigned char state;
> >    unsigned hyper max_mem;
> >    unsigned hyper memory;
> >    unsigned short nr_virt_cpu;
> >    /* XXX cpu_time is declared as unsigned long long */
> >    unsigned hyper cpu_time;
> >};
> 
> It wasn't clear if cpu_time, defined as unsigned long long in C, could 
> be larger than 64 bits.  XDR supports 64 bits max, so if it is larger 
> we'd need to send _hi and _lo hypers.

AFAIK all current 64-bit platforms define  long long as 64-bits. In terms
of the data we're actually representing here - the total CPU time accumulated
to a guest, 64 bits is plenty of space. So even if it were 128-bit, we'd
never have more than 64-bits worth of data stored, so we'd be able to safely
drop the high 64-bits.

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