Re: New Xen boot infrastructure proposal

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

On Wed, 2013-05-22 at 18:19 +0200, Daniel Kiper wrote:
> On Wed, May 22, 2013 at 04:41:31PM +0100, Ian Campbell wrote:
> 
> [...]
> 
> > In that case my question (which I think others have raised) is why does
> > this need to be a complex extensible protocol at all? The two halves
> > here must surely be upgraded in sync and so both sides can be changed
> > whenever the data needs expanding. i.e. this is just struct boot_info,
> > which perhaps contains "struct arch_boot_info arch;"
> >
> > Or perhaps I've just read more into what you are proposing than you were
> > actually proposing.
> 
> MBI structure which is passed to __start_xen() is strictly defined and
> could not be changed. It worked very nice once but now it is not true.
> It does not have enough place to pass eny extra information from other
> bootloaders (in this case multiboot2 protocol aware) and there are some
> members which are not used. In that case we must have e.g. global variables
> or other solution to pass that extra info. That is why I think we should
> build new struture which will replace MBI.

"... replace Xen's internal use of MBI" would be a way of putting this
which is less prone to misunderstandings, I think ;-)

>  It should have only data which
> is used by Xen. This way we could add in the future any extra members if we
> require it and we would not be so strictly bound to any boot protocol.

Yes, this sounds sane.

> However, I do not insist on the split between arch dependent and
> independent stuff. I know this is disputable. However, I posted
> that idea because I was not sure that soultion will fit.
> I just wanted to dicuss pros and cons of this split too.

I think you've set requirements (extensibility etc) which aren't
actually required and this gave (at least me) the impression that this
was something much more far reaching than it actually is. I suggest
making it as simple as possible, basically a single struct, perhaps
containing arch specific struct, although the single struct may actually
be arch specific anyway.

I'm not actually sure how useful this will be on ARM where we don't have
the problem of passing stuff from real mode to protected mode (because
you can only call the BIOS/bootloader routines from real mode). On ARM
we already have struct dt_early_info which despite the name isn't at all
specific to DT and is more than sufficient for our current needs. We
will obviously just extend that as need be. I'd be happy to move that
into an ARM specific place and then x86 could do its own thing too.

Ian.