On Mon, 2015-06-15 at 14:44 +0100, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
> +EMULATOR\_CONTEXT > +---------------- > + > +A context blob for a specific emulator associated with the domain. > + > + 0 1 2 3 4 5 6 7 octet > + +------------------------+------------------------+ > + | emulator_id | index | > + +------------------------+------------------------+ > + | emulator_ctx | > + ... > + +-------------------------------------------------+ > + > +-------------------------------------------------------------------- > +Field Description > +------------ --------------------------------------------------- > +emulator_id 0x00000000: Unknown (In the case of a legacy stream) > + > + 0x00000001: Qemu Traditional > + > + 0x00000002: Qemu Upstream > + > + 0x00000003 - 0xFFFFFFFF: Reserved for future emulators. Would it be useful for future proofing to carve out some space for a per-emulator version field too? Otherwise LGTM. One thought, it might be useful (here or elsewhere) to have an explicit overview of the expected control flow (as in the ownership of the fd, and/or nesting of the layers as you prefer to think about it) between libxc, libxl and the next layer (i.e. xl). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
