Re: [Xen-devel] [PATCH for-xen-4.5 v3 00/16] xen: Break multiboot (v1) dependency and add multiboot2 support

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Thu, Oct 16, 2014 at 02:41:45PM +0100, Jan Beulich wrote:
> >>> On 16.10.14 at 14:58, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Thu, Oct 16, 2014 at 09:13:35AM +0100, Jan Beulich wrote:
> >> >>> On 08.10.14 at 19:52, <daniel.kiper@xxxxxxxxxx> wrote:
> >>
> >> Just for the record - I do not see this as warranting a release exception.
> >> The effort to get this in place was started way too late, and shouldn't
> >> be rushed close to or already beyond the feature freeze point.
> >
> > It will be nice to have it in 4.5 but I am not going to insist on it
> > so strong. Anyway, I am working on next release. I hope that I will
> > be able to send it tomorrow.
>
> Which means I can ditch the to-be-reviewed v3 patches 5...16 from
> my queue?

Yep.

> And then I'm still not really convinced that all this goes in the right
> direction. In particular I'm worried about you doing pretty invasive
> to early boot code when it's not really clear that all this need to be
> touched (and largely re-written). I'd really favor you initially working
> towards supporting MB2 without at the same time trying to abstract

I have a feeling that if we go in that direction that this strong
dependency on MB1 never would be broken.

> things to fit all of MB1, EFI, MB2, and eventually even ARM. This is
> to a good part that it's currently rather hard to see whether what
> you abstract and how are really the right items and mechanisms.

As said earlier, I think that we should break MB1 dependency first
and use this work for further MB2 development. It pays. Please, look
at patch which introduce MB2. It is very easy to do after my changes
(introducing MBD and boot_info). Just one very simple patch. We do not
even touch Xen main code! I am sure that it could be more difficult
if we try to do that on currently exiting MB1 code. I do not mention
that if we need to pass something which is not specified in MB1 then
we will be forced to pass it using side channel. Additionally, as
I showed on MB2 case it will be much easier to introduce other boot
protocols in the future if we need it. Just change preloder. There
is a small chance that we should change anything in Xen main code
(after __start_xen()).

However, I am aware of difficulties related to MB2 and EFI. Currently
I have at least two ideas how to solve that problem. More or less
we can put MB2 header and relevant code into currently generated PE
file or pack currently generated ELF file into PE header. So, this
is thing which I should dig deeper. I am going to do it soon.

Daniel

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