Re: [Xen-devel] fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on SuperMicro hardware; fixes solve 1/2 problems & SM responds that can't/won't fix their firmware

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > Now attached.
> >>
> >> xen.efi /noexitboot /mapbs
> >>
> >> And you can try without 'efi=no-rs'.
> >>
> >> However I am wondering - why are you using '/mapbs' ? What did it
> >> help? (The combination of 'efi=no-rs' means you are in effect not
> >> using _any_ EFI operations - so doing /mapbs is not needed).
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxx
> >> http://lists.xen.org/xen-devel
> 
> Konrad,

Heya!!
> 
> Can we land the /noexitboot (probably better to call it /noexitbs to
> match rs) into the tree?

It is up to the EFI maintainer (Jan) who would like the vendors to
fix their broken firmware before adding this gross hack in.

> 
> I have to have a very similar patch locally to bring up my machine and
> it would make sense that if you and I are seeing this problem then
> others are.

I think the way going forward is to make Xen capable of working in the
VirtualAddress instead of the 1:1. The problem isn't fixing the code
(it blows up if you try enabling) - it is that we lose kexec support
unless we also make kexec be less Linux-centric when booting under EFI.

This is a topic I think we should bring up at the XenHackathon(Dev summit?)
in Cambridge, UK to hash out.

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