To circumvent an issue where placing the relocations inside the init
sections produces empty relocations, use --emit-relocs. But to avoid
carrying those relocations in vmlinux, use an intermediate
vmlinux.relocs file which is a copy of vmlinux *before* stripping its
relocations.
Suggested-by:
From: Alexandre Ghiti
Relocating kernel at runtime is done very early in the boot process, so
it is not convenient to check for relocations there and react in case a
relocation was not expected.
There exists a script in scripts/ that extracts the relocations from
vmlinux that is then used at
From: Alexandre Ghiti
Relocating kernel at runtime is done very early in the boot process, so
it is not convenient to check for relocations there and react in case a
relocation was not expected.
Powerpc architecture has a script that allows to check at compile time
for such unexpected
This config allows to compile 64b kernel as PIE and to relocate it at
any virtual address at runtime: this paves the way to KASLR.
Runtime relocation is possible since relocation metadata are embedded into
the kernel.
Note that relocating at runtime introduces an overhead even if the
kernel is
This is a preparatory patch for relocatable kernels: .rela.dyn should be
in .init but doing so actually produces empty relocations, so this should
be a temporary commit until we find a solution.
This issue was reported here [1].
[1]
ld does not handle relocations correctly as explained here [1],
a fix for that was proposed by Nelson there but we have to support older
toolchains and then provide this fix.
Note that llvm does not need this fix and is then excluded.
[1]
After multiple attempts, this patchset is now based on the fact that the
64b kernel mapping was moved outside the linear mapping.
The first patch allows to build relocatable kernels but is not selected
by default. That patch is a requirement for KASLR.
The second and third patches take advantage
kernel test robot writes:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
> branch HEAD: c827c932c00ccd231a73da9816a51ce2c2b557d6 powerpc: Use
> of_address_to_resource()
>
> Error/Warning reports:
>
>
From: Anshuman Khandual
The entire scheme of deferred TLB flush in reclaim path rests on the
fact that the cost to refill TLB entries is less than flushing out
individual entries by sending IPI to remote CPUs. But architecture
can have different ways to evaluate that. Hence apart from checking
From: Barry Song
on x86, batched and deferred tlb shootdown has lead to 90%
performance increase on tlb shootdown. on arm64, HW can do
tlb shootdown without software IPI. But sync tlbi is still
quite expensive.
Even running a simplest program which requires swapout can
prove this is true,
From: Yicong Yang
Though ARM64 has the hardware to do tlb shootdown, the hardware
broadcasting is not free.
A simplest micro benchmark shows even on snapdragon 888 with only
8 cores, the overhead for ptep_clear_flush is huge even for paging
out one page mapped by only one process:
5.36% a.out
Jiaxun Yang writes:
> As for now all arches have dma_default_coherent reflecting default
> DMA coherency for of devices, so there is no need to have a standalone
> config option.
>
> Signed-off-by: Jiaxun Yang
> ---
> v3: Squash setting ARCH_DMA_DEFAULT_COHERENT into this patch.
> ---
>
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
branch HEAD: c827c932c00ccd231a73da9816a51ce2c2b557d6 powerpc: Use
of_address_to_resource()
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202303240411.tq2tzkig-...@intel.com
Error/Warning:
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: 0f98241d5ef5c3bb4c5ca07ceee3a825d7fd Automatic merge of
'fixes' into merge (2023-03-28 23:32)
elapsed time: 741m
configs tested: 43
configs skipped: 3
The following configs have been built
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
topic/ppc-kvm
branch HEAD: 5f4f53d28cde2cc7be96f657229c8603da578500 KVM: PPC: Book3S HV:
kvmppc_hv_entry: remove .global scope
elapsed time: 741m
configs tested: 2
configs skipped: 163
The following configs have
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: fd7276189450110ed835eb0a334e62d2f1c4e3be powerpc: Don't try to
copy PPR for task with NULL pt_regs
elapsed time: 742m
configs tested: 7
configs skipped: 163
The following configs have been
Add a helper, of_property_read_reg(), to read "reg" entries untranslated
address and size. This function is intended mainly for cases with an
untranslatable "reg" address (i.e. not MMIO). There's also a few
translatable cases such as address cells containing a bus chip-select
number.
While there are tests for "dma-ranges" helpers, "ranges" is missing any
tests. It's the same underlying code, but for completeness add a test
for "ranges" parsing iterators. This is in preparation to add some
additional "ranges" helpers.
Signed-off-by: Rob Herring
---
drivers/of/unittest.c | 53
There's a few custom bus bindings (e.g. fsl,qoriq-mc) which use a
3 cell format with custom flags in the high cell. We can match these
buses as a fallback if we didn't match on PCI bus which is the only
standard bus binding with 3 address cells.
Signed-off-by: Rob Herring
---
A few users need to convert a specific "ranges" entry into a struct
resource. Add a helper to similar to of_address_to_resource(). The
existing of_pci_range_to_resource() helper isn't really PCI specific,
so it can be used with the CONFIG_PCI check dropped.
Signed-off-by: Rob Herring
---
eletions(-)
---
base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
change-id: 20230328-dt-address-helpers-2f00c5c1eba4
Best regards,
--
Rob Herring
Some users need a count of the number of ranges entries before
iterating over the entries. Typically this is for allocating some data
structure based on the size. Add a helper, of_range_count(), to get the
count. The helper must be called with an struct of_range_parser
initialized by
[+cc linux-pci, more error handling folks; beginning of thread at
https://lore.kernel.org/all/20230323213808.398039-1-terry.bow...@amd.com/]
On Mon, Mar 27, 2023 at 11:51:39PM +0200, Robert Richter wrote:
> On 24.03.23 17:36:56, Bjorn Helgaas wrote:
> > > The CXL device driver is then
On 3/28/23 6:51?AM, Michael Ellerman wrote:
> Jens Axboe writes:
Can the queueing cause the creation of an IO thread (if one does not
exist, or all blocked?)
>>>
>>> Yep
>>>
>>> Since writing this email, I've gone through a lot of different tests.
>>> Here's a rough listing of what I
On Tue, Mar 28, 2023 at 4:30 AM Kajol Jain wrote:
>
> Commit 3c22ba524304 ("perf vendor events powerpc: Update POWER9 events")
> added and updated power9 pmu json events. However some of the json
> events which are part of other.json and pipeline.json files,
> contains UTF-8 characters in their
On 3/28/23 05:25, Ioana Ciornei wrote:
> On Mon, Mar 27, 2023 at 02:15:47PM -0400, Sean Anderson wrote:
>> On 3/24/23 09:17, Ioana Ciornei wrote:
>> > On Tue, Mar 21, 2023 at 04:13:12PM -0400, Sean Anderson wrote:
>> >> This adds serdes support to the LS1088ARDB. I have tested the QSGMII
>> >>
On Tue, Mar 21, 2023 at 6:08 AM Jiaxun Yang wrote:
>
> As for now all arches have dma_default_coherent reflecting default
> DMA coherency for of devices, so there is no need to have a standalone
> config option.
>
> Signed-off-by: Jiaxun Yang
> ---
> v3: Squash setting ARCH_DMA_DEFAULT_COHERENT
On Tue, Mar 21, 2023 at 6:08 AM Jiaxun Yang wrote:
>
> DT-based MIPS doesn't use OF_DMA_DEFAULT_COHERENT, but
> might override the system-wide default at runtime.
>
> Use dma_default_coherent to override default coherence for
> MIPS.
>
I assume you want this tagged for stable? Otherwise, I don't
> 2023年3月28日 08:45，Thomas Bogendoerfer 写道：
>
> On Tue, Mar 28, 2023 at 03:18:12AM +0200, Christoph Hellwig wrote:
>> On Fri, Mar 24, 2023 at 09:17:38AM +, Jiaxun Yang wrote:
Is patch a 6.3 candidate or should all of it go into 6.4?
>>>
>>> Please leave it for 6.4, as
Jens Axboe writes:
>>> Can the queueing cause the creation of an IO thread (if one does not
>>> exist, or all blocked?)
>>
>> Yep
>>
>> Since writing this email, I've gone through a lot of different tests.
>> Here's a rough listing of what I found:
>>
>> - Like using the hack patch, if I just
On 3/28/23 5:32?AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, except when PF_IO_WORKER's have been created and
>> the task
On 2023-03-28 23:02:09, Michael Ellerman wrote:
> Kautuk Consul writes:
> > On 2023-03-28 15:44:02, Kautuk Consul wrote:
> >> On 2023-03-28 20:44:48, Michael Ellerman wrote:
> >> > Kautuk Consul writes:
> >> > > kvmppc_vcore_create() might not be able to allocate memory through
> >> > > kzalloc.
Daniel Black writes:
> Thanks Jens, Nick, Christophe and Michael for your work so far.
>
> Apologies for the out of thread email.
>
> Confirming MariabD-10.6+ is required( when we added liburing), and
> previous versions used libaio (which tested without incident as mpe
> retested).
Thanks! I
Kautuk Consul writes:
> On 2023-03-28 15:44:02, Kautuk Consul wrote:
>> On 2023-03-28 20:44:48, Michael Ellerman wrote:
>> > Kautuk Consul writes:
>> > > kvmppc_vcore_create() might not be able to allocate memory through
>> > > kzalloc. In that case the kvm->arch.online_vcores shouldn't be
>> >
"Nicholas Piggin" writes:
> On Mon Mar 27, 2023 at 8:26 PM AEST, Christophe Leroy wrote:
...
>>
>> Now that thread.regs doesn't change anymore at each interrupt, it would
>> probably be worth dropping it and falling back to task_pt_regs() as
>> defined on most architecture.
>> Knowing whether a
Jens Axboe writes:
> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
> from my (arguably very short) checking is not commonly done for other
> archs. This is fine, except when PF_IO_WORKER's have been created and
> the task does something that causes a coredump to be
Commit 3c22ba524304 ("perf vendor events powerpc: Update POWER9 events")
added and updated power9 pmu json events. However some of the json
events which are part of other.json and pipeline.json files,
contains UTF-8 characters in their brief description.
Having UTF-8 character could brakes the
On 2023-03-28 15:44:02, Kautuk Consul wrote:
> On 2023-03-28 20:44:48, Michael Ellerman wrote:
> > Kautuk Consul writes:
> > > kvmppc_vcore_create() might not be able to allocate memory through
> > > kzalloc. In that case the kvm->arch.online_vcores shouldn't be
> > > incremented.
> >
> > I
On 2023-03-28 20:44:48, Michael Ellerman wrote:
> Kautuk Consul writes:
> > kvmppc_vcore_create() might not be able to allocate memory through
> > kzalloc. In that case the kvm->arch.online_vcores shouldn't be
> > incremented.
>
> I agree that looks wrong.
>
> Have you tried to test what goes
Kautuk Consul writes:
> kvmppc_vcore_create() might not be able to allocate memory through
> kzalloc. In that case the kvm->arch.online_vcores shouldn't be
> incremented.
I agree that looks wrong.
Have you tried to test what goes wrong if it fails? It looks like it
will break the LPCR update,
On Mon, Mar 27, 2023 at 02:15:47PM -0400, Sean Anderson wrote:
> On 3/24/23 09:17, Ioana Ciornei wrote:
> > On Tue, Mar 21, 2023 at 04:13:12PM -0400, Sean Anderson wrote:
> >> This adds serdes support to the LS1088ARDB. I have tested the QSGMII
> >> ports as well as the two 10G ports. The SFP slot
"Nicholas Piggin" writes:
> On Tue Mar 28, 2023 at 3:43 AM AEST, Sean Christopherson wrote:
>> On Mon, Mar 27, 2023, Nicholas Piggin wrote:
>> > On Thu Mar 23, 2023 at 3:41 AM AEST, Sean Christopherson wrote:
...
>> > >
>> > > What is the long term plan for KVM PPC maintenance? I was under the
On Tue, Mar 28, 2023 at 03:18:12AM +0200, Christoph Hellwig wrote:
> On Fri, Mar 24, 2023 at 09:17:38AM +, Jiaxun Yang wrote:
> > >
> > > Is patch a 6.3 candidate or should all of it go into 6.4?
> >
> > Please leave it for 6.4, as corresponding MIPS arch part will be a part of
> > 6.4.
>
On 3/28/23 09:15, Nicholas Piggin wrote:
On Tue Mar 28, 2023 at 2:09 AM AEST, Cédric Le Goater wrote:
On 3/27/23 14:45, Nicholas Piggin wrote:
This series is growing a bit I'm sorry. v2 series added extra interrupt
vectors support which was actually wrong because interrupt handling
code can
On Tue Mar 28, 2023 at 2:09 AM AEST, Cédric Le Goater wrote:
> On 3/27/23 14:45, Nicholas Piggin wrote:
> > This series is growing a bit I'm sorry. v2 series added extra interrupt
> > vectors support which was actually wrong because interrupt handling
> > code can only cope with 0x100-size vectors
Le 28/03/2023 à 08:51, Nicholas Piggin a écrit :
> On Tue Mar 28, 2023 at 3:48 AM AEST, Christophe Leroy wrote:
>>
>>
>> Le 25/03/2023 à 14:06, Nicholas Piggin a écrit :
>>> This file contains only the enter_prom implementation now.
>>> Trim includes and update header comment while we're here.
On Tue Mar 28, 2023 at 12:39 AM AEST, Thomas Huth wrote:
> On 27/03/2023 14.45, Nicholas Piggin wrote:
> > Check to ensure exception handlers are not being overwritten or
> > invalid exception numbers are used.
> >
> > Signed-off-by: Nicholas Piggin
> > ---
> > Since v2:
> > - New patch
> >
> >
On Tue Mar 28, 2023 at 3:48 AM AEST, Christophe Leroy wrote:
>
>
> Le 25/03/2023 à 14:06, Nicholas Piggin a écrit :
> > This file contains only the enter_prom implementation now.
> > Trim includes and update header comment while we're here.
> >
> > Signed-off-by: Nicholas Piggin
> > ---
> >
On Tue Mar 28, 2023 at 3:43 AM AEST, Sean Christopherson wrote:
> On Mon, Mar 27, 2023, Nicholas Piggin wrote:
> > On Thu Mar 23, 2023 at 3:41 AM AEST, Sean Christopherson wrote:
> > > On Thu, Mar 16, 2023, Michael Ellerman wrote:
> > > > Nicholas Piggin writes:
> > > > > Hi,
> > > > >
> > > > >
Thanks Jens, Nick, Christophe and Michael for your work so far.
Apologies for the out of thread email.
Confirming MariabD-10.6+ is required( when we added liburing), and
previous versions used libaio (which tested without incident as mpe
retested).
We were (we're now back on the old good kernel
On Mon Mar 27, 2023 at 8:26 PM AEST, Christophe Leroy wrote:
>
>
> Le 27/03/2023 à 08:36, Nicholas Piggin a écrit :
> > On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
> >> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
> >> from my (arguably very short) checking is
51 matches
Mail list logo
