[PATCH 11/12] ppc64: Move fwnmi vectors into trampoline area

[Milton Miller]

Sorry for the broken threading, I only saw Michael's reply via
the web.

key:
> > Milton Miller quotes
> Michael Ellerman quotes

> >
> > 1) Addresses below 0x3000 are reserved by the (processor?) 
> architecture
> > to add interrupt vectors.  This patch might collide with them.
>
> Yeah it's reserved up to 0x3000 in the green book. My reasoning was 
> that when
> a chip comes out that uses those addresses we'll know about it and we 
> can
> move the fwmni vectors some where else, in the meantime it's just empty
> space.

By following the architecture, we have a chance of booting on CPUs that
we don't know about yet.  We also find out with a more deterministic
crash when we are slow to add support for a new feature.

Following the architecture will save us in the long run.
[success story censored]
>

> > 2) Without making sure the old and new vecotors are at the same 
> place,
> > the call may not succeed.
> >
> > 3) We are going to call rtas to register these vectors again.
> >
> > I would much prefer we test that rtas handles us calling register 
> again
> > with a different address to move the vector addresses.
>
> Do you mean the old and new vectors should be in the same place, or 
> different
> places? If they're in the same place then perhaps we don't even need to
> re-register them?


I'm saying if rtas and the hypervisor accept the new address then
we don't have to worry.  If they don't accept an address, then we
must reserve a fixed address in page 3 and only support dump of a
base kernel of some minimum level.

So let us test now if the address is accepted, and if so not worry
about a "low" vector or trampoline for these entry points.


On Aug 30, 2005, at 1:09 AM, Milton D. Miller II wrote: