On 03/09/18 12:09, Julien Grall wrote:
On 23/08/18 08:58, Roger Pau Monné wrote:
On Wed, Aug 22, 2018 at 06:48:05PM +0100, Julien Grall wrote:
+
+ b_info->type = LIBXL_DOMAIN_TYPE_PVH;
+
+ /*
+ * They only field in u.pv that matters on Arm are: kernel,
cmdline,
+ * ramdisk.
+ */
+
+ if (!b_info->kernel && b_info->u.pv.kernel)
+ b_info->kernel = b_info->u.pv.kernel;
+
+ if (!b_info->ramdisk && b_info->u.pv.ramdisk)
+ b_info->ramdisk = b_info->u.pv.ramdisk;
+
+ if (!b_info->cmdline && b_info->u.pv.cmdline)
+ b_info->cmdline = b_info->u.pv.cmdline;
+
+ /* Reset b_info->u.pvh to default values */
+ memset(&b_info->u.pvh, 0, sizeof(b_info->u.pvh));
I'm afraid that's not correct. The default values for u.pvh are set
by libxl__domain_build_info_setdefault.
I thought that this should be covered by the switch right after the
call of
libxl__arch_domain_build_info_setdefault. Did I miss anything?
Oh right, libxl__arch_domain_build_info_setdefault is called by
libxl__domain_build_info_setdefault.
What I wanted to do here is resetting the union to 0 so you don't get
data
mangled by the pv fields.
Another possible option I think would be to mark those fields as
deprecated in the IDL, and libxl__domain_build_info_copy_deprecated
will take care of copying them to the new place. In fact I think all
guest types should be using the top level kernel, ramdisk and cmdline
fields.
I will have a look at it.
I'm not specially comfortable with changing the guest type in the
middle of libxl__domain_build_info_setdefault, but I also don't have a
much better suggestion apart from using the deprecation helper.
I forgot to answer to this bit. I don't think the deprecation helper
will do all the jobs. There are still PV specific parameters:
slack_memkb, features, e820_host.
Those are not necessary for Arm, if you don't zero them then you will
not initialize the PVH structure with default values. How do you suggest
to handle them?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
