[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <0D8EEF0C-CC43-4E37-B184-0D3B9BC400D1@suse.de>
Date: Tue, 20 Jul 2010 09:37:27 +0200
From: Alexander Graf <agraf@...e.de>
To: Milton Miller <miltonm@....com>
Cc: Subrata Modak <subrata@...ux.vnet.ibm.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
linux-kernel List <linux-kernel@...r.kernel.org>,
kvm-ppc@...r.kernel.org, KVM list <kvm@...r.kernel.org>
Subject: Re: [PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings whileBuilding a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists