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

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Fri, Nov 13, 2015 at 10:48 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 12.11.15 at 18:09, <ian.campbell@xxxxxxxxxx> wrote:
>> On Thu, 2015-11-12 at 08:44 -0700, Jan Beulich wrote:
>>> > > > On 12.11.15 at 14:41, <phcoder@xxxxxxxxx> wrote:
>>> > Hello, all. I'd like to have set of commands that would boot xen on all
>>> > platforms. I thought of following set:
>>> >
>>> > xen_hypervisor FILE XEN_OPTIONS
>>> > xen_kernel FILE KERNEL_OPTIONS
>>> > xen_initrd INITRD INITRD INITRD
>>> > all initrds are concatenated.
>>> > xen_xsm ???
>>>
>>> xen_ucode (and we might add more going forward). I don't see
>>> why the multiboot mechanism (kernel plus any number of modules)
>>> can't be used, without adding any Xen-specific directives.
>>
>> You likely aren't aware that on ARM Xen doesn't boot via multiboot, but via
>> a protocol which involves passing modules in an fdt[0].
>>
>> I had originally hoped that this would use the same command names in the
>> grub cfg, such that things would just work, however the grub maintainers
>> didn't like that (and I appreciate why).
>>
>> Hence on grub/ARM we already have xen_{hypervisor,kernel,initrd,...}.
>>
>> The question then is what grub-mkconfig (or more precisely
>> /etc/grub.d/20_linux_xen) ought to emit so that things just work on all
>> architectures.
>>
>> The author of the grub/ARM/Xen patches initially made it generate the xen_*
>> namas for arm and the multiboot names for x86, here is Vladimir's feedback
>> on that: http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00133.html
>>
>> Which I think gets us to approximately today and Vladimir's question.
>
> Now that makes the situation really ugly (and supports my
> reservations regarding grub2 as a uniform solution for everything).

Well, if you want uniform solution for everything why not simply
implement uniform boot protocol everywhere?

> 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?

> I think any architecture following a well defined, cross-arch
> protocol (like multiboot) should not require any special xen_*
> directives. If ARM64 needs Xen to be treated specially, special
> directives are maybe warranted for this particular case, but I don't
> see why all architectures supporting Xen should then automatically
> have to use those too.

So we can have common grub.cfg that does not depend on each platform
peculiarities and can be reused everywhere. Exactly so that grub could
be uniform solution for everything.

Let's face it. Bootloader obviously must be aware of any changes in
boot protocol requires for a kernel. If (Xen) boot protocol does any
addition, bootloader (GRUB) obviously must implement this addition. As
soon as it needs to implement it for at least one supported arch - it
will automatically be available on every other Xen platform. So it
does not really cost anything (and you can continue to use "module" on
multiboot complying platforms anyway).

Because we already have precedent of using incompatible Xen boot
protocol on different architectures, we try to find uniform solution
that covers everything. Give us protocol that does not require
knowledge of module type everywhere and we will use. But so far you
just shoot the messenger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel