Re: Uniform commands for booting xen

Re: Uniform commands for booting xen

[Jan Beulich]

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

Jan

> On arm64 it would use the arm64 xen FDT protocol but on x86 should we
> use multiboot2 if multiboot2 header is present and multiboot otherwise?
> Or do xen devs have other preferences?

Re: Uniform commands for booting xen

[Andrew Cooper]

On 12/11/15 15:44, 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.

I also don't see why multiple directives are necessary or useful.

All that matters is that the xen binary gets started at any of its
optional entry points, and that there are one or more modules loaded.

~Andrew

Re: Uniform commands for booting xen

[Andrei Borzenkov]

12.11.2015 18:44, Jan Beulich пишет:
>>>> 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.
>

Loader commands traditionally reflected underlying protocol. Using 
multiboot command in this case would be confusing as this is not 
multiboot. But I agree that it is becoming ridiculous. Probably

xen_kernel
xen_module

would be enough.

> Jan
>
>> On arm64 it would use the arm64 xen FDT protocol but on x86 should we
>> use multiboot2 if multiboot2 header is present and multiboot otherwise?
>> Or do xen devs have other preferences?
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


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

Re: Uniform commands for booting xen

[Jan Beulich]

>>> On 12.11.15 at 17:58, <arvidjaar@gmail.com> wrote:
> 12.11.2015 18:44, Jan Beulich пишет:
>>>>> 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.
>>
> 
> Loader commands traditionally reflected underlying protocol. Using 
> multiboot command in this case would be confusing as this is not 
> multiboot.

Why would it not be multiboot?

Jan

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

Re: Uniform commands for booting xen

[Andrei Borzenkov]

12.11.2015 20:08, Jan Beulich пишет:
>>>> On 12.11.15 at 17:58, <arvidjaar@gmail.com> wrote:
>> 12.11.2015 18:44, Jan Beulich пишет:
>>>>>> 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.
>>>
>>
>> Loader commands traditionally reflected underlying protocol. Using
>> multiboot command in this case would be confusing as this is not
>> multiboot.
>
> Why would it not be multiboot?
>

It is multiboot on x86 but it is something different on arm64; or did I 
misunderstand something?

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

Re: Uniform commands for booting xen

[Ian Campbell]

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.

Ian.

[0] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot

> 
> Jan
> 
> > On arm64 it would use the arm64 xen FDT protocol but on x86 should we
> > use multiboot2 if multiboot2 header is present and multiboot otherwise?
> > Or do xen devs have other preferences?
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: Uniform commands for booting xen

[Jan Beulich]

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

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

Jan

Re: Uniform commands for booting xen

[Andrei Borzenkov]

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.

Re: Uniform commands for booting xen

[Ian Campbell]

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

Re: Uniform commands for booting xen

[Ian Campbell]

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.

Re: Uniform commands for booting xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Re: Uniform commands for booting xen

[Jan Beulich]

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

Re: Uniform commands for booting xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Re: Uniform commands for booting xen

[Jan Beulich]

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

Re: Uniform commands for booting xen

[Ian Campbell]

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

Re: Uniform commands for booting xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Uniform commands for booting xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 445 bytes --]

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

On arm64 it would use the arm64 xen FDT protocol but on x86 should we
use multiboot2 if multiboot2 header is present and multiboot otherwise?
Or do xen devs have other preferences?


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