From: cyril@ti.com (Cyril Chemparathy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 03/22] ARM: use late patch framework for phys-virt patching
Date: Sun, 12 Aug 2012 13:34:06 -0400 [thread overview]
Message-ID: <5027E90E.2000604@ti.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1208112238270.5231@xanadu.home>
On 08/11/12 23:03, Nicolas Pitre wrote:
> On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
>
>> This patch replaces the original physical offset patching implementation
>> with one that uses the newly added patching framework. In the process, we now
>> unconditionally initialize the __pv_phys_offset and __pv_offset globals in the
>> head.S code.
>
> This last sentence is now wrong.
>
Removed.
[...]
>> -extern unsigned long __pv_phys_offset;
>> -#define PHYS_OFFSET __pv_phys_offset
[...]
>> +#define PHYS_OFFSET __virt_to_phys(PAGE_OFFSET)
>
> What was wrong with the former PHYS_OFFSET = __pv_phys_offset ?
>
> If you really want to have it optimized at run time, you could simply
> use your new stub to patch a mov instruction instead of going through
> __virt_to_phys which uses and add on top of a constant.
>
The intent was to optimize out the load(s) on references to PHYS_OFFSET,
but is it worth it? If so, we could go with a patched mov (or two) with
the necessary endian fixups. If not, we could revert to
__pv_phys_offset loads as before.
[...]
>> s = find_mod_section(hdr, sechdrs, ".runtime.patch.table");
>> if (s)
>> runtime_patch((void *)s->sh_addr, s->sh_size);
>
> I missed this in the previous patch, but could you fail the module
> loading by returning an error if runtime_patch() fails? That would take
> care of not accepting modules that might have been compiled with future
> runtime patching extensions that are not yet supported in an earlier
> kernel.
>
Sure. Thanks.
> You also should remove the MODULE_ARCH_VERMAGIC_P2V definitions now that
> the corresponding code is no longer there.
>
Hmm...
"rt-patch" needs to be in vermagic to prevent modules built against the
new code from being loaded on older kernels that used the traditional
patch code.
"p2v" needs to be in there as well, because it should be possible to
build without PATCH_PHYS_VIRT, but with RUNTIME_PATCH as and when there
are other users for this.
Thanks
-- Cyril.
next prev parent reply other threads:[~2012-08-12 17:34 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-11 1:24 [PATCH v2 00/22] Introducing the TI Keystone platform Cyril Chemparathy
2012-08-11 1:24 ` [PATCH v2 01/22] ARM: add mechanism for late code patching Cyril Chemparathy
2012-08-12 2:22 ` Nicolas Pitre
2012-08-12 18:13 ` Cyril Chemparathy
2012-08-11 1:24 ` [PATCH v2 02/22] ARM: add self test for runtime patch mechanism Cyril Chemparathy
2012-08-12 2:35 ` Nicolas Pitre
2012-08-12 16:32 ` Cyril Chemparathy
2012-08-13 3:19 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 03/22] ARM: use late patch framework for phys-virt patching Cyril Chemparathy
2012-08-12 3:03 ` Nicolas Pitre
2012-08-12 17:34 ` Cyril Chemparathy [this message]
2012-08-13 3:32 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 04/22] ARM: LPAE: use phys_addr_t on virt <--> phys conversion Cyril Chemparathy
2012-08-12 3:04 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 05/22] ARM: LPAE: support 64-bit virt_to_phys patching Cyril Chemparathy
2012-08-12 3:39 ` Nicolas Pitre
2012-08-12 23:27 ` Cyril Chemparathy
2012-08-13 4:03 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 06/22] ARM: LPAE: use signed arithmetic for mask definitions Cyril Chemparathy
2012-08-12 3:57 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 07/22] ARM: LPAE: use phys_addr_t in alloc_init_pud() Cyril Chemparathy
2012-08-11 1:24 ` [PATCH v2 08/22] ARM: LPAE: use phys_addr_t in free_memmap() Cyril Chemparathy
2012-08-11 1:24 ` [PATCH v2 09/22] ARM: LPAE: use phys_addr_t for initrd location and size Cyril Chemparathy
2012-08-12 3:58 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 10/22] ARM: LPAE: use phys_addr_t in switch_mm() Cyril Chemparathy
2012-08-12 4:04 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 11/22] ARM: LPAE: use 64-bit accessors for TTBR registers Cyril Chemparathy
2012-08-12 4:11 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 12/22] ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem Cyril Chemparathy
2012-08-11 1:24 ` [PATCH v2 13/22] ARM: LPAE: factor out T1SZ and TTBR1 computations Cyril Chemparathy
2012-08-12 4:19 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 14/22] ARM: LPAE: accomodate >32-bit addresses for page table base Cyril Chemparathy
2012-08-11 1:24 ` [PATCH v2 15/22] ARM: mm: use physical addresses in highmem sanity checks Cyril Chemparathy
2012-08-12 4:29 ` Nicolas Pitre
2012-08-11 1:24 ` [PATCH v2 16/22] ARM: mm: cleanup checks for membank overlap with vmalloc area Cyril Chemparathy
2012-08-12 4:36 ` Nicolas Pitre
2012-09-10 17:43 ` Cyril Chemparathy
2012-09-10 18:07 ` Nicolas Pitre
2012-08-11 1:25 ` [PATCH v2 17/22] ARM: mm: clean up membank size limit checks Cyril Chemparathy
2012-08-11 1:25 ` [PATCH v2 18/22] ARM: add virt_to_idmap for interconnect aliasing Cyril Chemparathy
2012-08-11 1:25 ` [PATCH v2 19/22] ARM: recreate kernel mappings in early_paging_init() Cyril Chemparathy
2012-08-11 1:25 ` [RFC v2 21/22] ARM: keystone: enable SMP on Keystone machines Cyril Chemparathy
2012-08-11 1:25 ` [RFC v2 22/22] ARM: keystone: add switch over to high physical address range Cyril Chemparathy
2012-08-11 1:26 ` [RFC v2 20/22] ARM: keystone: introducing TI Keystone platform Cyril Chemparathy
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=5027E90E.2000604@ti.com \
--to=cyril@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).