From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for 64 bit physical addresses
Date: Thu, 25 Jul 2013 14:53:53 -0400 [thread overview]
Message-ID: <51F17441.3000503@ti.com> (raw)
In-Reply-To: <51F0A051.20203@ti.com>
On Wednesday 24 July 2013 11:49 PM, Sricharan R wrote:
> Hi Nicolas,
>
> On Thursday 25 July 2013 01:51 AM, Nicolas Pitre wrote:
[..]
>> I don't think I follow you here.
>>
>> Let's assume:
>>
>> phys_addr_t __pv_offset = PHYS_START - VIRT_START;
>>
>> If PA = 0x0-8000-0000 and VA = 0xc000-0000 then
>> __pv_offset = 0xffff-ffff-c000-0000.
>>
>> If PA = 0x2-8000-0000 and VA = 0xc000-0000 then
>> __pv_offset = 0x1-c000-0000.
>>
>> So the __virt_to_phys() assembly stub could look like:
>>
>> static inline phys_addr_t __virt_to_phys(unsigned long x)
>> {
>> phys_addr_t t;
>>
>> if if (sizeof(phys_addr_t) == 4) {
>> __pv_stub(x, t, "add", __PV_BITS_31_24);
>> } else {
>> __pv_movhi_stub(t);
>> __pv_add_carry_stub(x, t);
>> }
>>
>> return t;
>> }
>>
>> And...
>>
>> #define __pv_movhi_stub(y) \
>> __asm__("@ __pv_movhi_stub\n" \
>> "1: mov %R0, %1\n" \
>> " .pushsection .pv_table,\"a\"\n" \
>> " .long 1b\n" \
>> " .popsection\n" \
>> : "=r" (y) \
>> : "I" (__PV_BITS_8_0))
>>
>> #define __pv_add_carry_stub(x, y) \
>> __asm__("@ __pv_add_carry_stub\n" \
>> "1: adds %Q0, %1, %2\n" \
>> " adc %R0, %R0, #0\n" \
>> " .pushsection .pv_table,\"a\"\n" \
>> " .long 1b\n" \
>> " .popsection\n" \
>> : "+r" (y) \
>> : "r" (x), "I" (__PV_BITS_31_24) \
>> : "cc")
>>
>> The stub bits such as __PV_BITS_8_0 can be augmented with more bits in
>> the middle to determine the type of fixup needed. The fixup code would
>> determine the shift needed on the value, and whether or not the low or
>> high word of __pv_offset should be used according to those bits.
>>
>> Then, in the case where a mov is patched, you need to check if the high
>> word of __pv_offset is 0xffffffff and if so the mov should be turned
>> into a "mvn rn, #0".
>>
>> And there you are with all possible cases handled.
>>
Brilliant !!
We knew you will have some tricks and better way. We were
not convinced with the extra stub for 'mov' but also didn't
have idea to avoid it.
> Thanks and you have given the full details here.
>
> Sorry if i was not clear on my previous response.
>
> 1) When i said special case can be avoided, i meant that
> we need not differentiate the 0xfffffff case inside the
> __virt_to_phy macro, but can handle it at the time of patching.
> Your above code makes that clear.
>
> 2) I would have ended creating separate tables for 'mov' and 'add'
> case. But again thanks to your above idea of augumenting the
> __PV_BITS, with which we can find out run time. And 'mvn' would
> be needed for moving '0xffffffff' . Now I can get rid
> of the separate section that i created for 'mov' in my previous
> version.
>
We also get rid of calling separate patching for modules as well
as late patching. Overall the patch-set becomes smaller and
simpler. Thanks for help.
Regards,
Santosh
next prev parent reply other threads:[~2013-07-25 18:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-21 23:48 [PATCH 0/8] ARM: mm: Extend the runtime patch stub for PAE systems Santosh Shilimkar
2013-06-21 23:48 ` [PATCH 1/8] ARM: mm: LPAE: use phys_addr_t appropriately in p2v and v2p conversions Santosh Shilimkar
2013-07-22 15:03 ` Nicolas Pitre
2013-06-21 23:48 ` [PATCH 2/8] ARM: mm: Introduce virt_to_idmap() with an arch hook Santosh Shilimkar
2013-06-21 23:48 ` [PATCH 3/8] ARM: mm: Move the idmap print to appropriate place in the code Santosh Shilimkar
2013-06-21 23:48 ` [PATCH 4/8] ARM: mm: Pass the constant as an argument to fixup_pv_table() Santosh Shilimkar
2013-06-21 23:48 ` [PATCH 5/8] ARM: mm: Add __pv_stub_mov to patch MOV instruction Santosh Shilimkar
2013-06-21 23:48 ` [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for 64 bit physical addresses Santosh Shilimkar
2013-07-24 1:10 ` Nicolas Pitre
2013-07-24 2:01 ` Santosh Shilimkar
2013-07-24 2:49 ` Nicolas Pitre
2013-07-24 11:50 ` Sricharan R
2013-07-24 12:07 ` Sricharan R
2013-07-24 14:04 ` Santosh Shilimkar
2013-07-24 20:21 ` Nicolas Pitre
2013-07-25 3:49 ` Sricharan R
2013-07-25 18:53 ` Santosh Shilimkar [this message]
2013-06-21 23:48 ` [PATCH 7/8] ARM: mm: Recreate kernel mappings in early_paging_init() Santosh Shilimkar
2013-06-21 23:48 ` [PATCH 8/8] ARM: keystone: Switch over to high physical address range Santosh Shilimkar
2013-06-22 1:51 ` [PATCH 0/8] ARM: mm: Extend the runtime patch stub for PAE systems Nicolas Pitre
2013-06-22 2:17 ` Santosh Shilimkar
2013-07-16 18:42 ` Santosh Shilimkar
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=51F17441.3000503@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).