On Mon, 2016-01-18 at 18:58 +0100, Roger Pau Monné wrote: > You certainly are more familiar with the migration code than me, but > wouldn't it be enough to add a new field to libxl_domain_build_info > (uint32_t emulation_flags), and teach > libxl_domain_build_info_gen_json/libxl__domain_build_info_parse_json > how to properly parse it?
Is libxl not already aware whether a domain is to be dmlite vs pv or hvm based on the domain config? As such can't it figure out the hardcoded set to use already without actually needing to expose this in libxl API (until we actually have a desire to expose such nobs to users)? Can't this work on resume just like it does on create? > This however raises the question about how to signal that the field is > not initialised, because 0 is a valid value (maybe ~0)? In libxl's API we tend to try and avoid opaque hex numbers, so the natural result would be a struct full of libxl_defbool options, which IIRC already get properly propagated and have handling for defaulting already in place. Ian. > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
