* [PATCH 5/6] powerpc/rtas: rename RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE
From: Nathan Lynch @ 2021-01-14 22:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld, ajd, aik, aneesh.kumar, brking
In-Reply-To: <20210114220004.1138993-1-nathanl@linux.ibm.com>
RTAS_RMOBUF_MAX doesn't actually describe a "maximum" value in any
sense. It represents the size of an area of memory set aside for user
space to use as work areas for certain RTAS calls.
Rename it to RTAS_USER_REGION, and express the value in terms of the
number of work areas allocated.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
squash! powerpc/rtas: rename RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE
---
arch/powerpc/include/asm/rtas.h | 9 ++++++---
arch/powerpc/kernel/rtas-proc.c | 2 +-
arch/powerpc/kernel/rtas.c | 2 +-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 332e1000ca0f..1aa7ab1cbc84 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -19,8 +19,11 @@
#define RTAS_UNKNOWN_SERVICE (-1)
#define RTAS_INSTANTIATE_MAX (1ULL<<30) /* Don't instantiate rtas at/above this value */
-/* Buffer size for ppc_rtas system call. */
-#define RTAS_RMOBUF_MAX (64 * 1024)
+/* Work areas shared with RTAS must be 4K, naturally aligned. */
+#define RTAS_WORK_AREA_SIZE 4096
+
+/* Work areas allocated for user space access. */
+#define RTAS_USER_REGION_SIZE (RTAS_WORK_AREA_SIZE * 16)
/* RTAS return status codes */
#define RTAS_BUSY -2 /* RTAS Busy */
@@ -357,7 +360,7 @@ extern void rtas_take_timebase(void);
static inline int page_is_rtas_user_buf(unsigned long pfn)
{
unsigned long paddr = (pfn << PAGE_SHIFT);
- if (paddr >= rtas_rmo_buf && paddr < (rtas_rmo_buf + RTAS_RMOBUF_MAX))
+ if (paddr >= rtas_rmo_buf && paddr < (rtas_rmo_buf + RTAS_USER_REGION_SIZE))
return 1;
return 0;
}
diff --git a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
index d2b0d99824a4..6857a5b0a1c3 100644
--- a/arch/powerpc/kernel/rtas-proc.c
+++ b/arch/powerpc/kernel/rtas-proc.c
@@ -767,6 +767,6 @@ static int ppc_rtas_tone_volume_show(struct seq_file *m, void *v)
*/
static int ppc_rtas_rmo_buf_show(struct seq_file *m, void *v)
{
- seq_printf(m, "%016lx %x\n", rtas_rmo_buf, RTAS_RMOBUF_MAX);
+ seq_printf(m, "%016lx %x\n", rtas_rmo_buf, RTAS_USER_REGION_SIZE);
return 0;
}
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 55f6aa170e57..da65faadbbb2 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1204,7 +1204,7 @@ void __init rtas_initialize(void)
if (firmware_has_feature(FW_FEATURE_LPAR))
rtas_region = min(ppc64_rma_size, RTAS_INSTANTIATE_MAX);
#endif
- rtas_rmo_buf = memblock_phys_alloc_range(RTAS_RMOBUF_MAX, PAGE_SIZE,
+ rtas_rmo_buf = memblock_phys_alloc_range(RTAS_USER_REGION_SIZE, PAGE_SIZE,
0, rtas_region);
if (!rtas_rmo_buf)
panic("ERROR: RTAS: Failed to allocate %lx bytes below %pa\n",
--
2.29.2
^ permalink raw reply related
* Re: [PATCH v5 18/21] ibmvfc: send Cancel MAD down each hw scsi channel
From: Brian King @ 2021-01-14 22:42 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20210114203148.246656-19-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v5 21/21] ibmvfc: provide modules parameters for MQ settings
From: Brian King @ 2021-01-14 22:44 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20210114203148.246656-22-tyreld@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v5 00/21] ibmvfc: initial MQ development/enablement
From: Brian King @ 2021-01-14 22:47 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20210114203148.246656-1-tyreld@linux.ibm.com>
Tyrel,
I think this patch series is looking pretty good. I don't think we need
to wait for resolution of the can_queue issue being discussed, since
that is an issue that exists prior to this patch series and this patch
series doesn't make the issue any worse. Let's work that separately.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v5 02/21] powerpc/64s: move the last of the page fault handling logic to C
From: Nicholas Piggin @ 2021-01-15 0:25 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <afa9875c-e8ed-de3e-d395-435be86bd958@csgroup.eu>
Excerpts from Christophe Leroy's message of January 14, 2021 11:28 pm:
>
>
> Le 14/01/2021 à 14:17, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of January 14, 2021 10:25 pm:
>>>
>>>
>>> Le 14/01/2021 à 13:09, Nicholas Piggin a écrit :
>>>> Excerpts from Nicholas Piggin's message of January 14, 2021 1:24 pm:
>>>>> Excerpts from Christophe Leroy's message of January 14, 2021 12:12 am:
>>>>>>
>>>>>>
>>>>>> Le 13/01/2021 à 08:31, Nicholas Piggin a écrit :
>>>>>>> The page fault handling still has some complex logic particularly around
>>>>>>> hash table handling, in asm. Implement this in C instead.
>>>>>>>
>>>>>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>>>>>> ---
>>>>>>> arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 +
>>>>>>> arch/powerpc/kernel/exceptions-64s.S | 131 +++---------------
>>>>>>> arch/powerpc/mm/book3s64/hash_utils.c | 77 ++++++----
>>>>>>> arch/powerpc/mm/fault.c | 46 ++++--
>>>>>>> 4 files changed, 107 insertions(+), 148 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>>>>>>> index 066b1d34c7bc..60a669379aa0 100644
>>>>>>> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>>>>>>> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>>>>>>> @@ -454,6 +454,7 @@ static inline unsigned long hpt_hash(unsigned long vpn,
>>>>>>> #define HPTE_NOHPTE_UPDATE 0x2
>>>>>>> #define HPTE_USE_KERNEL_KEY 0x4
>>>>>>>
>>>>>>> +int do_hash_fault(struct pt_regs *regs, unsigned long ea, unsigned long dsisr);
>>>>>>> extern int __hash_page_4K(unsigned long ea, unsigned long access,
>>>>>>> unsigned long vsid, pte_t *ptep, unsigned long trap,
>>>>>>> unsigned long flags, int ssize, int subpage_prot);
>>>>>>> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>>>>>>> index 6e53f7638737..bcb5e81d2088 100644
>>>>>>> --- a/arch/powerpc/kernel/exceptions-64s.S
>>>>>>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>>>>>>> @@ -1401,14 +1401,15 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
>>>>>>> *
>>>>>>> * Handling:
>>>>>>> * - Hash MMU
>>>>>>> - * Go to do_hash_page first to see if the HPT can be filled from an entry in
>>>>>>> - * the Linux page table. Hash faults can hit in kernel mode in a fairly
>>>>>>> + * Go to do_hash_fault, which attempts to fill the HPT from an entry in the
>>>>>>> + * Linux page table. Hash faults can hit in kernel mode in a fairly
>>>>>>> * arbitrary state (e.g., interrupts disabled, locks held) when accessing
>>>>>>> * "non-bolted" regions, e.g., vmalloc space. However these should always be
>>>>>>> - * backed by Linux page tables.
>>>>>>> + * backed by Linux page table entries.
>>>>>>> *
>>>>>>> - * If none is found, do a Linux page fault. Linux page faults can happen in
>>>>>>> - * kernel mode due to user copy operations of course.
>>>>>>> + * If no entry is found the Linux page fault handler is invoked (by
>>>>>>> + * do_hash_fault). Linux page faults can happen in kernel mode due to user
>>>>>>> + * copy operations of course.
>>>>>>> *
>>>>>>> * KVM: The KVM HDSI handler may perform a load with MSR[DR]=1 in guest
>>>>>>> * MMU context, which may cause a DSI in the host, which must go to the
>>>>>>> @@ -1439,13 +1440,17 @@ EXC_COMMON_BEGIN(data_access_common)
>>>>>>> GEN_COMMON data_access
>>>>>>> ld r4,_DAR(r1)
>>>>>>> ld r5,_DSISR(r1)
>>>>>>
>>>>>> We have DSISR here. I think the dispatch between page fault or do_break() should be done here:
>>>>>> - It would be more similar to other arches
>>>>>
>>>>> Other sub-archs?
>>>>>
>>>>>> - Would avoid doing it also in instruction fault
>>>>>
>>>>> True but it's hidden under an unlikely branch so won't really help
>>>>> instruction fault.
>>>>>
>>>>>> - Would avoid that -1 return which looks more like a hack.
>>>>>
>>>>> I don't really see it as a hack, we return a code to asm caller to
>>>>> direct whether to restore registers or not, we alrady have this
>>>>> pattern.
>>>>>
>>>>> (I'm hoping all that might be go away one day by conrolling NV
>>>>> regs from C if we can get good code generation but even if not we
>>>>> still have it in the interrupt returns).
>>>>>
>>>>> That said I will give it a try here. At very least it might be a
>>>>> better intermediate step.
>>>>
>>>> Ah yes, this way doesn't work well for later patches because you end
>>>> e.g., with the do_break call having to call the interrupt handler
>>>> wrappers again when they actually expect to be in the asm entry state
>>>> (e.g., irq soft-mask state) when called, and return via interrupt_return
>>>> after the exit wrapper runs (which 64s uses to implement better context
>>>> tracking for example).
>>>>
>>>> That could possibly be hacked up to deal with multiple interrupt
>>>> wrappers per interrupt, but I'd rather not go backwards.
>>>>
>>>> That does leave the other sub archs as having this issue, but they don't
>>>> do so much in their handlers. 32 doesn't have soft-mask or context
>>>> tracking to deal with for example. We will need to fix this up though
>>>> and unify things more.
>>>>
>>>
>>> Not sure I understand what you mean exactly.
>>>
>>> On the 8xx, do_break() is called by totally different exceptions:
>>> - Exception 0x1c00 Data breakpoint ==> do_break()
>>> - Exception 0x1300 Instruction TLB error ==> handle_page_fault()
>>> - Exception 0x1400 Data TLB error ==> handle_page_fault()
>>>
>>> On book3s/32, we now (after my patch ie patch 1 in your series ) have either do_break() or
>>> handle_page_fault() being called from very early in ASM.
>>>
>>> If you do the same in book3s/64, then there is no issue with interrupt wrappers being called twice,
>>> is it ?
>>
>> bad_page_fault is the problem, it has to go afterwards.
>>
>> Once we have the changed 64s behaviour of do_page_fault, I don't know if
>> there is any point leaving do_break in asm is there? I guess it is neat
>> to treat it quite separately, I might need to count fast path branches...
>> I have done the split anyway already, so I will post your way first.
>>
>
> As far as I understand, not taken unlikely branches are costless (at least on book3s/32), so you
> would only suffer the cost of the logical 'and.' on the value of DSISR that you already have in a
> register. Should be in the noise.
>
> bad_page_fault() is not in the fast path anymore since we now handle the exception fixup at the end
> of do_page_fault(). So I think it shouldn't be a concern to call the wrapper again for bad_page_fault()
It's not performance but correctness. For example we can have interrupts
enabled again at this time, which the interrupt wrapper does not expect.
Or the context tracking code in the entry wrapper would break if it's
called again before interrupt_return.
I think it's not too ugly to put bad_page_fault in C and having do_break
in asm still avoids a lot of your complaints.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v4 01/21] ibmvfc: add vhost fields and defaults for MQ enablement
From: Ming Lei @ 2021-01-15 1:47 UTC (permalink / raw)
To: Brian King
Cc: Tyrel Datwyler, martin.petersen, linux-scsi, linux-kernel,
james.smart, james.bottomley, brking, linuxppc-dev
In-Reply-To: <9c5f7786-cd13-6a49-2d71-d0c438318bcb@linux.vnet.ibm.com>
On Thu, Jan 14, 2021 at 11:24:35AM -0600, Brian King wrote:
> On 1/13/21 7:27 PM, Ming Lei wrote:
> > On Wed, Jan 13, 2021 at 11:13:07AM -0600, Brian King wrote:
> >> On 1/12/21 6:33 PM, Tyrel Datwyler wrote:
> >>> On 1/12/21 2:54 PM, Brian King wrote:
> >>>> On 1/11/21 5:12 PM, Tyrel Datwyler wrote:
> >>>>> Introduce several new vhost fields for managing MQ state of the adapter
> >>>>> as well as initial defaults for MQ enablement.
> >>>>>
> >>>>> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> >>>>> ---
> >>>>> drivers/scsi/ibmvscsi/ibmvfc.c | 8 ++++++++
> >>>>> drivers/scsi/ibmvscsi/ibmvfc.h | 9 +++++++++
> >>>>> 2 files changed, 17 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> >>>>> index ba95438a8912..9200fe49c57e 100644
> >>>>> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> >>>>> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> >>>>> @@ -3302,6 +3302,7 @@ static struct scsi_host_template driver_template = {
> >>>>> .max_sectors = IBMVFC_MAX_SECTORS,
> >>>>> .shost_attrs = ibmvfc_attrs,
> >>>>> .track_queue_depth = 1,
> >>>>> + .host_tagset = 1,
> >>>>
> >>>> This doesn't seem right. You are setting host_tagset, which means you want a
> >>>> shared, host wide, tag set for commands. It also means that the total
> >>>> queue depth for the host is can_queue. However, it looks like you are allocating
> >>>> max_requests events for each sub crq, which means you are over allocating memory.
> >>>
> >>> With the shared tagset yes the queue depth for the host is can_queue, but this
> >>> also implies that the max queue depth for each hw queue is also can_queue. So,
> >>> in the worst case that all commands are queued down the same hw queue we need an
> >>> event pool with can_queue commands.
> >>>
> >>>>
> >>>> Looking at this closer, we might have bigger problems. There is a host wide
> >>>> max number of commands that the VFC host supports, which gets returned on
> >>>> NPIV Login. This value can change across a live migration event.
> >>>
> >>> From what I understand the max commands can only become less.
> >>>
> >>>>
> >>>> The ibmvfc driver, which does the same thing the lpfc driver does, modifies
> >>>> can_queue on the scsi_host *after* the tag set has been allocated. This looks
> >>>> to be a concern with ibmvfc, not sure about lpfc, as it doesn't look like
> >>>> we look at can_queue once the tag set is setup, and I'm not seeing a good way
> >>>> to dynamically change the host queue depth once the tag set is setup.
> >>>>
> >>>> Unless I'm missing something, our best options appear to either be to implement
> >>>> our own host wide busy reference counting, which doesn't sound very good, or
> >>>> we need to add some API to block / scsi that allows us to dynamically change
> >>>> can_queue.
> >>>
> >>> Changing can_queue won't do use any good with the shared tagset becasue each
> >>> queue still needs to be able to queue can_queue number of commands in the worst
> >>> case.
> >>
> >> The issue I'm trying to highlight here is the following scenario:
> >>
> >> 1. We set shost->can_queue, then call scsi_add_host, which allocates the tag set.
> >>
> >> 2. On our NPIV login response from the VIOS, we might get a lower value than we
> >> initially set in shost->can_queue, so we update it, but nobody ever looks at it
> >> again, and we don't have any protection against sending too many commands to the host.
> >>
> >>
> >> Basically, we no longer have any code that ensures we don't send more
> >> commands to the VIOS than we are told it supports. According to the architecture,
> >> if we actually do this, the VIOS will do an h_free_crq, which would be a bit
> >> of a bug on our part.
> >>
> >> I don't think it was ever clearly defined in the API that a driver can
> >> change shost->can_queue after calling scsi_add_host, but up until
> >> commit 6eb045e092efefafc6687409a6fa6d1dabf0fb69, this worked and now
> >> it doesn't.
> >
> > Actually it isn't related with commit 6eb045e092ef, because blk_mq_alloc_tag_set()
> > uses .can_queue to create driver tag sbitmap and request pool.
> >
> > So even thought without 6eb045e092ef, the updated .can_queue can't work
> > as expected because the max driver tag depth has been fixed by blk-mq already.
>
> There are two scenarios here. In the scenario of someone increasing can_queue
> after the tag set is allocated, I agree, blk-mq will never take advantage
> of this. However, in the scenario of someone *decreasing* can_queue after the
> tag set is allocated, prior to 6eb045e092ef, the shost->host_busy code provided
> this protection.
When .can_queue is decreased, blk-mq still may allocate driver tag which is >
.can_queue, this way might break driver/device too, but it depends on how driver
uses req->tag.
>
> >
> > What 6eb045e092ef does is just to remove the double check on max
> > host-wide allowed commands because that has been respected by blk-mq
> > driver tag allocation already.
> >
> >>
> >> I started looking through drivers that do this, and so far, it looks like the
> >> following drivers do: ibmvfc, lpfc, aix94xx, libfc, BusLogic, and likely others...
> >>
> >> We probably need an API that lets us change shost->can_queue dynamically.
> >
> > I'd suggest to confirm changing .can_queue is one real usecase.
>
> For ibmvfc, the total number of commands that the scsi host supports is very
> much a dynamic value. It can increase and it can decrease. Live migrating
> a logical partition from one system to another is the usual cause of
> such a capability change. For ibmvfc, at least, this only ever happens
> when we've self blocked the host and have sent back all outstanding I/O.
This one looks a good use case, and the new API may have to freeze request
queues of all LUNs, and the operation is very expensive and slow.
>
> However, looking at other drivers that modify can_queue dynamically, this
> doesn't always hold true. Looking at libfc, it looks to dynamically ramp
> up and ramp down can_queue based on its ability to handle requests.
This one looks hard to use the new API which isn't supposed to be called
in fast path. And changing host wide resource is really not good in fast
path, IMO.
>
> There are certainly a number of other drivers that change can_queue
> after the tag set has been allocated. Some of these drivers could
> likely be changed to avoid doing this, but changing them all will likely
> be difficult.
It is still better to understand why these drivers have to update
.can_queue dynamically.
Thanks,
Ming
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 41131a5e54ae7ba5a2bb8d7b30d1818b3f5b13d2
From: kernel test robot @ 2021-01-15 1:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 41131a5e54ae7ba5a2bb8d7b30d1818b3f5b13d2 powerpc/vdso: Fix clock_gettime_fallback for vdso32
elapsed time: 728m
configs tested: 115
configs skipped: 94
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
mips tb0287_defconfig
s390 debug_defconfig
openrisc defconfig
arc nsim_700_defconfig
arm sunxi_defconfig
powerpc mpc5200_defconfig
arm cns3420vb_defconfig
powerpc holly_defconfig
mips pistachio_defconfig
mips nlm_xlr_defconfig
powerpc tqm8xx_defconfig
powerpc katmai_defconfig
powerpc eiger_defconfig
arc alldefconfig
m68k mvme147_defconfig
um kunit_defconfig
m68k alldefconfig
arm at91_dt_defconfig
m68k m5407c3_defconfig
riscv rv32_defconfig
arm corgi_defconfig
arm aspeed_g5_defconfig
arm mvebu_v5_defconfig
arm assabet_defconfig
arm multi_v7_defconfig
powerpc pcm030_defconfig
powerpc cm5200_defconfig
mips loongson1b_defconfig
mips mtx1_defconfig
arm spear3xx_defconfig
arc axs103_defconfig
nios2 defconfig
arm cm_x300_defconfig
sh se7750_defconfig
sh se7206_defconfig
powerpc tqm8555_defconfig
arm lpc32xx_defconfig
sh se7722_defconfig
nds32 allnoconfig
mips maltaup_defconfig
csky alldefconfig
arm iop32x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20210114
i386 randconfig-a005-20210114
i386 randconfig-a006-20210114
i386 randconfig-a001-20210114
i386 randconfig-a003-20210114
i386 randconfig-a004-20210114
x86_64 randconfig-a015-20210114
x86_64 randconfig-a012-20210114
x86_64 randconfig-a013-20210114
x86_64 randconfig-a016-20210114
x86_64 randconfig-a014-20210114
x86_64 randconfig-a011-20210114
i386 randconfig-a012-20210114
i386 randconfig-a011-20210114
i386 randconfig-a016-20210114
i386 randconfig-a015-20210114
i386 randconfig-a013-20210114
i386 randconfig-a014-20210114
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20210114
x86_64 randconfig-a006-20210114
x86_64 randconfig-a001-20210114
x86_64 randconfig-a003-20210114
x86_64 randconfig-a005-20210114
x86_64 randconfig-a002-20210114
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 56f0e929cb28f6e28e6f88d88c03b75979cf1f40
From: kernel test robot @ 2021-01-15 1:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 56f0e929cb28f6e28e6f88d88c03b75979cf1f40 Automatic merge of 'fixes' into merge (2021-01-14 15:57)
elapsed time: 725m
configs tested: 134
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc mpc836x_rdk_defconfig
powerpc mpc8313_rdb_defconfig
arm mvebu_v7_defconfig
mips bcm47xx_defconfig
sh rsk7201_defconfig
mips tb0287_defconfig
s390 debug_defconfig
openrisc defconfig
arc nsim_700_defconfig
arm sunxi_defconfig
powerpc mpc5200_defconfig
arm cns3420vb_defconfig
powerpc holly_defconfig
mips pistachio_defconfig
mips nlm_xlr_defconfig
powerpc tqm8xx_defconfig
powerpc katmai_defconfig
powerpc eiger_defconfig
arc alldefconfig
m68k mvme147_defconfig
um kunit_defconfig
arm zeus_defconfig
mips workpad_defconfig
arm eseries_pxa_defconfig
mips cu1000-neo_defconfig
mips mpc30x_defconfig
mips maltasmvp_defconfig
m68k alldefconfig
arm at91_dt_defconfig
m68k m5407c3_defconfig
riscv rv32_defconfig
arm corgi_defconfig
arm aspeed_g5_defconfig
arm mvebu_v5_defconfig
arm assabet_defconfig
arm multi_v7_defconfig
sh se7750_defconfig
m68k q40_defconfig
m68k m5475evb_defconfig
arm imx_v6_v7_defconfig
arm tegra_defconfig
mips loongson1b_defconfig
mips mtx1_defconfig
arm spear3xx_defconfig
arc axs103_defconfig
nios2 defconfig
arm cm_x300_defconfig
sh se7206_defconfig
powerpc tqm8555_defconfig
arm lpc32xx_defconfig
sh se7722_defconfig
nds32 allnoconfig
mips maltaup_defconfig
csky alldefconfig
arm iop32x_defconfig
powerpc tqm8541_defconfig
sh ap325rxa_defconfig
arm palmz72_defconfig
s390 alldefconfig
h8300 h8300h-sim_defconfig
powerpc tqm8540_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20210114
i386 randconfig-a005-20210114
i386 randconfig-a006-20210114
i386 randconfig-a001-20210114
i386 randconfig-a003-20210114
i386 randconfig-a004-20210114
x86_64 randconfig-a015-20210114
x86_64 randconfig-a012-20210114
x86_64 randconfig-a013-20210114
x86_64 randconfig-a016-20210114
x86_64 randconfig-a014-20210114
x86_64 randconfig-a011-20210114
i386 randconfig-a012-20210114
i386 randconfig-a011-20210114
i386 randconfig-a016-20210114
i386 randconfig-a015-20210114
i386 randconfig-a013-20210114
i386 randconfig-a014-20210114
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20210114
x86_64 randconfig-a006-20210114
x86_64 randconfig-a001-20210114
x86_64 randconfig-a003-20210114
x86_64 randconfig-a005-20210114
x86_64 randconfig-a002-20210114
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 6629114a7f6f21d41640cbc006c3694e65940729
From: kernel test robot @ 2021-01-15 1:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 6629114a7f6f21d41640cbc006c3694e65940729 powerpc/vas: Fix IRQ name allocation
elapsed time: 726m
configs tested: 122
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
mips tb0287_defconfig
s390 debug_defconfig
openrisc defconfig
arc nsim_700_defconfig
arm sunxi_defconfig
mips cavium_octeon_defconfig
alpha alldefconfig
sh r7780mp_defconfig
sparc64 defconfig
m68k stmark2_defconfig
arc nsimosci_defconfig
powerpc mpc5200_defconfig
arm cns3420vb_defconfig
powerpc holly_defconfig
mips pistachio_defconfig
mips nlm_xlr_defconfig
powerpc tqm8xx_defconfig
powerpc katmai_defconfig
powerpc eiger_defconfig
arc alldefconfig
m68k mvme147_defconfig
um kunit_defconfig
m68k alldefconfig
arm at91_dt_defconfig
m68k m5407c3_defconfig
riscv rv32_defconfig
arm davinci_all_defconfig
powerpc pq2fads_defconfig
powerpc mpc8272_ads_defconfig
arm corgi_defconfig
arm aspeed_g5_defconfig
arm mvebu_v5_defconfig
arm assabet_defconfig
arm multi_v7_defconfig
mips loongson1b_defconfig
mips mtx1_defconfig
arm spear3xx_defconfig
arc axs103_defconfig
nios2 defconfig
arm cm_x300_defconfig
sh se7750_defconfig
sh se7206_defconfig
powerpc tqm8555_defconfig
arm lpc32xx_defconfig
sh se7722_defconfig
nds32 allnoconfig
mips maltaup_defconfig
csky alldefconfig
arm iop32x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20210114
i386 randconfig-a005-20210114
i386 randconfig-a006-20210114
i386 randconfig-a001-20210114
i386 randconfig-a003-20210114
i386 randconfig-a004-20210114
x86_64 randconfig-a015-20210114
x86_64 randconfig-a012-20210114
x86_64 randconfig-a013-20210114
x86_64 randconfig-a016-20210114
x86_64 randconfig-a014-20210114
x86_64 randconfig-a011-20210114
i386 randconfig-a012-20210114
i386 randconfig-a011-20210114
i386 randconfig-a016-20210114
i386 randconfig-a015-20210114
i386 randconfig-a013-20210114
i386 randconfig-a014-20210114
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20210114
x86_64 randconfig-a006-20210114
x86_64 randconfig-a001-20210114
x86_64 randconfig-a003-20210114
x86_64 randconfig-a005-20210114
x86_64 randconfig-a002-20210114
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v5 00/21] ibmvfc: initial MQ development/enablement
From: Martin K. Petersen @ 2021-01-15 3:31 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: martin.petersen, linux-scsi, linux-kernel, james.bottomley,
brking, linuxppc-dev
In-Reply-To: <20210114203148.246656-1-tyreld@linux.ibm.com>
Tyrel,
> Recent updates in pHyp Firmware and VIOS releases provide new
> infrastructure towards enabling Subordinate Command Response Queues
> (Sub-CRQs) such that each Sub-CRQ is a channel backed by an actual
> hardware queue in the FC stack on the partner VIOS. Sub-CRQs are
> registered with the firmware via hypercalls and then negotiated with
> the VIOS via new Management Datagrams (MADs) for channel setup.
>
> This initial implementation adds the necessary Sub-CRQ framework and
> implements the new MADs for negotiating and assigning a set of
> Sub-CRQs to associated VIOS HW backed channels.
Applied to 5.12/scsi-staging, thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [RFC PATCH v3 6/6] of: Add plumbing for restricted DMA pool
From: Claire Chang @ 2021-01-15 3:46 UTC (permalink / raw)
To: Florian Fainelli
Cc: heikki.krogerus, peterz, grant.likely, paulus, Frank Rowand,
mingo, Marek Szyprowski, sstabellini, Saravana Kannan,
Joerg Roedel, rafael.j.wysocki, Christoph Hellwig,
Bartosz Golaszewski, xen-devel, Thierry Reding, linux-devicetree,
will, Konrad Rzeszutek Wilk, dan.j.williams, linuxppc-dev,
Rob Herring, boris.ostrovsky, Andy Shevchenko, jgross,
Nicolas Boichat, Greg KH, rdunlap, lkml, Tomasz Figa,
list@263.net:IOMMU DRIVERS, xypron.glpk, Robin Murphy, bauerman
In-Reply-To: <5f276678-3ab2-ddc8-640c-6dbbe173463c@gmail.com>
On Fri, Jan 15, 2021 at 2:52 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 1/14/21 1:08 AM, Claire Chang wrote:
> > On Wed, Jan 13, 2021 at 7:48 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>
> >> On 1/5/21 7:41 PM, Claire Chang wrote:
> >>> If a device is not behind an IOMMU, we look up the device node and set
> >>> up the restricted DMA when the restricted-dma-pool is presented.
> >>>
> >>> Signed-off-by: Claire Chang <tientzu@chromium.org>
> >>> ---
> >>
> >> [snip]
> >>
> >>> +int of_dma_set_restricted_buffer(struct device *dev)
> >>> +{
> >>> + struct device_node *node;
> >>> + int count, i;
> >>> +
> >>> + if (!dev->of_node)
> >>> + return 0;
> >>> +
> >>> + count = of_property_count_elems_of_size(dev->of_node, "memory-region",
> >>> + sizeof(phandle));
> >>
> >> You could have an early check for count < 0, along with an error
> >> message, if that is deemed useful.
> >>
> >>> + for (i = 0; i < count; i++) {
> >>> + node = of_parse_phandle(dev->of_node, "memory-region", i);
> >>> + if (of_device_is_compatible(node, "restricted-dma-pool"))
> >>
> >> And you may want to add here an of_device_is_available(node). A platform
> >> that provides the Device Tree firmware and try to support multiple
> >> different SoCs may try to determine if an IOMMU is present, and if it
> >> is, it could be marking the restriced-dma-pool region with a 'status =
> >> "disabled"' property, or any variant of that scheme.
> >
> > This function is called only when there is no IOMMU present (check in
> > drivers/of/device.c). I can still add of_device_is_available(node)
> > here if you think it's helpful.
>
> I believe it is, since boot loader can have a shared Device Tree blob
> skeleton and do various adaptations based on the chip (that's what we
> do) and adding a status property is much simpler than insertion new
> nodes are run time.
>
> >
> >>
> >>> + return of_reserved_mem_device_init_by_idx(
> >>> + dev, dev->of_node, i);
> >>
> >> This does not seem to be supporting more than one memory region, did not
> >> you want something like instead:
> >>
> >> ret = of_reserved_mem_device_init_by_idx(...);
> >> if (ret)
> >> return ret;
> >>
> >
> > Yes. This implement only supports one restriced-dma-pool memory region
> > with the assumption that there is only one memory region with the
> > compatible string, restricted-dma-pool, in the dts. IIUC, it's similar
> > to shared-dma-pool.
>
> Then if here is such a known limitation it should be both documented and
> enforced here, you shouldn ot be iterating over all of the phandles that
> you find, stop at the first one and issue a warning if count > 1?
What I have in mind is there might be multiple memory regions, but
only one is for restriced-dma-pool.
Say, if you want a separated region for coherent DMA and only do
streaming DMA in this restriced-dma-pool region, you can add another
reserved-memory node with shared-dma-pool in dts and the current
implementation will try to allocate the memory via
dma_alloc_from_dev_coherent() first (see dma_alloc_attrs() in
/kernel/dma/mapping.c).
Or if you have vendor specific memory region, you can still set up
restriced-dma-pool by adding another reserved-memory node in dts.
Dose this make sense to you? I'll document this for sure.
> --
> Florian
^ permalink raw reply
* Re: [PATCH 10/18] arch: powerpc: Stop building and using oprofile
From: Viresh Kumar @ 2021-01-15 4:13 UTC (permalink / raw)
To: Linus Torvalds, Robert Richter, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Arnd Bergmann,
Jeremy Kerr
Cc: Arnd Bergmann, Vincent Guittot, Christoph Hellwig, linux-kernel,
anmar.oueja, oprofile-list, Alexander Viro, William Cohen,
linuxppc-dev
In-Reply-To: <fd155a0a1e52650ddc9ec57a1d211fdc777beddb.1610622251.git.viresh.kumar@linaro.org>
On 14-01-21, 17:05, Viresh Kumar wrote:
> The "oprofile" user-space tools don't use the kernel OPROFILE support
> any more, and haven't in a long time. User-space has been converted to
> the perf interfaces.
>
> This commits stops building oprofile for powerpc and removes any
> reference to it from directories in arch/powerpc/ apart from
> arch/powerpc/oprofile, which will be removed in the next commit (this is
> broken into two commits as the size of the commit became very big, ~5k
> lines).
>
> Note that the member "oprofile_cpu_type" in "struct cpu_spec" isn't
> removed as it was also used by other parts of the code.
>
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+ this to fix a warning:
diff --git a/arch/powerpc/platforms/cell/spufs/run.c b/arch/powerpc/platforms/cell/spufs/run.c
index 466006918003..ce52b87496d2 100644
--- a/arch/powerpc/platforms/cell/spufs/run.c
+++ b/arch/powerpc/platforms/cell/spufs/run.c
@@ -353,7 +353,6 @@ static int spu_process_callback(struct spu_context *ctx)
long spufs_run_spu(struct spu_context *ctx, u32 *npc, u32 *event)
{
int ret;
- struct spu *spu;
u32 status;
if (mutex_lock_interruptible(&ctx->run_mutex))
@@ -386,7 +385,6 @@ long spufs_run_spu(struct spu_context *ctx, u32 *npc, u32 *event)
mutex_lock(&ctx->state_mutex);
break;
}
- spu = ctx->spu;
if (unlikely(test_and_clear_bit(SPU_SCHED_NOTIFY_ACTIVE,
&ctx->sched_flags))) {
if (!(status & SPU_STATUS_STOPPED_BY_STOP))
--
viresh
^ permalink raw reply related
* Re: [PATCH 6/6] powerpc/rtas: constrain user region allocation to RMA
From: Alexey Kardashevskiy @ 2021-01-15 4:38 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, brking, ajd, aneesh.kumar
In-Reply-To: <20210114220004.1138993-7-nathanl@linux.ibm.com>
On 15/01/2021 09:00, Nathan Lynch wrote:
> Memory locations passed as arguments from the OS to RTAS usually need
> to be addressable in 32-bit mode and must reside in the Real Mode
> Area. On PAPR guests, the RMA starts at logical address 0 and is the
> first logical memory block reported in the LPAR’s device tree.
>
> On powerpc targets with RTAS, Linux makes available to user space a
> region of memory suitable for arguments to be passed to RTAS via
> sys_rtas(). This region (rtas_rmo_buf) is allocated via the memblock
> API during boot in order to ensure that it satisfies the requirements
> described above.
>
> With radix MMU, the upper limit supplied to the memblock allocation
> can exceed the bounds of the first logical memory block, since
> ppc64_rma_size is ULONG_MAX and RTAS_INSTANTIATE_MAX is 1GB. (512MB is
> a common size of the first memory block according to a small sample of
> LPARs I have checked.) This leads to failures when user space invokes
> an RTAS function that uses a work area, such as
> ibm,configure-connector.
>
> Alter the determination of the upper limit for rtas_rmo_buf's
> allocation to consult the device tree directly, ensuring placement
> within the RMA regardless of the MMU in use.
Can we tie this with RTAS (which also needs to be in RMA) and simply add
extra 64K in prom_instantiate_rtas() and advertise this address
(ALIGH_UP(rtas-base + rtas-size, PAGE_SIZE)) to the user space? We do
not need this RMO area before that point.
And probably do the same with per-cpu RTAS argument structures mentioned
in the cover letter?
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
> arch/powerpc/kernel/rtas.c | 80 +++++++++++++++++++++++++++++++-------
> 1 file changed, 65 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index da65faadbbb2..98dfb112f4df 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -1166,6 +1166,70 @@ SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
> return 0;
> }
>
> +/*
> + * Memory locations passed to RTAS must be in the RMA as described by
> + * the range in /memory@0.
> + */
> +static phys_addr_t rtas_arg_addr_limit(void)
> +{
> + unsigned int addr_cells;
> + unsigned int size_cells;
> + struct device_node *np;
> + const __be32 *prop;
> + u64 limit;
> + u64 base;
> +
> + /* RTAS is instantiated in 32-bit mode. */
> + limit = 1ULL << 32;
> +
> + /* Account for mem=. */
> + if (memory_limit != 0)
> + limit = min(limit, memory_limit);
> +
> + np = of_find_node_by_path("/memory@0");
> + if (!np)
> + goto out;
> +
> + prop = of_get_property(np, "reg", NULL);
> + if (!prop)
> + goto put;
> +
> + addr_cells = of_n_addr_cells(np);
> + base = of_read_number(prop, addr_cells);
> + prop += addr_cells;
> + size_cells = of_n_size_cells(np);
> + limit = min(limit, of_read_number(prop, size_cells));
> +put:
> + of_node_put(np);
> +out:
> + pr_debug("%s: base = %#llx limit = %#llx", __func__, base, limit);
> +
> + return limit;
> +}
> +
> +static void __init rtas_user_region_setup(void)
> +{
> + phys_addr_t limit, align, size;
> +
> + limit = rtas_arg_addr_limit();
> + size = RTAS_USER_REGION_SIZE;
> +
> + /*
> + * Although work areas need only 4KB alignment, user space
> + * accesses this region via mmap so it must be placed on a
> + * page boundary.
> + */
> + align = PAGE_SIZE;
> +
> + rtas_rmo_buf = memblock_phys_alloc_range(size, align, 0, limit);
> + if (rtas_rmo_buf == 0) {
> + panic("Failed to allocate %llu bytes for user region below %pa\n",
> + size, &limit);
> + }
> +
> + pr_debug("RTAS user region allocated at %pa\n", &rtas_rmo_buf);
> +}
> +
> /*
> * Call early during boot, before mem init, to retrieve the RTAS
> * information from the device-tree and allocate the RMO buffer for userland
> @@ -1173,7 +1237,6 @@ SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
> */
> void __init rtas_initialize(void)
> {
> - unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
> u32 base, size, entry;
> int no_base, no_size, no_entry;
>
> @@ -1197,23 +1260,10 @@ void __init rtas_initialize(void)
> no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", &entry);
> rtas.entry = no_entry ? rtas.base : entry;
>
> - /* If RTAS was found, allocate the RMO buffer for it and look for
> - * the stop-self token if any
> - */
> -#ifdef CONFIG_PPC64
> - if (firmware_has_feature(FW_FEATURE_LPAR))
> - rtas_region = min(ppc64_rma_size, RTAS_INSTANTIATE_MAX);
> -#endif
> - rtas_rmo_buf = memblock_phys_alloc_range(RTAS_USER_REGION_SIZE, PAGE_SIZE,
> - 0, rtas_region);
> - if (!rtas_rmo_buf)
> - panic("ERROR: RTAS: Failed to allocate %lx bytes below %pa\n",
> - PAGE_SIZE, &rtas_region);
> -
> #ifdef CONFIG_RTAS_ERROR_LOGGING
> rtas_last_error_token = rtas_token("rtas-last-error");
> #endif
> -
> + rtas_user_region_setup();
> rtas_syscall_filter_init();
> }
>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/rtas-proc: remove unused RMO_READ_BUF_MAX
From: Alexey Kardashevskiy @ 2021-01-15 4:38 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, brking, ajd, aneesh.kumar
In-Reply-To: <20210114220004.1138993-3-nathanl@linux.ibm.com>
On 15/01/2021 09:00, Nathan Lynch wrote:
> This constant is unused.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> arch/powerpc/kernel/rtas-proc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
> index e0f8329966d6..d2b0d99824a4 100644
> --- a/arch/powerpc/kernel/rtas-proc.c
> +++ b/arch/powerpc/kernel/rtas-proc.c
> @@ -755,8 +755,6 @@ static int ppc_rtas_tone_volume_show(struct seq_file *m, void *v)
> return 0;
> }
>
> -#define RMO_READ_BUF_MAX 30
> -
> /**
> * ppc_rtas_rmo_buf_show() - Describe RTAS-addressable region for user space.
> *
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/rtas: rename RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE
From: Alexey Kardashevskiy @ 2021-01-15 4:38 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, brking, ajd, aneesh.kumar
In-Reply-To: <20210114220004.1138993-6-nathanl@linux.ibm.com>
On 15/01/2021 09:00, Nathan Lynch wrote:
> RTAS_RMOBUF_MAX doesn't actually describe a "maximum" value in any
> sense. It represents the size of an area of memory set aside for user
> space to use as work areas for certain RTAS calls.
>
> Rename it to RTAS_USER_REGION, and express the value in terms of the
> number of work areas allocated.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
>
> squash! powerpc/rtas: rename RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE
> ---
> arch/powerpc/include/asm/rtas.h | 9 ++++++---
> arch/powerpc/kernel/rtas-proc.c | 2 +-
> arch/powerpc/kernel/rtas.c | 2 +-
> 3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
> index 332e1000ca0f..1aa7ab1cbc84 100644
> --- a/arch/powerpc/include/asm/rtas.h
> +++ b/arch/powerpc/include/asm/rtas.h
> @@ -19,8 +19,11 @@
> #define RTAS_UNKNOWN_SERVICE (-1)
> #define RTAS_INSTANTIATE_MAX (1ULL<<30) /* Don't instantiate rtas at/above this value */
>
> -/* Buffer size for ppc_rtas system call. */
> -#define RTAS_RMOBUF_MAX (64 * 1024)
> +/* Work areas shared with RTAS must be 4K, naturally aligned. */
Why exactly 4K and not (for example) PAGE_SIZE?
> +#define RTAS_WORK_AREA_SIZE 4096
> +
> +/* Work areas allocated for user space access. */
> +#define RTAS_USER_REGION_SIZE (RTAS_WORK_AREA_SIZE * 16)
This is still 64K but no clarity why. There is 16 of something, what is it?
>
> /* RTAS return status codes */
> #define RTAS_BUSY -2 /* RTAS Busy */
> @@ -357,7 +360,7 @@ extern void rtas_take_timebase(void);
> static inline int page_is_rtas_user_buf(unsigned long pfn)
> {
> unsigned long paddr = (pfn << PAGE_SHIFT);
> - if (paddr >= rtas_rmo_buf && paddr < (rtas_rmo_buf + RTAS_RMOBUF_MAX))
> + if (paddr >= rtas_rmo_buf && paddr < (rtas_rmo_buf + RTAS_USER_REGION_SIZE))
> return 1;
> return 0;
> }
> diff --git a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
> index d2b0d99824a4..6857a5b0a1c3 100644
> --- a/arch/powerpc/kernel/rtas-proc.c
> +++ b/arch/powerpc/kernel/rtas-proc.c
> @@ -767,6 +767,6 @@ static int ppc_rtas_tone_volume_show(struct seq_file *m, void *v)
> */
> static int ppc_rtas_rmo_buf_show(struct seq_file *m, void *v)
> {
> - seq_printf(m, "%016lx %x\n", rtas_rmo_buf, RTAS_RMOBUF_MAX);
> + seq_printf(m, "%016lx %x\n", rtas_rmo_buf, RTAS_USER_REGION_SIZE);
> return 0;
> }
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index 55f6aa170e57..da65faadbbb2 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -1204,7 +1204,7 @@ void __init rtas_initialize(void)
> if (firmware_has_feature(FW_FEATURE_LPAR))
> rtas_region = min(ppc64_rma_size, RTAS_INSTANTIATE_MAX);
> #endif
> - rtas_rmo_buf = memblock_phys_alloc_range(RTAS_RMOBUF_MAX, PAGE_SIZE,
> + rtas_rmo_buf = memblock_phys_alloc_range(RTAS_USER_REGION_SIZE, PAGE_SIZE,
> 0, rtas_region);
> if (!rtas_rmo_buf)
> panic("ERROR: RTAS: Failed to allocate %lx bytes below %pa\n",
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 3/6] powerpc/rtas: remove ibm_suspend_me_token
From: Alexey Kardashevskiy @ 2021-01-15 4:38 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, brking, ajd, aneesh.kumar
In-Reply-To: <20210114220004.1138993-4-nathanl@linux.ibm.com>
On 15/01/2021 09:00, Nathan Lynch wrote:
> There's not a compelling reason to cache the value of the token for
> the ibm,suspend-me function. Just look it up when needed in the RTAS
> syscall's special case for it.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> arch/powerpc/kernel/rtas.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index d126d71ea5bd..60fcf7f7b0b8 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -828,7 +828,6 @@ void rtas_activate_firmware(void)
> pr_err("ibm,activate-firmware failed (%i)\n", fwrc);
> }
>
> -static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
> #ifdef CONFIG_PPC_PSERIES
> /**
> * rtas_call_reentrant() - Used for reentrant rtas calls
> @@ -1103,7 +1102,7 @@ SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
> return -EINVAL;
>
> /* Need to handle ibm,suspend_me call specially */
> - if (token == ibm_suspend_me_token) {
> + if (token == rtas_token("ibm,suspend-me")) {
>
> /*
> * rtas_ibm_suspend_me assumes the streamid handle is in cpu
> @@ -1191,10 +1190,8 @@ void __init rtas_initialize(void)
> * the stop-self token if any
> */
> #ifdef CONFIG_PPC64
> - if (firmware_has_feature(FW_FEATURE_LPAR)) {
> + if (firmware_has_feature(FW_FEATURE_LPAR))
> rtas_region = min(ppc64_rma_size, RTAS_INSTANTIATE_MAX);
> - ibm_suspend_me_token = rtas_token("ibm,suspend-me");
> - }
> #endif
> rtas_rmo_buf = memblock_phys_alloc_range(RTAS_RMOBUF_MAX, PAGE_SIZE,
> 0, rtas_region);
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/rtas: improve ppc_rtas_rmo_buf_show documentation
From: Alexey Kardashevskiy @ 2021-01-15 4:38 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, brking, ajd, aneesh.kumar
In-Reply-To: <20210114220004.1138993-2-nathanl@linux.ibm.com>
On 15/01/2021 08:59, Nathan Lynch wrote:
> Add kerneldoc for ppc_rtas_rmo_buf_show(), the callback for
> /proc/powerpc/rtas/rmo_buffer, explaining its expected use.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
> arch/powerpc/kernel/rtas-proc.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
> index 2d33f342a293..e0f8329966d6 100644
> --- a/arch/powerpc/kernel/rtas-proc.c
> +++ b/arch/powerpc/kernel/rtas-proc.c
> @@ -757,7 +757,16 @@ static int ppc_rtas_tone_volume_show(struct seq_file *m, void *v)
>
> #define RMO_READ_BUF_MAX 30
>
> -/* RTAS Userspace access */
> +/**
> + * ppc_rtas_rmo_buf_show() - Describe RTAS-addressable region for user space.
> + *
> + * Base + size description of a range of RTAS-addressable memory set
> + * aside for user space to use as work area(s) for certain RTAS
> + * functions. User space accesses this region via /dev/mem.
mmm ufff wuuuuut argh^w^w^w^w Thanks for documenting it :)
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Apart from
> + * security policies, the kernel does not arbitrate or serialize
> + * access to this region, and user space must ensure that concurrent
> + * users do not interfere with each other.
> + */
> static int ppc_rtas_rmo_buf_show(struct seq_file *m, void *v)
> {
> seq_printf(m, "%016lx %x\n", rtas_rmo_buf, RTAS_RMOBUF_MAX);
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 4/6] powerpc/rtas: move syscall filter setup into separate function
From: Alexey Kardashevskiy @ 2021-01-15 4:39 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, brking, ajd, aneesh.kumar
In-Reply-To: <20210114220004.1138993-5-nathanl@linux.ibm.com>
On 15/01/2021 09:00, Nathan Lynch wrote:
> Reduce conditionally compiled sections within rtas_initialize() by
> moving the filter table initialization into its own function already
> guarded by CONFIG_PPC_RTAS_FILTER. No behavior change intended.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
> arch/powerpc/kernel/rtas.c | 23 +++++++++++++++--------
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index 60fcf7f7b0b8..55f6aa170e57 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -1051,6 +1051,16 @@ static bool block_rtas_call(int token, int nargs,
> return true;
> }
>
> +static void __init rtas_syscall_filter_init(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rtas_filters); i++) {
> + rtas_filters[i].token = rtas_token(rtas_filters[i].name);
> + }
> +
Unnecessary curly braces (I understand it is cut-n-paste but still) and
an empty line. Otherwise:
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> +}
> +
> #else
>
> static bool block_rtas_call(int token, int nargs,
> @@ -1059,6 +1069,10 @@ static bool block_rtas_call(int token, int nargs,
> return false;
> }
>
> +static void __init rtas_syscall_filter_init(void)
> +{
> +}
> +
> #endif /* CONFIG_PPC_RTAS_FILTER */
>
> /* We assume to be passed big endian arguments */
> @@ -1162,9 +1176,6 @@ void __init rtas_initialize(void)
> unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
> u32 base, size, entry;
> int no_base, no_size, no_entry;
> -#ifdef CONFIG_PPC_RTAS_FILTER
> - int i;
> -#endif
>
> /* Get RTAS dev node and fill up our "rtas" structure with infos
> * about it.
> @@ -1203,11 +1214,7 @@ void __init rtas_initialize(void)
> rtas_last_error_token = rtas_token("rtas-last-error");
> #endif
>
> -#ifdef CONFIG_PPC_RTAS_FILTER
> - for (i = 0; i < ARRAY_SIZE(rtas_filters); i++) {
> - rtas_filters[i].token = rtas_token(rtas_filters[i].name);
> - }
> -#endif
> + rtas_syscall_filter_init();
> }
>
> int __init early_init_dt_scan_rtas(unsigned long node,
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 4/6] powerpc/rtas: move syscall filter setup into separate function
From: Andrew Donnellan @ 2021-01-15 5:49 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: aik, tyreld, brking, aneesh.kumar
In-Reply-To: <20210114220004.1138993-5-nathanl@linux.ibm.com>
On 15/1/21 9:00 am, Nathan Lynch wrote:
> Reduce conditionally compiled sections within rtas_initialize() by
> moving the filter table initialization into its own function already
> guarded by CONFIG_PPC_RTAS_FILTER. No behavior change intended.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
> +static void __init rtas_syscall_filter_init(void)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rtas_filters); i++) {
> + rtas_filters[i].token = rtas_token(rtas_filters[i].name);
> + }
> +
> +}
Unnecessary empty line, but vitally important braces :)
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/rtas: improve ppc_rtas_rmo_buf_show documentation
From: Andrew Donnellan @ 2021-01-15 5:50 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: aik, tyreld, brking, aneesh.kumar
In-Reply-To: <20210114220004.1138993-2-nathanl@linux.ibm.com>
On 15/1/21 8:59 am, Nathan Lynch wrote:
> Add kerneldoc for ppc_rtas_rmo_buf_show(), the callback for
> /proc/powerpc/rtas/rmo_buffer, explaining its expected use.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Looks good.
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/rtas-proc: remove unused RMO_READ_BUF_MAX
From: Andrew Donnellan @ 2021-01-15 5:52 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: aik, tyreld, brking, aneesh.kumar
In-Reply-To: <20210114220004.1138993-3-nathanl@linux.ibm.com>
On 15/1/21 9:00 am, Nathan Lynch wrote:
> This constant is unused.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
A quick grep agrees.
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
> ---
> arch/powerpc/kernel/rtas-proc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
> index e0f8329966d6..d2b0d99824a4 100644
> --- a/arch/powerpc/kernel/rtas-proc.c
> +++ b/arch/powerpc/kernel/rtas-proc.c
> @@ -755,8 +755,6 @@ static int ppc_rtas_tone_volume_show(struct seq_file *m, void *v)
> return 0;
> }
>
> -#define RMO_READ_BUF_MAX 30
> -
> /**
> * ppc_rtas_rmo_buf_show() - Describe RTAS-addressable region for user space.
> *
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 3/6] powerpc/rtas: remove ibm_suspend_me_token
From: Andrew Donnellan @ 2021-01-15 5:52 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: aik, tyreld, brking, aneesh.kumar
In-Reply-To: <20210114220004.1138993-4-nathanl@linux.ibm.com>
On 15/1/21 9:00 am, Nathan Lynch wrote:
> There's not a compelling reason to cache the value of the token for
> the ibm,suspend-me function. Just look it up when needed in the RTAS
> syscall's special case for it.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
> ---
> arch/powerpc/kernel/rtas.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index d126d71ea5bd..60fcf7f7b0b8 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -828,7 +828,6 @@ void rtas_activate_firmware(void)
> pr_err("ibm,activate-firmware failed (%i)\n", fwrc);
> }
>
> -static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
> #ifdef CONFIG_PPC_PSERIES
> /**
> * rtas_call_reentrant() - Used for reentrant rtas calls
> @@ -1103,7 +1102,7 @@ SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
> return -EINVAL;
>
> /* Need to handle ibm,suspend_me call specially */
> - if (token == ibm_suspend_me_token) {
> + if (token == rtas_token("ibm,suspend-me")) {
>
> /*
> * rtas_ibm_suspend_me assumes the streamid handle is in cpu
> @@ -1191,10 +1190,8 @@ void __init rtas_initialize(void)
> * the stop-self token if any
> */
> #ifdef CONFIG_PPC64
> - if (firmware_has_feature(FW_FEATURE_LPAR)) {
> + if (firmware_has_feature(FW_FEATURE_LPAR))
> rtas_region = min(ppc64_rma_size, RTAS_INSTANTIATE_MAX);
> - ibm_suspend_me_token = rtas_token("ibm,suspend-me");
> - }
> #endif
> rtas_rmo_buf = memblock_phys_alloc_range(RTAS_RMOBUF_MAX, PAGE_SIZE,
> 0, rtas_region);
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/rtas: rename RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE
From: Andrew Donnellan @ 2021-01-15 6:10 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: aik, tyreld, brking, aneesh.kumar
In-Reply-To: <20210114220004.1138993-6-nathanl@linux.ibm.com>
On 15/1/21 9:00 am, Nathan Lynch wrote:
> RTAS_RMOBUF_MAX doesn't actually describe a "maximum" value in any
> sense. It represents the size of an area of memory set aside for user
> space to use as work areas for certain RTAS calls.
>
> Rename it to RTAS_USER_REGION, and express the value in terms of the
> number of work areas allocated.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
>
> squash! powerpc/rtas: rename RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE
I think you meant to get rid of this line...
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH] powerpc/sstep: Fix array out of bound warning
From: Ravi Bangoria @ 2021-01-15 6:16 UTC (permalink / raw)
To: mpe; +Cc: naveen.n.rao, ravi.bangoria, paulus, linuxppc-dev, jniethe5
Compiling kernel with -Warray-bounds throws below warning:
In function 'emulate_vsx_store':
warning: array subscript is above array bounds [-Warray-bounds]
buf.d[2] = byterev_8(reg->d[1]);
~~~~~^~~
buf.d[3] = byterev_8(reg->d[0]);
~~~~~^~~
Fix it by converting local variable 'union vsx_reg buf' into an array.
Also consider function argument 'union vsx_reg *reg' as array instead
of pointer because callers are actually passing an array to it.
Fixes: af99da74333b ("powerpc/sstep: Support VSX vector paired storage access instructions")
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 61 ++++++++++++++++++++--------------------
1 file changed, 31 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index bf7a7d62ae8b..5b4281ade5b6 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -723,7 +723,8 @@ void emulate_vsx_load(struct instruction_op *op, union vsx_reg *reg,
const unsigned char *bp;
size = GETSIZE(op->type);
- reg->d[0] = reg->d[1] = 0;
+ reg[0].d[0] = reg[0].d[1] = 0;
+ reg[1].d[0] = reg[1].d[1] = 0;
switch (op->element_size) {
case 32:
@@ -742,25 +743,25 @@ void emulate_vsx_load(struct instruction_op *op, union vsx_reg *reg,
/* scalar loads, lxvd2x, lxvdsx */
read_size = (size >= 8) ? 8 : size;
i = IS_LE ? 8 : 8 - read_size;
- memcpy(®->b[i], mem, read_size);
+ memcpy(®[0].b[i], mem, read_size);
if (rev)
- do_byte_reverse(®->b[i], 8);
+ do_byte_reverse(®[0].b[i], 8);
if (size < 8) {
if (op->type & SIGNEXT) {
/* size == 4 is the only case here */
- reg->d[IS_LE] = (signed int) reg->d[IS_LE];
+ reg[0].d[IS_LE] = (signed int)reg[0].d[IS_LE];
} else if (op->vsx_flags & VSX_FPCONV) {
preempt_disable();
- conv_sp_to_dp(®->fp[1 + IS_LE],
- ®->dp[IS_LE]);
+ conv_sp_to_dp(®[0].fp[1 + IS_LE],
+ ®[0].dp[IS_LE]);
preempt_enable();
}
} else {
if (size == 16) {
unsigned long v = *(unsigned long *)(mem + 8);
- reg->d[IS_BE] = !rev ? v : byterev_8(v);
+ reg[0].d[IS_BE] = !rev ? v : byterev_8(v);
} else if (op->vsx_flags & VSX_SPLAT)
- reg->d[IS_BE] = reg->d[IS_LE];
+ reg[0].d[IS_BE] = reg[0].d[IS_LE];
}
break;
case 4:
@@ -768,13 +769,13 @@ void emulate_vsx_load(struct instruction_op *op, union vsx_reg *reg,
wp = mem;
for (j = 0; j < size / 4; ++j) {
i = IS_LE ? 3 - j : j;
- reg->w[i] = !rev ? *wp++ : byterev_4(*wp++);
+ reg[0].w[i] = !rev ? *wp++ : byterev_4(*wp++);
}
if (op->vsx_flags & VSX_SPLAT) {
- u32 val = reg->w[IS_LE ? 3 : 0];
+ u32 val = reg[0].w[IS_LE ? 3 : 0];
for (; j < 4; ++j) {
i = IS_LE ? 3 - j : j;
- reg->w[i] = val;
+ reg[0].w[i] = val;
}
}
break;
@@ -783,7 +784,7 @@ void emulate_vsx_load(struct instruction_op *op, union vsx_reg *reg,
hp = mem;
for (j = 0; j < size / 2; ++j) {
i = IS_LE ? 7 - j : j;
- reg->h[i] = !rev ? *hp++ : byterev_2(*hp++);
+ reg[0].h[i] = !rev ? *hp++ : byterev_2(*hp++);
}
break;
case 1:
@@ -791,7 +792,7 @@ void emulate_vsx_load(struct instruction_op *op, union vsx_reg *reg,
bp = mem;
for (j = 0; j < size; ++j) {
i = IS_LE ? 15 - j : j;
- reg->b[i] = *bp++;
+ reg[0].b[i] = *bp++;
}
break;
}
@@ -804,7 +805,7 @@ void emulate_vsx_store(struct instruction_op *op, const union vsx_reg *reg,
{
int size, write_size;
int i, j;
- union vsx_reg buf;
+ union vsx_reg buf[2];
unsigned int *wp;
unsigned short *hp;
unsigned char *bp;
@@ -818,11 +819,11 @@ void emulate_vsx_store(struct instruction_op *op, const union vsx_reg *reg,
break;
if (rev) {
/* reverse 32 bytes */
- buf.d[0] = byterev_8(reg->d[3]);
- buf.d[1] = byterev_8(reg->d[2]);
- buf.d[2] = byterev_8(reg->d[1]);
- buf.d[3] = byterev_8(reg->d[0]);
- reg = &buf;
+ buf[0].d[0] = byterev_8(reg[1].d[1]);
+ buf[0].d[1] = byterev_8(reg[1].d[0]);
+ buf[1].d[0] = byterev_8(reg[0].d[1]);
+ buf[1].d[1] = byterev_8(reg[0].d[0]);
+ reg = buf;
}
memcpy(mem, reg, size);
break;
@@ -834,9 +835,9 @@ void emulate_vsx_store(struct instruction_op *op, const union vsx_reg *reg,
rev = !rev;
if (rev) {
/* reverse 16 bytes */
- buf.d[0] = byterev_8(reg->d[1]);
- buf.d[1] = byterev_8(reg->d[0]);
- reg = &buf;
+ buf[0].d[0] = byterev_8(reg[0].d[1]);
+ buf[0].d[1] = byterev_8(reg[0].d[0]);
+ reg = buf;
}
memcpy(mem, reg, size);
break;
@@ -845,15 +846,15 @@ void emulate_vsx_store(struct instruction_op *op, const union vsx_reg *reg,
write_size = (size >= 8) ? 8 : size;
i = IS_LE ? 8 : 8 - write_size;
if (size < 8 && op->vsx_flags & VSX_FPCONV) {
- buf.d[0] = buf.d[1] = 0;
+ buf[0].d[0] = buf[0].d[1] = 0;
preempt_disable();
- conv_dp_to_sp(®->dp[IS_LE], &buf.fp[1 + IS_LE]);
+ conv_dp_to_sp(®[0].dp[IS_LE], &buf[0].fp[1 + IS_LE]);
preempt_enable();
- reg = &buf;
+ reg = buf;
}
- memcpy(mem, ®->b[i], write_size);
+ memcpy(mem, ®[0].b[i], write_size);
if (size == 16)
- memcpy(mem + 8, ®->d[IS_BE], 8);
+ memcpy(mem + 8, ®[0].d[IS_BE], 8);
if (unlikely(rev)) {
do_byte_reverse(mem, write_size);
if (size == 16)
@@ -865,7 +866,7 @@ void emulate_vsx_store(struct instruction_op *op, const union vsx_reg *reg,
wp = mem;
for (j = 0; j < size / 4; ++j) {
i = IS_LE ? 3 - j : j;
- *wp++ = !rev ? reg->w[i] : byterev_4(reg->w[i]);
+ *wp++ = !rev ? reg[0].w[i] : byterev_4(reg[0].w[i]);
}
break;
case 2:
@@ -873,7 +874,7 @@ void emulate_vsx_store(struct instruction_op *op, const union vsx_reg *reg,
hp = mem;
for (j = 0; j < size / 2; ++j) {
i = IS_LE ? 7 - j : j;
- *hp++ = !rev ? reg->h[i] : byterev_2(reg->h[i]);
+ *hp++ = !rev ? reg[0].h[i] : byterev_2(reg[0].h[i]);
}
break;
case 1:
@@ -881,7 +882,7 @@ void emulate_vsx_store(struct instruction_op *op, const union vsx_reg *reg,
bp = mem;
for (j = 0; j < size; ++j) {
i = IS_LE ? 15 - j : j;
- *bp++ = reg->b[i];
+ *bp++ = reg[0].b[i];
}
break;
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] perf tools: Resolve symbols against debug file first
From: Namhyung Kim @ 2021-01-15 7:37 UTC (permalink / raw)
To: Michael Ellerman
Cc: Mark Rutland, Peter Zijlstra, Jiri Slaby, linuxppc-dev,
linux-kernel, Arnaldo Carvalho de Melo, Alexander Shishkin,
Ingo Molnar, Jiri Olsa
In-Reply-To: <87sg73kbsq.fsf@mpe.ellerman.id.au>
Hello,
On Thu, Jan 14, 2021 at 8:17 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Namhyung Kim <namhyung@kernel.org> writes:
> > On Wed, Jan 13, 2021 at 8:43 PM Jiri Slaby <jslaby@suse.cz> wrote:
> >>
> >> On 13. 01. 21, 11:46, Jiri Olsa wrote:
> >> > On Wed, Jan 13, 2021 at 09:01:28AM +0100, Jiri Slaby wrote:
> >> >> With LTO, there are symbols like these:
> >> >> /usr/lib/debug/usr/lib64/libantlr4-runtime.so.4.8-4.8-1.4.x86_64.debug
> >> >> 10305: 0000000000955fa4 0 NOTYPE LOCAL DEFAULT 29 Predicate.cpp.2bc410e7
> >> >>
> >> >> This comes from a runtime/debug split done by the standard way:
> >> >> objcopy --only-keep-debug $runtime $debug
> >> >> objcopy --add-gnu-debuglink=$debugfn -R .comment -R .GCC.command.line --strip-all $runtime
> >> >>
> ...
> >> >> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> >> >> index f3577f7d72fe..a31b716fa61c 100644
> >> >> --- a/tools/perf/util/symbol-elf.c
> >> >> +++ b/tools/perf/util/symbol-elf.c
> >> >> @@ -1226,12 +1226,20 @@ int dso__load_sym(struct dso *dso, struct map *map, struct symsrc *syms_ss,
> >> >> if (sym.st_shndx == SHN_ABS)
> >> >> continue;
> >> >>
> >> >> - sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
> >> >> + sec = elf_getscn(syms_ss->elf, sym.st_shndx);
> >> >> if (!sec)
> >> >> goto out_elf_end;
> >> >
> >> > we iterate symbols from syms_ss, so the fix seems to be correct
> >> > to call elf_getscn on syms_ss, not on runtime_ss as we do now
> >> >
> >> > I'd think this worked only when runtime_ss == syms_ss
> >>
> >> No, because the headers are copied 1:1 from runtime_ss to syms_ss. And
> >> runtime_ss is then stripped, so only .debug* sections are removed there.
> >> (And syms_ss's are set as NOBITS.)
> >>
> >> We iterated .debug* sections in syms_ss and used runtime_ss section
> >> _headers_ only to adjust symbols (sometimes). That worked.
> >
> > It seems PPC has an opd section only in the runtime_ss and that's why
> > we use it for section headers.
>
> At least on my system (Ubuntu 20.04.1) I see .opd in the debug file with
> NOBITS set:
>
> $ readelf -e vmlinux.debug | grep opd
> [37] .opd NOBITS c000000001c1f548 01202e14
>
>
> But possibly that's not the case with older toolchains?
I was referring to this commit:
commit 261360b6e90a782f0a63d8f61a67683c376c88cf
Author: Cody P Schafer <cody@linux.vnet.ibm.com>
Date: Fri Aug 10 15:23:01 2012 -0700
perf symbols: Convert dso__load_syms to take 2 symsrc's
To properly handle platforms with an opd section, both a runtime image
(which contains the opd section but possibly lacks symbols) and a symbol
image (which probably lacks an opd section but has symbols).
The next patch ("perf symbol: use both runtime and debug images")
adjusts the callsite in dso__load() to take advantage of being able to
pass both runtime & debug images.
Assumptions made here:
- The opd section, if it exists in the runtime image, has headers in
both the runtime image and the debug/syms image.
- The index of the opd section (again, only if it exists in the runtime
image) is the same in both the runtime and debug/symbols image.
Both of these are true on RHEL, but it is unclear how accurate they are
in general (on platforms with function descriptors in opd sections).
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Thanks,
Namhyung
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox