Re: [Xen-devel] Uniform commands for booting xen

[Ian Campbell <ian.campbell@citrix.com>]

On Mon, 2016-01-11 at 15:06 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 13.11.2015 10:50, Ian Campbell wrote:
> > On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
> > > > How do you express modules other than kernel+initrd in that
> > > > scheme, without grub needing to be aware of any new addition we
> > > > may find necessary going forward?
> > > > 
> > > 
> > > Are modules used by Xen self-identifying? Is it enough to simply pass
> > > Xen kernel list of binary blobs or Xen kernel must be told what these
> > > binary blobs are? If they are self identifying, why arm needs to be
> > > passed module type in the first place?
> > 
> > At first Xen/ARM required the bootloader to identify, but that was
> > since
> > identified as causing madness and fixed by having Xen/ARM do as Xen/x86
> > does and figure things out for itself, but I failed to communicate this
> > clearly and things got implemented on the grub side under the old
> > assumptions.
> > 
> This changes a lot. This removes most of hurdles towards uniformity. Are
> you ok with replacing xen_kernel/xen_xsm/... with just xen_module and
> dropping type altogether?

So ending up with xen_hypervisor followed by one or more xen_module lines?
That's fine with me. This bit:

@@ -203,15 +155,11 @@ prepare_xen_module_params (struct xen_boot_binary *module, void *xen_boot_fdt)
       grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name);
 
   retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible",
-                             module->node_info.compat_string,
-                             (grub_uint32_t) module->
-                             node_info.compat_string_size);
+                             "deprecated", sizeof("deprecated") - 1);

Seems to be changing the compatibility string of hte node to "deprecated",
which isn't right (or at least won't work). The nodes still need to be
identified as being modules per http://xenbits.xen.org/docs/unstable/misc/a
rm/device-tree/booting.txt that means "multiboot,module" (or if you insist
"xen,multiboot-module").

> Do you think that it makes sense to have xen_initrd in order to have
> in-memory initrd concatenation like baremetal counterpart? In either
> case we can add it later. I'd rather not have a command than to change
> its meaning later.

If it is useful on baremetal (and I can see that it would be) then I think
it would be useful on Xen too.

Ian.