* Re: Uniform commands for booting xen
2015-11-13 7:48 ` Jan Beulich
@ 2015-11-13 9:04 ` Andrei Borzenkov
2015-11-13 9:04 ` [Xen-devel] " Andrei Borzenkov
` (2 subsequent siblings)
3 siblings, 0 replies; 33+ messages in thread
From: Andrei Borzenkov @ 2015-11-13 9:04 UTC (permalink / raw)
To: The development of GNU GRUB; +Cc: Vladimir Serbinenko, Ian Campbell, xen-devel
On Fri, Nov 13, 2015 at 10:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 12.11.15 at 18:09, <ian.campbell@citrix.com> wrote:
>> On Thu, 2015-11-12 at 08:44 -0700, Jan Beulich wrote:
>>> > > > On 12.11.15 at 14:41, <phcoder@gmail.com> 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.
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [Xen-devel] Uniform commands for booting xen
2015-11-13 7:48 ` Jan Beulich
2015-11-13 9:04 ` Andrei Borzenkov
@ 2015-11-13 9:04 ` Andrei Borzenkov
2015-11-13 9:50 ` Ian Campbell
2015-11-13 9:50 ` [Xen-devel] " Ian Campbell
2015-11-13 9:48 ` Ian Campbell
2015-11-13 9:48 ` [Xen-devel] " Ian Campbell
3 siblings, 2 replies; 33+ messages in thread
From: Andrei Borzenkov @ 2015-11-13 9:04 UTC (permalink / raw)
To: The development of GNU GRUB; +Cc: Vladimir Serbinenko, Ian Campbell, xen-devel
On Fri, Nov 13, 2015 at 10:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 12.11.15 at 18:09, <ian.campbell@citrix.com> wrote:
>> On Thu, 2015-11-12 at 08:44 -0700, Jan Beulich wrote:
>>> > > > On 12.11.15 at 14:41, <phcoder@gmail.com> 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.
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Uniform commands for booting xen
2015-11-13 9:04 ` [Xen-devel] " Andrei Borzenkov
@ 2015-11-13 9:50 ` Ian Campbell
2015-11-13 9:50 ` [Xen-devel] " Ian Campbell
1 sibling, 0 replies; 33+ messages in thread
From: Ian Campbell @ 2015-11-13 9:50 UTC (permalink / raw)
To: Andrei Borzenkov, The development of GNU GRUB
Cc: Vladimir Serbinenko, xen-devel
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.
I just replied in more detail about that to Jan's mail, so I won't repeat
myself further here.
Ian.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Xen-devel] Uniform commands for booting xen
2015-11-13 9:04 ` [Xen-devel] " Andrei Borzenkov
2015-11-13 9:50 ` Ian Campbell
@ 2015-11-13 9:50 ` Ian Campbell
2016-01-11 14:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-11 14:06 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 2 replies; 33+ messages in thread
From: Ian Campbell @ 2015-11-13 9:50 UTC (permalink / raw)
To: Andrei Borzenkov, The development of GNU GRUB
Cc: Vladimir Serbinenko, xen-devel
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.
I just replied in more detail about that to Jan's mail, so I won't repeat
myself further here.
Ian.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Uniform commands for booting xen
2015-11-13 9:50 ` [Xen-devel] " Ian Campbell
@ 2016-01-11 14:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-11 14:06 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 0 replies; 33+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-01-11 14:06 UTC (permalink / raw)
To: Ian Campbell, Andrei Borzenkov, The development of GNU GRUB
Cc: Jan Beulich, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1428 bytes --]
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?
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.
Jan, does it address your concerns?
> I just replied in more detail about that to Jan's mail, so I won't repeat
> myself further here.
>
> Ian.
>
[-- Attachment #1.1.2: xen.diff --]
[-- Type: application/x-ext-patch, Size: 11181 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Xen-devel] Uniform commands for booting xen
2015-11-13 9:50 ` [Xen-devel] " Ian Campbell
2016-01-11 14:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2016-01-11 14:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-11 14:32 ` Jan Beulich
` (3 more replies)
1 sibling, 4 replies; 33+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-01-11 14:06 UTC (permalink / raw)
To: Ian Campbell, Andrei Borzenkov, The development of GNU GRUB
Cc: Jan Beulich, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1428 bytes --]
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?
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.
Jan, does it address your concerns?
> I just replied in more detail about that to Jan's mail, so I won't repeat
> myself further here.
>
> Ian.
>
[-- Attachment #1.2: xen.diff --]
[-- Type: application/x-ext-patch, Size: 11181 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Uniform commands for booting xen
2016-01-11 14:06 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko
@ 2016-01-11 14:32 ` Jan Beulich
2016-01-11 14:32 ` [Xen-devel] " Jan Beulich
` (2 subsequent siblings)
3 siblings, 0 replies; 33+ messages in thread
From: Jan Beulich @ 2016-01-11 14:32 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: Andrei Borzenkov, The development of GNU GRUB, Ian Campbell, xen-devel
>>> On 11.01.16 at 15:06, <phcoder@gmail.com> 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?
> 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.
> Jan, does it address your concerns?
It improves things a bit, but I'd really like to not see any xen_
prefixed commands at all in grub2 - after all Xen should just be
an ordinary multiboot client.
Jan
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [Xen-devel] Uniform commands for booting xen
2016-01-11 14:06 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-11 14:32 ` Jan Beulich
@ 2016-01-11 14:32 ` Jan Beulich
2016-01-11 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-11 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-18 10:28 ` Ian Campbell
2016-01-18 10:28 ` [Xen-devel] " Ian Campbell
3 siblings, 2 replies; 33+ messages in thread
From: Jan Beulich @ 2016-01-11 14:32 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: Andrei Borzenkov, The development of GNU GRUB, Ian Campbell, xen-devel
>>> On 11.01.16 at 15:06, <phcoder@gmail.com> 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?
> 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.
> Jan, does it address your concerns?
It improves things a bit, but I'd really like to not see any xen_
prefixed commands at all in grub2 - after all Xen should just be
an ordinary multiboot client.
Jan
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Xen-devel] Uniform commands for booting xen
2016-01-11 14:32 ` [Xen-devel] " Jan Beulich
@ 2016-01-11 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-11 15:36 ` [Xen-devel] " Jan Beulich
2016-01-11 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 1 reply; 33+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-01-11 14:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Andrei Borzenkov, The development of GNU GRUB, Ian Campbell, xen-devel
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
On 11.01.2016 15:32, Jan Beulich wrote:
>>>> On 11.01.16 at 15:06, <phcoder@gmail.com> 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?
>> 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.
>> Jan, does it address your concerns?
>
> It improves things a bit, but I'd really like to not see any xen_
> prefixed commands at all in grub2 - after all Xen should just be
> an ordinary multiboot client.
>
This is true for x86 but on ARM64 the protocol xen expects is quite
different and not really multiboot. How would we avoid xen_ prefixed
commands for ARM64? And when we have them it makes sense to have them on
x86 as well so that the same set of commands works on both arm64 and x86
> Jan
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Uniform commands for booting xen
2016-01-11 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2016-01-11 15:36 ` Jan Beulich
0 siblings, 0 replies; 33+ messages in thread
From: Jan Beulich @ 2016-01-11 15:36 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: Andrei Borzenkov, The development of GNU GRUB, Ian Campbell, xen-devel
>>> On 11.01.16 at 15:58, <phcoder@gmail.com> wrote:
> On 11.01.2016 15:32, Jan Beulich wrote:
>>>>> On 11.01.16 at 15:06, <phcoder@gmail.com> 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?
>>> 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.
>>> Jan, does it address your concerns?
>>
>> It improves things a bit, but I'd really like to not see any xen_
>> prefixed commands at all in grub2 - after all Xen should just be
>> an ordinary multiboot client.
>>
> This is true for x86 but on ARM64 the protocol xen expects is quite
> different and not really multiboot. How would we avoid xen_ prefixed
> commands for ARM64? And when we have them it makes sense to have them on
> x86 as well so that the same set of commands works on both arm64 and x86
Well, if they're unavoidable on ARM then I can see avoiding them
on x86 as not as relevant. Otoh avoiding divergence from other
x86 clients might still call for them to be omitted. In the end you're
the maintainer, so you should know best.
Jan
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Xen-devel] Uniform commands for booting xen
@ 2016-01-11 15:36 ` Jan Beulich
0 siblings, 0 replies; 33+ messages in thread
From: Jan Beulich @ 2016-01-11 15:36 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko
Cc: Andrei Borzenkov, The development of GNU GRUB, Ian Campbell, xen-devel
>>> On 11.01.16 at 15:58, <phcoder@gmail.com> wrote:
> On 11.01.2016 15:32, Jan Beulich wrote:
>>>>> On 11.01.16 at 15:06, <phcoder@gmail.com> 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?
>>> 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.
>>> Jan, does it address your concerns?
>>
>> It improves things a bit, but I'd really like to not see any xen_
>> prefixed commands at all in grub2 - after all Xen should just be
>> an ordinary multiboot client.
>>
> This is true for x86 but on ARM64 the protocol xen expects is quite
> different and not really multiboot. How would we avoid xen_ prefixed
> commands for ARM64? And when we have them it makes sense to have them on
> x86 as well so that the same set of commands works on both arm64 and x86
Well, if they're unavoidable on ARM then I can see avoiding them
on x86 as not as relevant. Otoh avoiding divergence from other
x86 clients might still call for them to be omitted. In the end you're
the maintainer, so you should know best.
Jan
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Uniform commands for booting xen
2016-01-11 14:32 ` [Xen-devel] " Jan Beulich
2016-01-11 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2016-01-11 14:58 ` Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 0 replies; 33+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-01-11 14:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Andrei Borzenkov, The development of GNU GRUB, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1948 bytes --]
On 11.01.2016 15:32, Jan Beulich wrote:
>>>> On 11.01.16 at 15:06, <phcoder@gmail.com> 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?
>> 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.
>> Jan, does it address your concerns?
>
> It improves things a bit, but I'd really like to not see any xen_
> prefixed commands at all in grub2 - after all Xen should just be
> an ordinary multiboot client.
>
This is true for x86 but on ARM64 the protocol xen expects is quite
different and not really multiboot. How would we avoid xen_ prefixed
commands for ARM64? And when we have them it makes sense to have them on
x86 as well so that the same set of commands works on both arm64 and x86
> Jan
>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Uniform commands for booting xen
2016-01-11 14:06 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-11 14:32 ` Jan Beulich
2016-01-11 14:32 ` [Xen-devel] " Jan Beulich
@ 2016-01-18 10:28 ` Ian Campbell
2016-01-18 10:28 ` [Xen-devel] " Ian Campbell
3 siblings, 0 replies; 33+ messages in thread
From: Ian Campbell @ 2016-01-18 10:28 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko,
Andrei Borzenkov, The development of GNU GRUB
Cc: Jan Beulich, xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [Xen-devel] Uniform commands for booting xen
2016-01-11 14:06 ` [Xen-devel] " Vladimir 'φ-coder/phcoder' Serbinenko
` (2 preceding siblings ...)
2016-01-18 10:28 ` Ian Campbell
@ 2016-01-18 10:28 ` Ian Campbell
2016-01-22 9:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-22 9:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
3 siblings, 2 replies; 33+ messages in thread
From: Ian Campbell @ 2016-01-18 10:28 UTC (permalink / raw)
To: Vladimir 'φ-coder/phcoder' Serbinenko,
Andrei Borzenkov, The development of GNU GRUB
Cc: Jan Beulich, xen-devel
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.
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [Xen-devel] Uniform commands for booting xen
2016-01-18 10:28 ` [Xen-devel] " Ian Campbell
@ 2016-01-22 9:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
2016-01-22 9:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 0 replies; 33+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-01-22 9:14 UTC (permalink / raw)
To: Ian Campbell, Andrei Borzenkov, The development of GNU GRUB
Cc: Jan Beulich, xen-devel
[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]
On 18.01.2016 11:28, Ian Campbell wrote:
> 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").
>
Changed to "multiboot,module" and committed
>> 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.
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Uniform commands for booting xen
2016-01-18 10:28 ` [Xen-devel] " Ian Campbell
2016-01-22 9:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2016-01-22 9:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 0 replies; 33+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-01-22 9:14 UTC (permalink / raw)
To: Ian Campbell, Andrei Borzenkov, The development of GNU GRUB
Cc: Jan Beulich, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 2631 bytes --]
On 18.01.2016 11:28, Ian Campbell wrote:
> 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").
>
Changed to "multiboot,module" and committed
>> 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.
>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Uniform commands for booting xen
2015-11-13 7:48 ` Jan Beulich
2015-11-13 9:04 ` Andrei Borzenkov
2015-11-13 9:04 ` [Xen-devel] " Andrei Borzenkov
@ 2015-11-13 9:48 ` Ian Campbell
2015-11-13 9:48 ` [Xen-devel] " Ian Campbell
3 siblings, 0 replies; 33+ messages in thread
From: Ian Campbell @ 2015-11-13 9:48 UTC (permalink / raw)
To: Jan Beulich, phcoder; +Cc: The development of GRUB 2, xen-devel
On Fri, 2015-11-13 at 00:48 -0700, Jan Beulich wrote:
> > > > On 12.11.15 at 18:09, <ian.campbell@citrix.com> wrote:
> > On Thu, 2015-11-12 at 08:44 -0700, Jan Beulich wrote:
> > > > > > On 12.11.15 at 14:41, <phcoder@gmail.com> 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).
> 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?
When I initially designed[0] my intention was that grub.cfg would be
unchanged between x86 and arm and therefore that the usual "multiboot" and
"module" commands would be used, but would be backed by the FDT protocol
not actual multiboot (my logic was that multiboot1 would never be added to
ARM and multiboot2 uses different command names so there was no clash, grub
upstream had good reasons for objecting to that though).
However at that time Xen/ARM didn't do as Xen/x86 does and assume something
from the ordering of the modules (first==dom0 kernel, second==dom0 initrd,
mechanisms to scan for other types, etc). Which led to the stuff at [1]
which put the onus for this inference into the bootloader, in a rather
complex way.
I since got convinced that this was madness and implemented in Xen/ARM
similar logic to x86 (i.e. inference based on the module ordering) so that
the bootloader could just present the modules in the order the cfg has them
and Xen/ARM would DTRT for the same set of common cases as Xen/x86 would.
At this point I should have updated [0] to much simplify things, since now
a single module command would have been much simpler. But it looks like I
neglected to do so and so the complex module type inference described in
[1] morphed during review (i.e. objections to the complicated type handling
in [1]) into the current xen_{kernel,initrd,foo} stuff we have now. Sorry
for a) not updating that wiki page in a timely manner and b) not noticing
this discrepancy was occurring during review.
I think at this point for the ARM stuff we could now ditch all these
xen_{kernel,initrd,xsm} etc in favour of a single xen_module command which
doesn't automatically attempt to infer or specify the type, and just lets
Xen figure it out.
AFAICT on the grub side this would mean exposing grub_cmd_xen_module
directly as a command and dropping the uses of set_module_type and the
other aliases.
Aside: Ideally I'd like to see a simplified variant of the --type stuff
added, which just takes a raw fdt compat value to use for flexibility in
the future, but that's not critical and orthogonal to this discussion.
> 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. But yes, it's not my call decide this...
So the above would IMHO make arm64 a) more rational and b) closer to how
multiboot/x86 behaves, but I don't really think it addresses your core
concern.
In [2] Vladimir proposed three options to avoid assumption about the
machine which runs grub-mkconfig not being the one which is going to
execute grub.cfg:
- Check arch on boot time
- Check that new xen commands are supported (define a new feature)
Both of which are alternatives to the proposal for uniform commands made
here. Both have the same downside which is that the grub.cfg then becomes
if <some condition>; then
xen_hypervisor AAAA
xen_module BBB
xen_module CCC
else
multiboot AAAA
module BBB
module CCC
fi
Which is added complexity in grub.cfg and in 20_linux_xen (only the latter of which is really "user serviceable" though).
Ian.
[0] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
[1] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot#Command:_module
[2] http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00133.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [Xen-devel] Uniform commands for booting xen
2015-11-13 7:48 ` Jan Beulich
` (2 preceding siblings ...)
2015-11-13 9:48 ` Ian Campbell
@ 2015-11-13 9:48 ` Ian Campbell
3 siblings, 0 replies; 33+ messages in thread
From: Ian Campbell @ 2015-11-13 9:48 UTC (permalink / raw)
To: Jan Beulich, phcoder; +Cc: The development of GRUB 2, xen-devel
On Fri, 2015-11-13 at 00:48 -0700, Jan Beulich wrote:
> > > > On 12.11.15 at 18:09, <ian.campbell@citrix.com> wrote:
> > On Thu, 2015-11-12 at 08:44 -0700, Jan Beulich wrote:
> > > > > > On 12.11.15 at 14:41, <phcoder@gmail.com> 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).
> 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?
When I initially designed[0] my intention was that grub.cfg would be
unchanged between x86 and arm and therefore that the usual "multiboot" and
"module" commands would be used, but would be backed by the FDT protocol
not actual multiboot (my logic was that multiboot1 would never be added to
ARM and multiboot2 uses different command names so there was no clash, grub
upstream had good reasons for objecting to that though).
However at that time Xen/ARM didn't do as Xen/x86 does and assume something
from the ordering of the modules (first==dom0 kernel, second==dom0 initrd,
mechanisms to scan for other types, etc). Which led to the stuff at [1]
which put the onus for this inference into the bootloader, in a rather
complex way.
I since got convinced that this was madness and implemented in Xen/ARM
similar logic to x86 (i.e. inference based on the module ordering) so that
the bootloader could just present the modules in the order the cfg has them
and Xen/ARM would DTRT for the same set of common cases as Xen/x86 would.
At this point I should have updated [0] to much simplify things, since now
a single module command would have been much simpler. But it looks like I
neglected to do so and so the complex module type inference described in
[1] morphed during review (i.e. objections to the complicated type handling
in [1]) into the current xen_{kernel,initrd,foo} stuff we have now. Sorry
for a) not updating that wiki page in a timely manner and b) not noticing
this discrepancy was occurring during review.
I think at this point for the ARM stuff we could now ditch all these
xen_{kernel,initrd,xsm} etc in favour of a single xen_module command which
doesn't automatically attempt to infer or specify the type, and just lets
Xen figure it out.
AFAICT on the grub side this would mean exposing grub_cmd_xen_module
directly as a command and dropping the uses of set_module_type and the
other aliases.
Aside: Ideally I'd like to see a simplified variant of the --type stuff
added, which just takes a raw fdt compat value to use for flexibility in
the future, but that's not critical and orthogonal to this discussion.
> 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. But yes, it's not my call decide this...
So the above would IMHO make arm64 a) more rational and b) closer to how
multiboot/x86 behaves, but I don't really think it addresses your core
concern.
In [2] Vladimir proposed three options to avoid assumption about the
machine which runs grub-mkconfig not being the one which is going to
execute grub.cfg:
- Check arch on boot time
- Check that new xen commands are supported (define a new feature)
Both of which are alternatives to the proposal for uniform commands made
here. Both have the same downside which is that the grub.cfg then becomes
if <some condition>; then
xen_hypervisor AAAA
xen_module BBB
xen_module CCC
else
multiboot AAAA
module BBB
module CCC
fi
Which is added complexity in grub.cfg and in 20_linux_xen (only the latter of which is really "user serviceable" though).
Ian.
[0] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
[1] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot#Command:_module
[2] http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00133.html
^ permalink raw reply [flat|nested] 33+ messages in thread