On 4/14/21 10:52 AM, Christophe Leroy wrote:
>
>
> Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
>> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
>> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
>> for those platforms which would
Christophe Leroy writes:
> When probe_kernel_read_inst() was created, it was to mimic
> probe_kernel_read() function.
>
> Since then, probe_kernel_read() has been renamed
> copy_from_kernel_nofault().
>
> Rename probe_kernel_read_inst() into copy_from_kernel_nofault_inst().
At first glance I
Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
for those platforms which would override generic default FIRST_USER_ADDRESS
value 0UL. This
Vaibhav Jain writes:
> Hi Shiva,
>
> Apologies for a late review but something just caught my eye while
> working on a different patch.
>
> Shivaprasad G Bhat writes:
>
>> Add support for ND_REGION_ASYNC capability if the device tree
>> indicates 'ibm,hcall-flush-required' property in the
On Mon, 2021-04-12 at 17:21 -0500, Segher Boessenkool wrote:
> On Fri, Apr 09, 2021 at 02:36:16PM +1000, Alexey Kardashevskiy wrote:
> > On 08/04/2021 19:04, Michael Ellerman wrote:
> > > > > > +#define QUERY_DDW_PGSIZE_4K0x01
> > > > > > +#define QUERY_DDW_PGSIZE_64K 0x02
> > > > >
On Sat, Apr 10, 2021 at 12:33 AM Michal Suchánek wrote:
>
> Hello,
>
> On Fri, Aug 28, 2020 at 04:10:09PM +0800, Pingfan Liu wrote:
> > On Thu, Aug 27, 2020 at 3:53 PM Laurent Dufour
> > wrote:
> > >
> > > Le 10/08/2020 à 10:52, Pingfan Liu a écrit :
> > > > A bug is observed on pseries by
Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
for those platforms which would override generic default FIRST_USER_ADDRESS
value 0UL. This makes it much cleaner with reduced code.
Cc:
Excerpts from Segher Boessenkool's message of April 14, 2021 7:58 am:
> On Tue, Apr 13, 2021 at 06:33:19PM +0200, Christophe Leroy wrote:
>> Le 12/04/2021 à 23:54, Segher Boessenkool a écrit :
>> >On Thu, Apr 08, 2021 at 03:33:44PM +, Christophe Leroy wrote:
>> >>For clear bits, on 32 bits
On Tue, 2021-04-13 at 18:24 +1000, Alexey Kardashevskiy wrote:
>
> On 13/04/2021 17:58, Leonardo Bras wrote:
> > On Tue, 2021-04-13 at 17:41 +1000, Alexey Kardashevskiy wrote:
> > >
> > > On 13/04/2021 17:33, Leonardo Bras wrote:
> > > > On Tue, 2021-04-13 at 17:18 +1000, Alexey Kardashevskiy
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Mon, 12 Apr 2021 19:47:16 +0200 you wrote:
> of_get_mac_address() is commonly used to fetch the MAC address
> from the device tree. It also supports reading it from a NVMEM
> provider. But the latter is only possible
On Tue, Apr 13, 2021 at 06:33:19PM +0200, Christophe Leroy wrote:
> Le 12/04/2021 à 23:54, Segher Boessenkool a écrit :
> >On Thu, Apr 08, 2021 at 03:33:44PM +, Christophe Leroy wrote:
> >>For clear bits, on 32 bits 'rlwinm' can be used instead or 'andc' for
> >>when all bits to be cleared are
On 2/11/21 10:24 AM, Tyrel Datwyler wrote:
> The pci_bus->bridge reference may no longer be valid after
> pci_bus_remove() resulting in passing a bad value to device_unregister()
> for the associated bridge device.
>
> Store the host_bridge reference in a separate variable prior to
>
When probe_kernel_read_inst() was created, there was no good place to
put it, so a file called lib/inst.c was dedicated for it.
Since then, probe_kernel_read_inst() has been renamed
copy_from_kernel_nofault_inst(). And mm/maccess.h didn't exist at that
time. Today, mm/maccess.h is related to
When probe_kernel_read_inst() was created, it was to mimic
probe_kernel_read() function.
Since then, probe_kernel_read() has been renamed
copy_from_kernel_nofault().
Rename probe_kernel_read_inst() into copy_from_kernel_nofault_inst().
Signed-off-by: Christophe Leroy
---
Its name comes from former probe_user_read() function.
That function is now called copy_from_user_nofault().
probe_user_read_inst() uses copy_from_user_nofault() to read only
a few bytes. It is suboptimal.
It does the same as get_user_inst() but in addition disables
page faults.
But on the
We have two independant versions of probe_kernel_read_inst(), one for
PPC32 and one for PPC64.
The PPC32 is identical to the first part of the PPC64 version.
The remaining part of PPC64 version is not relevant for PPC32, but
not contradictory, so we can easily have a common function with
the
Using asm goto in __WARN_FLAGS() and WARN_ON() allows more
flexibility to GCC.
For that add an entry to the exception table so that
program_check_exception() knowns where to resume execution
after a WARNING.
Here are two exemples. The first one is done on PPC32 (which
benefits from the previous
powerpc BUG_ON() and WARN_ON() are based on using twnei instruction.
For catching simple conditions like a variable having value 0, this
is efficient because it does the test and the trap at the same time.
But most conditions used with BUG_ON or WARN_ON are more complex and
forces GCC to format
Now that atomic_add() and atomic_sub() handle immediate operands,
atomic_inc() and atomic_dec() have no added value compared to the
generic fallback which calls atomic_add(1) and atomic_sub(1).
Also remove atomic_inc_not_zero() which fallsback to
atomic_add_unless() which itself fallsback to
Today we get the following code generation for atomic operations:
c001bb2c: 39 20 00 01 li r9,1
c001bb30: 7d 40 18 28 lwarx r10,0,r3
c001bb34: 7d 09 50 50 subfr8,r9,r10
c001bb38: 7d 00 19 2d stwcx. r8,0,r3
Today we get the following code generation for bitops like
set or clear bit:
c0009fe0: 39 40 08 00 li r10,2048
c0009fe4: 7c e0 40 28 lwarx r7,0,r8
c0009fe8: 7c e7 53 78 or r7,r7,r10
c0009fec: 7c e0 41 2d stwcx.
Le 13/04/2021 à 00:08, Segher Boessenkool a écrit :
Hi!
On Thu, Apr 08, 2021 at 03:33:45PM +, Christophe Leroy wrote:
+#define ATOMIC_OP(op, asm_op, dot, sign) \
static __inline__ void atomic_##op(int a, atomic_t *v)
\
{
Le 12/04/2021 à 23:54, Segher Boessenkool a écrit :
Hi!
On Thu, Apr 08, 2021 at 03:33:44PM +, Christophe Leroy wrote:
For clear bits, on 32 bits 'rlwinm' can be used instead or 'andc' for
when all bits to be cleared are consecutive.
Also on 64-bits, as long as both the top and bottom
Hi Shiva,
Apologies for a late review but something just caught my eye while
working on a different patch.
Shivaprasad G Bhat writes:
> Add support for ND_REGION_ASYNC capability if the device tree
> indicates 'ibm,hcall-flush-required' property in the NVDIMM node.
> Flush is done by issuing
irq_work's use of the DEC SPR is racy with guest<->host switch and guest
entry which flips the DEC interrupt to guest, which could lose a host
work interrupt.
This patch closes one race, and attempts to comment another class of
races.
Signed-off-by: Nicholas Piggin
---
LPCR[HDICE]=0 suppresses hypervisor decrementer exceptions on some
processors, so it must be enabled before HDEC is set.
Rather than set it in the host LPCR then setting HDEC, move the HDEC
update to after the guest MMU context (including LPCR) is loaded.
There shouldn't be much concern with
These are small timer improvement and buglet fix, taken from the
KVM Cify series.
This is the last one for the upcoming merge window.
Thanks,
Nick
Nicholas Piggin (2):
KVM: PPC: Book3S HV P9: Move setting HDEC after switching to guest
LPCR
KVM: PPC: Book3S HV P9: Reduce irq_work vs
This is more symmetric with kvmppc_xive_push_vcpu, and has the advantage
that it runs with the MMU on.
The extra test added to the asm will go away with a future change.
Reviewed-by: Cédric Le Goater
Reviewed-by: Alexey Kardashevskiy
Signed-off-by: Nicholas Piggin
---
Another bit that came
The 'chip_id' field of the XIVE CPU structure is used to choose a
target for a source located on the same chip. For that, the XIVE
driver queries the chip identifier from the "ibm,chip-id" property
and compares it to a 'src_chip' field identifying the chip of a
source. This information is only
Christophe Leroy writes:
> Le 11/04/2021 à 02:31, Haren Myneni a écrit :
>>
>> Using the same /dev/crypto/nx-gzip interface for both powerNV and
>> pseries. So this patcb moves VAS API to powerpc platform indepedent
>> directory. The actual functionality is not changed in this patch.
>
> This
Srikar Dronamraju writes:
>
> Some of the per-CPU masks use cpu_cpu_mask as a filter to limit the search
> for related CPUs. On a dlpar add of a CPU, update cpu_cpu_mask before
> updating the per-CPU masks. This will ensure the cpu_cpu_mask is updated
> correctly before its used in setting the
Srikar Dronamraju writes:
> That leaves us with just 2 options for now.
> 1. Update numa_mem later and only update numa_node here.
> - Over a longer period of time, this would be more confusing since we
> may lose track of why we are splitting the set of numa_node and numa_mem.
>
> or
> 2. Use my
Changes to export the following NXGZIP capabilities through sysfs:
/sys/devices/vio/ibm,compression-v1/NxGzCaps:
min_compress_len /*Recommended minimum compress length in bytes*/
min_decompress_len /*Recommended minimum decompress length in bytes*/
req_max_processed_len /* Maximum number of
phyp provides NX capabilities which gives recommended minimum
compression / decompression length and maximum request buffer size
in bytes.
Changes to get NX overall capabilities which points to the specific
features phyp supports. Then retrieve NXGZIP specific capabilities.
Signed-off-by:
Changes to create /dev/crypto/nx-gzip interface with VAS register
and to remove this interface with VAS unregister.
Signed-off-by: Haren Myneni
---
drivers/crypto/nx/Kconfig | 1 +
drivers/crypto/nx/nx-common-pseries.c | 9 +
2 files changed, 10 insertions(+)
diff --git
Rename nx-842-pseries.c to nx-common-pseries.c to add code for new
GZIP compression type. The actual functionality is not changed in
this patch.
Signed-off-by: Haren Myneni
---
drivers/crypto/nx/Makefile | 2 +-
drivers/crypto/nx/{nx-842-pseries.c =>
pHyp provides GZIP default and GZIP QoS capabilities which gives
the total number of credits are available in LPAR. This patch
creates sysfs entries and exports LPAR credits, the currently used
and the available credits for each feature.
/sys/kernel/vas/VasCaps/VDefGzip: (default GZIP
When NX sees a fault on the user space buffer, generates a fault
interrupt and pHyp forwards that interrupt to OS. Then the kernel
makes H_GET_NX_FAULT HCALL to retrieve the fault CRB information.
This patch adds changes to setup IRQ per each window and handles
fault by updating CSB.
This patch adds VAS window allocatioa/close with the corresponding
HCALLs. Also changes to integrate with the existing user space VAS
API and provide register/unregister functions to NX pseries driver.
The driver register function is used to create the user space
interface (/dev/crypto/nx-gzip)
pHyp provides various VAS capabilities such as GZIP default and QoS
capabilities which are used to determine total number of credits
available in LPAR, maximum window credits, maximum LPAR credits,
whether usermode copy/paste is supported, and etc.
So first retrieve overall vas capabilities
On 13/04/2021 17:58, Leonardo Bras wrote:
On Tue, 2021-04-13 at 17:41 +1000, Alexey Kardashevskiy wrote:
On 13/04/2021 17:33, Leonardo Bras wrote:
On Tue, 2021-04-13 at 17:18 +1000, Alexey Kardashevskiy wrote:
On 13/04/2021 15:49, Leonardo Bras wrote:
Thanks for the feedback!
On Tue,
This patch adds the following HCALLs which are used to allocate,
modify and deallocate VAS windows.
H_ALLOCATE_VAS_WINDOW: Allocate VAS window
H_DEALLOCATE_VAS_WINDOW: Close VAS window
H_MODIFY_VAS_WINDOW: Setup window before using
Also adds phyp call (H_QUERY_VAS_CAPABILITIES) to get all VAS
pHyp introduces two different type of credits: Default and Quality
of service (QoS).
The total number of default credits available on each LPAR depends
on CPU resources configured. But these credits can be shared or
over-committed across LPARs in shared mode which can result in
paste command
This patch adds HCALLs and other definitions. Also define structs
that are used in VAS implementation on powerVM.
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/hvcall.h| 7 ++
arch/powerpc/include/asm/vas.h | 28
arch/powerpc/platforms/pseries/vas.h | 96
Same vas_window struct is used on powerNV and pseries. So this patch
changes in struct vas_window to support both platforms and also the
corresponding modifications in powerNV vas code.
On powerNV vas_window is used for both TX and RX windows, whereas
only for TX windows on powerVM. So some
NX issues an interrupt when sees fault on user space buffer. The
kernel processes the fault by updating CSB. This functionality is
same for both powerNV and pseries. So this patch moves these
functions to vas-api.c and the actual functionality is not changed.
Signed-off-by: Haren Myneni
---
Take task reference when each window opens and drops during close.
This functionality is needed for powerNV and pseries. So this patch
defines the existing code as functions in powerpc platform
independent vas-api.c
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/vas.h |
From: Matthew Wilcox
> Sent: 12 April 2021 19:24
>
> On Sun, Apr 11, 2021 at 11:43:07AM +0200, Jesper Dangaard Brouer wrote:
> > Could you explain your intent here?
> > I worry about @index.
> >
> > As I mentioned in other thread[1] netstack use page_is_pfmemalloc()
> > (code copy-pasted below
Using the same /dev/crypto/nx-gzip interface for both powerNV and
pseries. So this patch moves VAS API to powerpc platform indepedent
directory. The actual functionality is not changed in this patch.
Common interface functions such as open, window open ioctl, mmap
and close are moved to
powerNV and pseries drivers register / unregister to the corresponding
VAS code separately. So rename powerNV VAS API register/unregister
functions.
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/vas.h | 6 +++---
arch/powerpc/platforms/powernv/vas-api.c | 10 +-
This patch series enables VAS / NX-GZIP on powerVM which allows
the user space to do copy/paste with the same existing interface
that is available on powerNV.
VAS Enablement:
- Get all VAS capabilities using H_QUERY_VAS_CAPABILITIES that are
available in the hypervisor. These capabilities
On Tue, 2021-04-13 at 17:41 +1000, Alexey Kardashevskiy wrote:
>
> On 13/04/2021 17:33, Leonardo Bras wrote:
> > On Tue, 2021-04-13 at 17:18 +1000, Alexey Kardashevskiy wrote:
> > >
> > > On 13/04/2021 15:49, Leonardo Bras wrote:
> > > > Thanks for the feedback!
> > > >
> > > > On Tue,
On 13/04/2021 17:33, Leonardo Bras wrote:
On Tue, 2021-04-13 at 17:18 +1000, Alexey Kardashevskiy wrote:
On 13/04/2021 15:49, Leonardo Bras wrote:
Thanks for the feedback!
On Tue, 2020-09-29 at 13:56 +1000, Alexey Kardashevskiy wrote:
-static bool find_existing_ddw(struct device_node
On Tue, 2021-04-13 at 17:18 +1000, Alexey Kardashevskiy wrote:
>
> On 13/04/2021 15:49, Leonardo Bras wrote:
> > Thanks for the feedback!
> >
> > On Tue, 2020-09-29 at 13:56 +1000, Alexey Kardashevskiy wrote:
> > > > -static bool find_existing_ddw(struct device_node *pdn, u64 *dma_addr)
> > > >
On 13/04/2021 15:49, Leonardo Bras wrote:
Thanks for the feedback!
On Tue, 2020-09-29 at 13:56 +1000, Alexey Kardashevskiy wrote:
-static bool find_existing_ddw(struct device_node *pdn, u64 *dma_addr)
+static phys_addr_t ddw_memory_hotplug_max(void)
Please, forward declaration or a
On Mon, 12 Apr 2021 at 17:24, Mel Gorman wrote:
>
> On Mon, Apr 12, 2021 at 02:21:47PM +0200, Vincent Guittot wrote:
> > > > Peter, Valentin, Vincent, Mel, etal
> > > >
> > > > On architectures where we have multiple levels of cache access latencies
> > > > within a DIE, (For example: one within
Thomas Gleixner writes:
> On Wed, Mar 31 2021 at 16:48, Christophe Leroy wrote:
>> [Sorry, resending with complete destination list, I used the wrong script on
>> the first delivery]
>>
>> This series adds support for time namespaces on powerpc.
>>
>> All timens selftests are successfull.
>
> If
On Wed, 2020-09-30 at 17:29 +1000, Alexey Kardashevskiy wrote:
>
> On 30/09/2020 06:54, Leonardo Bras wrote:
> > On Tue, 2020-09-29 at 13:55 +1000, Alexey Kardashevskiy wrote:
> > >
> > > On 12/09/2020 03:07, Leonardo Bras wrote:
> > > > Cc: linuxppc-dev@lists.ozlabs.org,
58 matches
Mail list logo
