[PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings whileBuilding a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled

[Alexander Graf]

On 20.07.2010, at 09:27, Milton Miller wrote:

> On Mon, 19 Jul 2010 about 14:00:56 +0200, Alexander Graf wrote:
>> Milton Miller wrote:
>>> I wrote:
>>> 
>>> Oh yea, and for book-3s, the code copies from 0x100 to __end_interrupts
>>> in arch/powerpc/kernel/exceptions-64s.h down to the real 0, but the rest
>>> of the kernel is at some disjointed address.  The interrupt will go to
>>> the copy at the real zero.  Any references to code outside that region
>>> must be done via a full indrect branch (not a relative one), simiar to
>>> the secondary startup (via following the function pointer in a descriptor
>>> set in very low memory), or syscall entry and exception vectors via paca.
>>> 
>> 
>> That would still break on normal PPC boxes, as any address accessed in
>> real mode has to be inside the RMA. And the #include for
>> kvm/book3s_rmhandlers.S happens after __end_interrupts. So I'd end up
>> with code that gets executed outside of the RMA after a relocation, right?
>> 
>> Alex
>> 
> 
> Weither its outside of the RMA or not, DO_KVM is creating a branch outside
> of code copied to lowmem.
> 
> This is BROKEN.
> 
> We have a hard limit that we can't extend _end_interrupts past 0x7000, and
> a soft limit that we can't exceed 0x6000.  If there is space, we could
> move the real mode handler extensions inside end_interrupts in
> exceptions-64s.S, and store the full address in a .quad so it gets
> relocated properly.  Don't subtract the start, we have designed the kernel
> to run with start at a VA that can be used as a EA in real mode.

Moving everything to exceptions-64s.S sounds like the best thing to do. All the code in real mode really is there so it stays inside the RMA. I don't think we can guarantee that for any code that is not copied, right?

> Otherwise we need to mark KVM_BOOK3S_64 depends on (!RELOCATABLE ||
> BROKEN) for 2.6.35 until we get fixes.

Well - it's only broken when really getting relocated. But I agree, the current state doesn't cope with Linux's relocation logic.

> I took a read though the book3s code as of 2.6.34.   A few things I noticed:
> 
> (1) The code is using slb large to control the segment size.   It should
> be using SLB B field (or just impliment 256M segments only).

I'm not sure I understand this part? We only use 256MB segments for now.

> (2) It appears that the mtspr and mfspr code is using the same storage for
> bats 4-7 as 0-3 ... I would have expected a 4 + a few places.

Yes, that one is fixed in more recent versions already.

> (3) Its not clear to me that you clear RI when transitioning to the guest
> but its obviously required because you place state in srr0 & srr1.

Uh - do I have to clear RI? I'm not prepared to take an interrupt anyways and RI is just a soft flag for Linux's handlers, right?

> (4) I don't understand why __kvmppc_vcpu_run turns on interrupts so that
> __kvmppc_vcpu_entry can turn them back off.   Something to do with
> irq trace annotations?

__kvmppc_vcpu_run turns on soft interrupts while __kvmppc_vcpu_entry turns them off in MSR. This is so that when enabling interrupts again on guest exit, we have the soft enable bit set.


Alex