Skips slow part of serialize_against_pte_lookup if there is no running
lockless pagetable walk.
Signed-off-by: Leonardo Bras
---
arch/powerpc/mm/book3s64/pgtable.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s64/pgtable.c
b/arch/powerpc/mm/book3s64
Enables count-based monitoring method for lockless pagetable walks on
PowerPC book3s_64.
Other architectures/platforms fallback to using generic dummy functions.
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 5 +
1 file changed, 5 insertions(+)
diff --git
Applies the counting-based method for monitoring all book3s_64-related
functions that do lockless pagetable walks.
Adds comments explaining that some lockless pagetable walks don't need
protection due to guest pgd not being a target of THP collapse/split, or
due to being called from Realmode + MSR
Applies the counting-based method for monitoring all book3s_hv related
functions that do lockless pagetable walks.
Adds comments explaining that some lockless pagetable walks don't need
protection due to guest pgd not being a target of THP collapse/split, or
due to being called from Realmode + MSR
Applies the counting-based method for monitoring lockless pgtable walks on
kvmppc_e500_shadow_map().
Fixes the place where local_irq_restore() is called: previously, if ptep
was NULL, local_irq_restore() would never be called.
Signed-off-by: Leonardo Bras
---
arch/powerpc/kvm/e500_mmu_host.c |
Applies the counting-based method for monitoring all hash-related functions
that do lockless pagetable walks.
hash_page_mm: Adds comment that explain that there is no need to
local_int_disable/save given that it is only called from DataAccess
interrupt, so interrupts are already disabled.
Signed-
Applies the counting-based method for monitoring lockless pgtable walks on
addr_to_pfn().
Signed-off-by: Leonardo Bras
---
arch/powerpc/kernel/mce_power.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_
Applies the counting-based method for monitoring lockless pgtable walks on
read_user_stack_slow.
Signed-off-by: Leonardo Bras
---
arch/powerpc/perf/callchain.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
in
As decribed, gup_pgd_range is a lockless pagetable walk. So, in order to
monitor against THP split/collapse with the couting method, it's necessary
to bound it with {start,end}_lockless_pgtbl_walk.
There are dummy functions, so it is not going to add any overhead on archs
that don't use this metho
There is a need to monitor lockless pagetable walks, in order to avoid
doing THP splitting/collapsing during them.
Some methods rely on local_irq_{save,restore}, but that can be slow on
cases with a lot of cpus are used for the process.
In order to speedup these cases, I propose a refcount-based
If a process (qemu) with a lot of CPUs (128) try to munmap() a large
chunk of memory (496GB) mapped with THP, it takes an average of 275
seconds, which can cause a lot of problems to the load (in qemu case,
the guest will lock for this time).
Trying to find the source of this bug, I found out most
It's necessary to monitor lockless pagetable walks, in order to avoid doing
THP splitting/collapsing during them.
Some methods rely on local_irq_{save,restore}, but that can be slow on
cases with a lot of cpus are used for the process.
In order to speedup some cases, I propose a refcount-based ap
On Fri, 2019-09-27 at 11:46 -0300, Leonardo Bras wrote:
> I am not sure if it would be ok to use irq_{save,restore} in real mode,
> I will do some more reading of the docs before addressing this.
It looks like it's unsafe to merge irq_{save,restore} in
{start,end}_lockless_pgtbl_walk(), due to a
ping?
On Wed, Aug 07, 2019 at 06:07:52PM +0300, Christoph Hellwig wrote:
> The powerpc version of dma-mapping.h only contains a version of
> get_arch_dma_ops that always return NULL. Replace it with the
> asm-generic version that does the same.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch
On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote:
> When hot-adding a device, the bridge may have windows not big enough (or
> fragmented too much) for newly requested BARs to fit in. And expanding
> these bridge windows may be impossible because blocked by "neighboring"
> BARs
On Fri, Aug 16, 2019 at 07:50:40PM +0300, Sergey Miroshnichenko wrote:
> The PCI_COMMAND_IO and PCI_COMMAND_MEMORY bits of the bridge must be
> updated not only when enabling the bridge for the first time, but also if a
> hotplugged device requests these types of resources.
Yeah, this assumption t
On Fri, Aug 16, 2019 at 07:50:39PM +0300, Sergey Miroshnichenko wrote:
> This is a yet another approach to fix an old [1-2] concurrency issue, when:
> - two or more devices are being hot-added into a bridge which was
>initially empty;
> - a bridge with two or more devices is being hot-added;
Thiago Jung Bauermann writes:
> Thiago Jung Bauermann writes:
>
>> The ultravisor will do an integrity check of the kernel image but we
>> relocated it so the check will fail. Restore the original image by
>> relocating it back to the kernel virtual base address.
>>
>> This works because durin
On 9/26/19 10:48 PM, Lijun Pan wrote:
> According to the PAPR, hcalls should not modify the Condition
> Register fields, hence save/restore the CR is not necessary.
Just curious: could you provide a more specific reference?
PC
On 9/9/19 2:59 AM, Alexey Kardashevskiy wrote:
On 06/09/2019 05:13, Shawn Anastasio wrote:
Move PCI device setup from pcibios_add_device() and pcibios_fixup_bus() to
pcibios_bus_add_device(). This ensures that platform-specific DMA and IOMMU
setup occurs after the device has been registered in
On Wed, Sep 25, 2019 at 03:34:47AM +, Leo Li wrote:
>
>
> > -Original Message-
> > From: Biwen Li
> > Sent: Tuesday, September 24, 2019 10:30 PM
> > To: Leo Li ; shawn...@kernel.org;
> > robh...@kernel.org; mark.rutl...@arm.com; Ran Wang
> >
> > Cc: linuxppc-dev@lists.ozlabs.org; lin
On Fri, Sep 27, 2019 at 09:04:02AM -0400, Dan Streetman wrote:
> The dummy vio_bus_device creates the /sys/devices/vio directory, which
> contains real vio devices under it; since it represents itself as having
> a bus = &vio_bus_type, its /sys/devices/vio/uevent does call the bus's
> .uevent funct
On Thu, Sep 26, 2019 at 10:41:18AM +0800, Biwen Li wrote:
> The 'fsl,ippdexpcr1-alt-addr' property is used to handle an errata A-008646
> on LS1021A
>
> Signed-off-by: Biwen Li
> ---
> Change in v4:
> - rename property name
> fsl,ippdexpcr-alt-addr -> fsl,ippdexpcr1-alt-addr
>
> Ch
On Tue, 24 Sep 2019 10:18:43 +0800, Xiaowei Bao wrote:
> Add compatible strings for ls1088a and ls2088a.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - No change.
> v3:
> - Use one valid combination of compatible strings.
> v4:
> - Add the comma between the two compatible.
>
> Documentation/
On 9/9/19 5:45 pm, Frederic Barrat wrote:
The PE for an opencapi device was set as part of a late PHB fixup
operation, when creating the PHB. To use the PCI hotplug framework,
this is not going to work, as the PHB stays the same, it's only the
devices underneath which are updated. For regular PCI
On 9/9/19 5:45 pm, Frederic Barrat wrote:
The driver only allows to disable a slot in the POPULATED
state. However, if an error occurs while enabling the slot, say
because the link couldn't be trained, then the POPULATED state may not
be reached, yet the power state of the slot is on. So allow to
John Hubbard writes:
> Hi Leonardo,
>
> Thanks for adding linux-mm to CC for this next round of reviews. For the
> benefit
> of any new reviewers, I'd like to add that there are some issues that were
> discovered
> while reviewing the v2 patchset, that are not (yet) addressed in this v3
> seri
Commit df44b479654f62b478c18ee4d8bc4e9f897a9844 ("kobject: return error code if
writing /sys/.../uevent fails") started returning failure when writing to
/sys/devices/vio/uevent.
This causes an early udevadm trigger to fail. On some installer versions of
Ubuntu, this will cause init to exit, thus
This patch updates the arch specific policies for PowernV systems
to add check against blacklisted hashes before doing the verification.
Signed-off-by: Nayna Jain
---
arch/powerpc/kernel/ima_arch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ima_ar
This patch deprecates the existing permit_directio flag, instead adds
it as possible value to appraise_flag parameter.
For eg.
appraise_flag=permit_directio
Signed-off-by: Nayna Jain
---
Documentation/ABI/testing/ima_policy | 4 ++--
security/integrity/ima/ima_policy.c | 2 ++
2 files changed,
Asymmetric private keys are used to sign multiple files. The kernel
currently support checking against the blacklisted keys. However, if the
public key is blacklisted, any file signed by the blacklisted key will
automatically fail signature verification. We might not want to blacklist
all the files
To add the support for checking against blacklist, it would be needed
to add an additional measurement record that identifies the record
as blacklisted.
This patch modifies the process_buffer_measurement() and makes it
non static to be used by blacklist functionality. It modifies the
function to h
This patch adds the measurement rules to the arch specific policies for the
systems with trusted boot.
Signed-off-by: Nayna Jain
---
arch/powerpc/kernel/ima_arch.c | 44 +++---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/ima_arch
PowerNV systems enables the IMA measurement rules only if the
trusted boot is enabled on the system.
This patch adds the function to detect if the system has trusted
boot enabled.
Signed-off-by: Nayna Jain
---
arch/powerpc/include/asm/secure_boot.h | 6 ++
arch/powerpc/kernel/secure_boot.c
PowerNV systems uses kernel based bootloader, thus its secure boot
implementation uses kernel IMA security subsystem to verify the kernel
before kexec. Since the verification policy might differ based on the
secure boot mode of the system, the policies are defined at runtime.
This patch implements
Secure boot on PowerNV defines different IMA policies based on the secure
boot state of the system.
This patch defines a function to detect the secure boot state of the
system.
The PPC_SECURE_BOOT config represents the base enablement of secureboot
on POWER.
Signed-off-by: Nayna Jain
---
arch/
PowerNV represents both the firmware and Host OS secureboot state of the
system via device tree. This patch adds the documentation to give
the definition of the nodes and the properties.
Signed-off-by: Nayna Jain
---
.../bindings/powerpc/ibm,secureboot.rst | 76
.../device
This patchset extends the previous version of the patchset[1] by adding
the support for checking against the binary blacklisted hashes.
IMA subsystem supports custom, built-in, arch-specific policies to define
the files to be measured and appraised. These policies are honored based
on the priority
Recent cleanup in the way EEH support is added to a device causes a
kernel oops when the cxl driver probes a device and creates virtual
devices discovered on the FPGA:
BUG: Kernel NULL pointer dereference at 0x00a0
Faulting instruction address: 0xc0048070
Oops: Kernel acces
On Tue, Aug 27, 2019 at 06:18:22PM +0300, Andy Shevchenko wrote:
> This simplifies and standardizes slot manipulation code
> by using for_each_set_bit() library function.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/pci/pcie/aer.c | 19 ---
> 1 file changed, 8 insertions(+)
Add a new attribute to both XIVE and XICS-on-XIVE KVM devices so that
userspace can tell how many interrupt servers it needs. If a VM needs
less than the current default of KVM_MAX_VCPUS (2048), we can allocate
less VPs in OPAL. Combined with a core stride (VSMT) that matches the
number of guest th
The XIVE VP is an internal structure which allow the XIVE interrupt
controller to maintain the interrupt context state of vCPUs non
dispatched on HW threads.
When a guest is started, the XIVE KVM device allocates a block of
XIVE VPs in OPAL, enough to accommodate the highest possible vCPU
id KVM_M
Reduce code duplication by consolidating the checking of vCPU ids and VP
ids to a common helper used by both legacy and native XIVE KVM devices.
And explain the magic with a comment.
Signed-off-by: Greg Kurz
---
arch/powerpc/kvm/book3s_xive.c| 42 ++---
arch
Print out the VP id of each connected vCPU, this allow to see:
- the VP block base in which OPAL encodes information that may be
useful when debugging
- the packed vCPU id which may differ from the raw vCPU id if the
latter is >= KVM_MAX_VCPUS (2048)
Signed-off-by: Greg Kurz
---
arch/powerpc
Connecting a vCPU to a XIVE KVM device means establishing a 1:1
association between a vCPU id and the offset (VP id) of a VP
structure within a fixed size block of VPs. We currently try to
enforce the 1:1 relationship by checking that a vCPU with the
same id isn't already connected. This is good bu
If we cannot allocate the XIVE VPs in OPAL, the creation of a XIVE or
XICS-on-XIVE device is aborted as expected, but we leave kvm->arch.xive
set forever since the release method isn't called in this case. Any
subsequent tentative to create a XIVE or XICS-on-XIVE for this VM will
thus always fail (
This brings some fixes and allows to start more VMs with an in-kernel
XIVE or XICS-on-XIVE device.
Changes since v1 (https://patchwork.ozlabs.org/cover/1166099/):
- drop a useless patch
- add a patch to show VP ids in debugfs
- update some changelogs
- fix buggy check in patch 5
- Cc: stable
--
On 25.09.19 09:37, David Hildenbrand wrote:
> On 10.09.19 18:39, David Hildenbrand wrote:
>> We can simply store the pages in a list (page->lru), no need for a
>> separate data structure (+ complicated handling). This is how most
>> other balloon drivers store allocated pages without additional tra
On Tue, Aug 27, 2019 at 06:18:22PM +0300, Andy Shevchenko wrote:
> This simplifies and standardizes slot manipulation code
> by using for_each_set_bit() library function.
>
> Signed-off-by: Andy Shevchenko
Applied both with Kuppuswamy's reviewed-by to pci/aer for v5.5,
thanks!
> ---
> drivers/
Comment below...
On Thu, 26 Sep 2019 at 12:18, Alastair D'Silva wrote:
>
> From: Alastair D'Silva
>
> When presented with large amounts of memory being hotplugged
> (in my test case, ~890GB), the call to flush_dcache_range takes
> a while (~50 seconds), triggering RCU stalls.
>
> This patch brea
50 matches
Mail list logo
