Re: [libvirt] [PATCH 02/16] Remote driver implementation of new migration API
On 05/12/2011 10:04 AM, Daniel P. Berrange wrote:
* src/remote/remote_protocol.x: Define wire protocol for migration
protocol v3
* daemon/remote.c: Server side dispatch
* src/remote/remote_driver.c: Client side serialization
* src/remote/remote_protocol.c, src/remote/remote_protocol.h,
daemon/remote_dispatch_args.h, daemon/remote_dispatch_prototypes.h,
daemon/remote_dispatch_ret.h, daemon/remote_dispatch_table.h:
Re-generate files
* src/remote_protocol-structs: Declare new ABIs
---
daemon/remote.c | 315 +++++++++++++++++++++++++++++++++++
src/remote/remote_driver.c | 370 +++++++++++++++++++++++++++++++++++++++++-
src/remote/remote_protocol.x | 79 +++++++++-
src/remote_protocol-structs | 90 ++++++++++
4 files changed, 847 insertions(+), 7 deletions(-)
ACK; your rebase looks sane.
+struct remote_domain_migrate_begin3_args {
+ remote_nonnull_domain dom;
+ unsigned hyper flags;
+ remote_string dname;
+ unsigned hyper resource;
+};
Unrelated to your patch, but do we need to think about the issues of
dealing with 32-bit platforms?
That is, if as a client on a 64-bit platform, connected to a 32-bit
server, I call virDomainMigrate(...,0x100000000), it gets correctly
transferred to the 64-bit hyper value over the wire. But then on the
server side, the conversion of the 64-bit hyper back to a 32-bit long
corrupts the value I passed, and ends up calling virDomainMigrate(...,0).
In other words, I think we need some patches to our RPC protocol such
that all longs are passed as hyper (necessary to avoid penalizing
64-to-64 communication), but range-checked for 32-bits (necessary for
64-to-32 communication), with an appropriate error issued if the RPC
call can't proceed because of truncation issues.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)