All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org
Subject: Re: [PATCH 3/3] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t
Date: Mon, 18 Apr 2016 18:32:58 +0800	[thread overview]
Message-ID: <20160418103258.GE3602@x1.redhat.com> (raw)
In-Reply-To: <20160418083601.GY19428@n2100.arm.linux.org.uk>

On 04/18/16 at 09:36am, Russell King - ARM Linux wrote:
> On Mon, Apr 18, 2016 at 01:38:20PM +0800, Baoquan He wrote:
> > On 04/14/16 at 09:00pm, Russell King wrote:
> > > On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> > > 4GB physical on 32-bit architectures, so we need a wider type than
> > > "unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
> > > a phys_addr_t, thereby allowing it to be located above 4GB.
> > 
> > At first glance, it sounds great. But I can't imagine a scenario where
> > on pae system kernel can be located above 4G. As far as I know i386 and
> > its pae can't do this because the current linux VM implementation can't
> > allow that. I am not familiar with arm system. So please correct me if
> > I was wrong.
> 
> You are wrong.  That's precisely why this patch exists.

I don't know arm is different then i386. On i386 the kernel text mapping
is linear, just as follow:

#define __phys_addr_nodebug(x)  ((x) - PAGE_OFFSET)


But arm seems not linear. 
static inline phys_addr_t __virt_to_phys(unsigned long x)
{
        phys_addr_t t;

        if (sizeof(phys_addr_t) == 4) {
                __pv_stub(x, t, "add", __PV_BITS_31_24);
        } else {
                __pv_stub_mov_hi(t);
                __pv_add_carry_stub(x, t);
        }
        return t;
}

So on arm PAE this change makes sense.

Besides, I checked kexec/arch/arm/kexec-zImage-arm.c and found function
locate_hole() is used to find position for arm kernel. 

unsigned long locate_hole(struct kexec_info *info,
        unsigned long hole_size, unsigned long hole_align,
        unsigned long hole_min, unsigned long hole_max, 
        int hole_end)

The type unsigned long for hole_max limit the region where arm kernel is
loaded. So withough modifying this I doubt arm PAE can really be loaded
above 4G.

Thanks
Baoquan

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org
Subject: Re: [PATCH 3/3] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t
Date: Mon, 18 Apr 2016 10:32:58 +0000	[thread overview]
Message-ID: <20160418103258.GE3602@x1.redhat.com> (raw)
In-Reply-To: <20160418083601.GY19428@n2100.arm.linux.org.uk>

On 04/18/16 at 09:36am, Russell King - ARM Linux wrote:
> On Mon, Apr 18, 2016 at 01:38:20PM +0800, Baoquan He wrote:
> > On 04/14/16 at 09:00pm, Russell King wrote:
> > > On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> > > 4GB physical on 32-bit architectures, so we need a wider type than
> > > "unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
> > > a phys_addr_t, thereby allowing it to be located above 4GB.
> > 
> > At first glance, it sounds great. But I can't imagine a scenario where
> > on pae system kernel can be located above 4G. As far as I know i386 and
> > its pae can't do this because the current linux VM implementation can't
> > allow that. I am not familiar with arm system. So please correct me if
> > I was wrong.
> 
> You are wrong.  That's precisely why this patch exists.

I don't know arm is different then i386. On i386 the kernel text mapping
is linear, just as follow:

#define __phys_addr_nodebug(x)  ((x) - PAGE_OFFSET)


But arm seems not linear. 
static inline phys_addr_t __virt_to_phys(unsigned long x)
{
        phys_addr_t t;

        if (sizeof(phys_addr_t) = 4) {
                __pv_stub(x, t, "add", __PV_BITS_31_24);
        } else {
                __pv_stub_mov_hi(t);
                __pv_add_carry_stub(x, t);
        }
        return t;
}

So on arm PAE this change makes sense.

Besides, I checked kexec/arch/arm/kexec-zImage-arm.c and found function
locate_hole() is used to find position for arm kernel. 

unsigned long locate_hole(struct kexec_info *info,
        unsigned long hole_size, unsigned long hole_align,
        unsigned long hole_min, unsigned long hole_max, 
        int hole_end)

The type unsigned long for hole_max limit the region where arm kernel is
loaded. So withough modifying this I doubt arm PAE can really be loaded
above 4G.

Thanks
Baoquan

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2016-04-18 10:33 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 19:59 [PATCH 0/3] Initial Kexec patches Russell King - ARM Linux
2016-04-14 19:59 ` Russell King - ARM Linux
2016-04-14 19:59 ` Russell King - ARM Linux
2016-04-14 20:00 ` [PATCH 1/3] kexec: don't invoke OOM-killer for control page allocation Russell King
2016-04-14 20:00   ` Russell King
2016-04-18  5:32   ` Baoquan He
2016-04-18  5:32     ` Baoquan He
2016-04-18  8:39     ` Russell King - ARM Linux
2016-04-18  8:39       ` Russell King - ARM Linux
2016-04-18 10:12       ` Baoquan He
2016-04-18 10:12         ` Baoquan He
2016-04-28  9:53         ` Baoquan He
2016-04-28  9:53           ` Baoquan He
2016-04-14 20:00 ` [PATCH 2/3] kexec: ensure user memory sizes do not wrap Russell King
2016-04-14 20:00   ` Russell King
2016-04-18  5:35   ` Baoquan He
2016-04-18  5:35     ` Baoquan He
2016-04-18  8:37     ` Russell King - ARM Linux
2016-04-18  8:37       ` Russell King - ARM Linux
2016-04-18 10:17       ` Baoquan He
2016-04-18 10:17         ` Baoquan He
2016-04-28  9:56   ` Baoquan He
2016-04-28  9:56     ` Baoquan He
2016-04-28 11:07   ` Minfei Huang
2016-04-28 11:07     ` Minfei Huang
2016-04-28 12:22     ` Russell King - ARM Linux
2016-04-28 12:22       ` Russell King - ARM Linux
2016-04-29  9:32       ` Minfei Huang
2016-04-29  9:32         ` Minfei Huang
2016-04-29  9:30         ` Russell King - ARM Linux
2016-04-29  9:30           ` Russell King - ARM Linux
2016-04-29 10:45           ` Minfei Huang
2016-04-29 10:45             ` Minfei Huang
2016-04-14 20:00 ` [PATCH 3/3] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t Russell King
2016-04-14 20:00   ` Russell King
2016-04-18  5:38   ` Baoquan He
2016-04-18  5:38     ` Baoquan He
2016-04-18  8:36     ` Russell King - ARM Linux
2016-04-18  8:36       ` Russell King - ARM Linux
2016-04-18 10:32       ` Baoquan He [this message]
2016-04-18 10:32         ` Baoquan He
2016-04-18 10:52         ` Russell King - ARM Linux
2016-04-18 10:52           ` Russell King - ARM Linux
2016-04-18 11:28           ` Baoquan He
2016-04-18 11:28             ` Baoquan He
2016-04-28  8:56             ` Russell King - ARM Linux
2016-04-28  8:56               ` Russell King - ARM Linux
2016-04-28  9:59   ` Baoquan He
2016-04-28  9:59     ` Baoquan He

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=20160418103258.GE3602@x1.redhat.com \
    --to=bhe@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=fenghua.yu@intel.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=tony.luck@intel.com \
    /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.