All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki Poulose <suzuki@in.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux ppc dev <linuxppc-dev@lists.ozlabs.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] Kexec support for PPC440x
Date: Wed, 29 Jun 2011 11:08:07 +0530	[thread overview]
Message-ID: <4E0ABA3F.5040809@in.ibm.com> (raw)
In-Reply-To: <4DE8E746.2080100@linutronix.de>

On 06/03/11 19:23, Sebastian Andrzej Siewior wrote:
> Suzuki Poulose wrote:
>>>> The way you setup the 1:1 mapping should be close to what you are doing on
>>>> kernel entry.Isn't it possible to include the file here and in the entry
>>>> code?
>>
>>> I will make this change and resend the patch.
>>
>> I took a look at the way we do it at kernel entry. It looks more cleaner to leave
>> it untouched. Especially, when we add the support for 47x in the future, the code
>> will become more unreadable.
>>
>> What do you think ?
>
> So the entry code has one 256MiB mapping, you need 8 of those. Entry goes for TLB 63 and you need to be flexible and avoid TLB 63 :).
> So after all you don't have that much in common with the entry code. If
> you look at the FSL-book code then you will notice that I tried to share
> some code.
>
> I don't understand why you don't flip the address space bit. On fsl we
> setup the tmp mapping in the "other address" space so we don't have two
> mappings for the same address. The entry code could be doing this with STS
> bit, I'm not sure.

I am not sure if I understood this correctly.
Could you explain how could there be two mappings for the same address ?
We are setting up 1:1 mapping for 0-2GiB and the only mapping that could exist
(in other words, not invalidated) is PAGE_OFFSET mapping. Since PAGE_OFFSET < 2GiB
we won't have multiple mappings. Or in other words we could limit KEXEC_*_MEMORY_LIMIT
to PAGE_OFFSET to make sure the crossing doesn't occur.

The kernel entry code sets up the mapping without a tmp mapping in 44x. i.e, it uses
the mapping setup by the firmware/boot loader.

Thanks
Suzuki

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Suzuki Poulose <suzuki@in.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux ppc dev <linuxppc-dev@lists.ozlabs.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] Kexec support for PPC440x
Date: Wed, 29 Jun 2011 11:08:07 +0530	[thread overview]
Message-ID: <4E0ABA3F.5040809@in.ibm.com> (raw)
In-Reply-To: <4DE8E746.2080100@linutronix.de>

On 06/03/11 19:23, Sebastian Andrzej Siewior wrote:
> Suzuki Poulose wrote:
>>>> The way you setup the 1:1 mapping should be close to what you are doing on
>>>> kernel entry.Isn't it possible to include the file here and in the entry
>>>> code?
>>
>>> I will make this change and resend the patch.
>>
>> I took a look at the way we do it at kernel entry. It looks more cleaner to leave
>> it untouched. Especially, when we add the support for 47x in the future, the code
>> will become more unreadable.
>>
>> What do you think ?
>
> So the entry code has one 256MiB mapping, you need 8 of those. Entry goes for TLB 63 and you need to be flexible and avoid TLB 63 :).
> So after all you don't have that much in common with the entry code. If
> you look at the FSL-book code then you will notice that I tried to share
> some code.
>
> I don't understand why you don't flip the address space bit. On fsl we
> setup the tmp mapping in the "other address" space so we don't have two
> mappings for the same address. The entry code could be doing this with STS
> bit, I'm not sure.

I am not sure if I understood this correctly.
Could you explain how could there be two mappings for the same address ?
We are setting up 1:1 mapping for 0-2GiB and the only mapping that could exist
(in other words, not invalidated) is PAGE_OFFSET mapping. Since PAGE_OFFSET < 2GiB
we won't have multiple mappings. Or in other words we could limit KEXEC_*_MEMORY_LIMIT
to PAGE_OFFSET to make sure the crossing doesn't occur.

The kernel entry code sets up the mapping without a tmp mapping in 44x. i.e, it uses
the mapping setup by the firmware/boot loader.

Thanks
Suzuki

WARNING: multiple messages have this Message-ID (diff)
From: Suzuki Poulose <suzuki@in.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	linux ppc dev <linuxppc-dev@lists.ozlabs.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] Kexec support for PPC440x
Date: Wed, 29 Jun 2011 11:08:07 +0530	[thread overview]
Message-ID: <4E0ABA3F.5040809@in.ibm.com> (raw)
In-Reply-To: <4DE8E746.2080100@linutronix.de>

On 06/03/11 19:23, Sebastian Andrzej Siewior wrote:
> Suzuki Poulose wrote:
>>>> The way you setup the 1:1 mapping should be close to what you are doing on
>>>> kernel entry.Isn't it possible to include the file here and in the entry
>>>> code?
>>
>>> I will make this change and resend the patch.
>>
>> I took a look at the way we do it at kernel entry. It looks more cleaner to leave
>> it untouched. Especially, when we add the support for 47x in the future, the code
>> will become more unreadable.
>>
>> What do you think ?
>
> So the entry code has one 256MiB mapping, you need 8 of those. Entry goes for TLB 63 and you need to be flexible and avoid TLB 63 :).
> So after all you don't have that much in common with the entry code. If
> you look at the FSL-book code then you will notice that I tried to share
> some code.
>
> I don't understand why you don't flip the address space bit. On fsl we
> setup the tmp mapping in the "other address" space so we don't have two
> mappings for the same address. The entry code could be doing this with STS
> bit, I'm not sure.

I am not sure if I understood this correctly.
Could you explain how could there be two mappings for the same address ?
We are setting up 1:1 mapping for 0-2GiB and the only mapping that could exist
(in other words, not invalidated) is PAGE_OFFSET mapping. Since PAGE_OFFSET < 2GiB
we won't have multiple mappings. Or in other words we could limit KEXEC_*_MEMORY_LIMIT
to PAGE_OFFSET to make sure the crossing doesn't occur.

The kernel entry code sets up the mapping without a tmp mapping in 44x. i.e, it uses
the mapping setup by the firmware/boot loader.

Thanks
Suzuki

  reply	other threads:[~2011-06-29  5:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-30  7:22 [RFC][PATCH] Kexec support for PPC440x Suzuki Poulose
2011-05-30  7:22 ` Suzuki Poulose
2011-05-30  7:22 ` Suzuki Poulose
2011-05-31 15:15 ` Sebastian Andrzej Siewior
2011-05-31 15:15   ` Sebastian Andrzej Siewior
2011-05-31 15:15   ` Sebastian Andrzej Siewior
2011-06-02  6:34   ` Suzuki Poulose
2011-06-02  6:34     ` Suzuki Poulose
2011-06-02  6:34     ` Suzuki Poulose
2011-06-03 11:50     ` Suzuki Poulose
2011-06-03 11:50       ` Suzuki Poulose
2011-06-03 11:50       ` Suzuki Poulose
2011-06-03 13:53       ` Sebastian Andrzej Siewior
2011-06-03 13:53         ` Sebastian Andrzej Siewior
2011-06-03 13:53         ` Sebastian Andrzej Siewior
2011-06-29  5:38         ` Suzuki Poulose [this message]
2011-06-29  5:38           ` Suzuki Poulose
2011-06-29  5:38           ` Suzuki Poulose
2011-06-02  7:25   ` Benjamin Herrenschmidt
2011-06-02  7:25     ` Benjamin Herrenschmidt
2011-06-02  7:25     ` Benjamin Herrenschmidt
2011-06-02  7:30     ` Suzuki Poulose
2011-06-02  7:30       ` Suzuki Poulose
2011-06-02  7:30       ` Suzuki Poulose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E0ABA3F.5040809@in.ibm.com \
    --to=suzuki@in.ibm.com \
    --cc=bigeasy@linutronix.de \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.