https://bugzilla.kernel.org/show_bug.cgi?id=203647
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |RESOLVED
On 18/05/19 7:55 PM, Claudio Carvalho wrote:
From: Ram Pai When the ultravisor firmware is
available, it takes control over the LDBAR register. In this case,
thread-imc updates and save/restore operations on the LDBAR register
are handled by ultravisor.
we should remove the core and thread
> diff --git a/arch/powerpc/include/asm/mem_encrypt.h
> b/arch/powerpc/include/asm/mem_encrypt.h
> new file mode 100644
> index ..45d5e4d0e6e0
> --- /dev/null
> +++ b/arch/powerpc/include/asm/mem_encrypt.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * SVM
On 20/05/19 2:35 PM, Anju T Sudhakar wrote:
Nest and core imc(In-memory Collection counters) assigns a particular
cpu as the designated target for counter data collection.
During system boot, the first online cpu in a chip gets assigned as
the designated cpu for that chip(for nest-imc) and the
On Tue, May 21, 2019 at 01:49:02AM -0300, Thiago Jung Bauermann wrote:
> From: Benjamin Herrenschmidt
>
> For secure VMs, the signing tool will create a ticket called the "ESM blob"
> for the Enter Secure Mode ultravisor call with the signatures of the kernel
> and initrd among other things.
>
From: Ryan Grimm
Enables running as a secure guest in platforms with an Ultravisor.
Signed-off-by: Ryan Grimm
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/configs/ppc64_defconfig | 1 +
arch/powerpc/configs/pseries_defconfig | 1 +
2 files changed, 2
On 20/05/19 2:27 PM, Anju T Sudhakar wrote:
Currently init_imc_pmu() can be failed either because
an IMC unit with invalid domain(i.e an IMC node not
supported by the kernel) is attempted a pmu-registration
or something went wrong while registering a valid IMC unit.
In both the cases kernel
Secure guest memory is inacessible to devices so regular DMA isn't
possible.
In that case set devices' dma_map_ops to NULL so that the generic
DMA code path will use SWIOTLB and DMA to bounce buffers.
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/platforms/pseries/iommu.c | 6 +-
1
Eric Biggers writes:
> From: Eric Biggers
>
> Convert the VMX implementations of AES-CBC, AES-CTR, and AES-XTS from
> the deprecated "blkcipher" API to the "skcipher" API.
>
> As part of this, I moved the skcipher_request for the fallback algorithm
> off the stack and into the request context of
From: Anshuman Khandual
Secure guests need to share the DTL buffers with the hypervisor. To that
end, use a kmem_cache constructor which converts the underlying buddy
allocated SLUB cache pages into shared memory.
Signed-off-by: Anshuman Khandual
Signed-off-by: Thiago Jung Bauermann
---
From: Anshuman Khandual
SWIOTLB checks range of incoming CPU addresses to be bounced and sees if
the device can access it through its DMA window without requiring bouncing.
In such cases it just chooses to skip bouncing. But for cases like secure
guests on powerpc platform all addresses need to
From: Sukadev Bhattiprolu
Normally, the HV emulates some instructions like MSGSNDP, MSGCLRP
from a KVM guest. To emulate the instructions, it must first read
the instruction from the guest's memory and decode its parameters.
However for a secure guest (aka SVM), the page containing the
From: Ryan Grimm
User space might want to know it's running in a secure VM. It can't do
a mfmsr because mfmsr is a privileged instruction.
The solution here is to create a cpu attribute:
/sys/devices/system/cpu/svm
which will read 0 or 1 based on the S bit of the guest's CPU 0.
From: Anshuman Khandual
LPPACA structures need to be shared with the host. Hence they need to be in
shared memory. Instead of allocating individual chunks of memory for a
given structure from memblock, a contiguous chunk of memory is allocated
and then converted into shared memory. Subsequent
Helps document what the hard-coded number means.
Also take the opportunity to fix an #endif comment.
Suggested-by: Alexey Kardashevskiy
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/kernel/paca.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git
This series enables Secure Virtual Machines (SVMs) on powerpc. SVMs use the
Protected Execution Facility (PEF) and request to be migrated to secure
memory during prom_init() so by default all of their memory is inaccessible
to the hypervisor. There is an Ultravisor call that the VM can use to
From: Ram Pai
These functions are used when the guest wants to grant the hypervisor
access to certain pages.
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/ultravisor-api.h | 2 ++
arch/powerpc/include/asm/ultravisor.h | 14 ++
2
From: Ram Pai
Make the Enter-Secure-Mode (ESM) ultravisor call to switch the VM to secure
mode. Add "svm=" command line option to turn off switching to secure mode.
Introduce CONFIG_PPC_SVM to control support for secure guests.
Signed-off-by: Ram Pai
[ Generate an RTAS os-term hcall when the
From: Benjamin Herrenschmidt
For secure VMs, the signing tool will create a ticket called the "ESM blob"
for the Enter Secure Mode ultravisor call with the signatures of the kernel
and initrd among other things.
This adds support to the wrapper script for adding that blob via the "-e"
option to
Introduce CONFIG_PPC_SVM to control support for secure guests and include
Ultravisor-related helpers when it is selected
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/ultravisor.h | 2 +-
arch/powerpc/kernel/Makefile | 4 +++-
On Wed, 2019-05-15 at 06:20 +, Christophe Leroy wrote:
Confirming this works on hash and radix book3s64.
> +
> + // only operate on VM areas for now
> + area = find_vm_area((void *)addr);
> + if (!area || end > (unsigned long)area->addr + area->size ||
> + !(area->flags &
Eric Biggers writes:
> From: Eric Biggers
>
> Remove the boilerplate license text and replace it with the equivalent
> SPDX license identifier.
>
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/vmx/aes.c | 14 +-
> drivers/crypto/vmx/aes_cbc.c | 14 +-
>
On Mon, May 20, 2019 at 11:47:39AM -0300, Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
Thanks, didn't notice that.
>
On Mon, May 20, 2019 at 04:10:46PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible
From: Eric Biggers
On PowerPC with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, there is sometimes
a crash in generate_random_aead_testvec(). The problem is that the
generated test vectors use data lengths of up to about 2 * PAGE_SIZE,
which is 128 KiB on PowerPC; however, the data length fields in the
From: Eric Biggers
Convert the VMX implementations of AES-CBC, AES-CTR, and AES-XTS from
the deprecated "blkcipher" API to the "skcipher" API.
As part of this, I moved the skcipher_request for the fallback algorithm
off the stack and into the request context of the parent algorithm.
I tested
From: Eric Biggers
Remove the boilerplate license text and replace it with the equivalent
SPDX license identifier.
Signed-off-by: Eric Biggers
---
drivers/crypto/vmx/aes.c | 14 +-
drivers/crypto/vmx/aes_cbc.c | 14 +-
drivers/crypto/vmx/aes_ctr.c | 14
On Mon, May 20, 2019 at 11:59:05AM +1000, Daniel Axtens wrote:
> Daniel Axtens writes:
>
> > The kernel self-tests picked up an issue with CTR mode:
> > alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test
> > vector 3, cfg="uneven misaligned splits, may sleep"
> >
> > Test
On 05/20, Christoph Hellwig wrote:
>
> No one is using this header anymore.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Arnd Bergmann
> ---
> MAINTAINERS| 1 -
> arch/mips/include/asm/ptrace.h | 5 ---
> include/asm-generic/ptrace.h | 74
On 05/20, Christoph Hellwig wrote:
>
> Doing the indirection through macros for the regs accessors just
> makes them harder to read, so implement the helpers directly.
Acked-by: Oleg Nesterov
This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
process that is created via traditional fork()/clone() calls that is only
referenced by a PID:
int pidfd = pidfd_open(1234, 0);
ret =
This adds testing for the new pidfd_open() syscalls. Specifically, we test:
- that no invalid flags can be passed to pidfd_open()
- that no invalid pid can be passed to pidfd_open()
- that a pidfd can be retrieved with pidfd_open()
- that the retrieved pidfd references the correct pid
On Mon, May 20, 2019 at 04:19:34PM +1000, Alexey Kardashevskiy wrote:
> On 04/05/2019 06:16, Daniel Jordan wrote:
> > locked_vm accounting is done roughly the same way in five places, so
> > unify them in a helper. Standardize the debug prints, which vary
> > slightly.
>
> And I rather liked
On Tue, May 21, 2019 at 12:55:49AM +1000, Nicholas Piggin wrote:
> Bharata B Rao's on May 21, 2019 12:29 am:
> > On Mon, May 20, 2019 at 01:50:35PM +0530, Bharata B Rao wrote:
> >> On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
> >> > Bharata B Rao's on May 20, 2019 3:56 pm:
> >>
On 5/20/19 8:25 PM, Nicholas Piggin wrote:
Bharata B Rao's on May 21, 2019 12:29 am:
On Mon, May 20, 2019 at 01:50:35PM +0530, Bharata B Rao wrote:
On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
Bharata B Rao's on May 20, 2019 3:56 pm:
On Mon, May 20, 2019 at 02:48:35PM
Tyrel Datwyler writes:
> On 05/16/2019 12:17 PM, Nathan Lynch wrote:
>> Tyrel Datwyler writes:
>>> The current dlpar_cpu_readd() takes in a cpu_id and uses that to look up
>>> the cpus device_node so that we can get at the ibm,my-drc-index
>>> property. The only user of cpu readd is an OF
On Mon, May 20, 2019 at 4:48 PM Christian Brauner wrote:
>
> On Mon, May 20, 2019 at 04:37:03PM +0200, Arnd Bergmann wrote:
> > On Mon, May 20, 2019 at 3:46 PM Christian Brauner
> > wrote:
> > >
> > > In line with Arnd's recent changes to consolidate syscall numbers across
> > > architectures,
Bharata B Rao's on May 21, 2019 12:29 am:
> On Mon, May 20, 2019 at 01:50:35PM +0530, Bharata B Rao wrote:
>> On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
>> > Bharata B Rao's on May 20, 2019 3:56 pm:
>> > > On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
>> >
On Mon, 20 May 2019 20:12:48 +0530
"Naveen N. Rao" wrote:
> Thanks, that definitely helps make things clearer. A very small nit from
> your first patch -- it would be good to also convert the calls to
> ftrace_check_record() to use 'true' or 'false' for the 'update' field.
Heh, I was so
On Mon, May 20, 2019 at 04:37:03PM +0200, Arnd Bergmann wrote:
> On Mon, May 20, 2019 at 3:46 PM Christian Brauner
> wrote:
> >
> > In line with Arnd's recent changes to consolidate syscall numbers across
> > architectures, I have added the pidfd_open() syscall to all architectures
> > at the
Mostly due to x86 and acpi conversion, several documentation
links are still pointing to the old file. Fix them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/acpi/dsd/leds.txt | 2 +-
Documentation/admin-guide/kernel-parameters.rst | 6 +++---
Hi Steven,
Steven Rostedt wrote:
On Mon, 20 May 2019 09:13:20 -0400
Steven Rostedt wrote:
> I haven't yet tested this patch on x86, but this looked wrong so sending
> this as a RFC.
This code has been through a bit of updates, and I need to go through
and clean it up. I'll have to take
On Mon, May 20, 2019 at 3:46 PM Christian Brauner wrote:
>
> In line with Arnd's recent changes to consolidate syscall numbers across
> architectures, I have added the pidfd_open() syscall to all architectures
> at the same time.
Thanks! I've checked that the ones you have added are all
done
On Mon, May 20, 2019 at 01:50:35PM +0530, Bharata B Rao wrote:
> On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
> > Bharata B Rao's on May 20, 2019 3:56 pm:
> > > On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
> > >> >> > git bisect points to
> > >> >> >
> > >>
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or
On Mon, May 20, 2019 at 3:46 PM Christian Brauner wrote:
> This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
> process that is created via traditional fork()/clone() calls that is only
>
First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the three config options in an choice, make people can only choose one of
the three at a time.
The default IOMMU dma modes on each ARCHs have no
v6 --> v7:
1. Fix some text editing errors
v5 --> v6:
1. give up adding boot option iommu.dma_mode
v4 --> v5:
As Hanjun and Thomas Gleixner's suggestion:
1. Keep the old ARCH specific boot options no change.
2. Keep build option CONFIG_IOMMU_DEFAULT_PASSTHROUGH no change.
v4:
As Robin Murphy's
This adds testing for the new pidfd_open() syscalls. Specifically, we test:
- that no invalid flags can be passed to pidfd_open()
- that no invalid pid can be passed to pidfd_open()
- that a pidfd can be retrieved with pidfd_open()
- that the retrieved pidfd references the correct pid
This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
process that is created via traditional fork()/clone() calls that is only
referenced by a PID:
int pidfd = pidfd_open(1234, 0);
ret =
On Mon, 20 May 2019 09:13:20 -0400
Steven Rostedt wrote:
> > I haven't yet tested this patch on x86, but this looked wrong so sending
> > this as a RFC.
>
> This code has been through a bit of updates, and I need to go through
> and clean it up. I'll have to take a look and convert "int" to
On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
> I rephrased it in terms of address translation. What do you think of
> this version? The flag name is slightly different too:
>
>
> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same
> meaning as
On Sat, 18 May 2019 00:32:46 +0530
"Naveen N. Rao" wrote:
> In commit a0572f687fb3c ("ftrace: Allow ftrace_replace_code() to be
> schedulable), the generic ftrace_replace_code() function was modified to
> accept a flags argument in place of a single 'enable' flag. However, the
> x86 version of
On Fri, Apr 26, 2019 at 08:56:43PM -0300, Thiago Jung Bauermann wrote:
>
> Michael S. Tsirkin writes:
>
> > On Wed, Apr 24, 2019 at 10:01:56PM -0300, Thiago Jung Bauermann wrote:
> >>
> >> Michael S. Tsirkin writes:
> >>
> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann
On Sat, 18 May 2019 00:32:45 +0530
"Naveen N. Rao" wrote:
> Since ftrace_replace_code() is a __weak function and can be overridden,
> we need to expose the flags that can be set. So, move the flags enum to
> the header file.
>
> Signed-off-by: Naveen N. Rao
Reviewed-by: Steven Rostedt
On Thu, May 02, 2019 at 05:10:55PM +0200, Martin Schwidefsky wrote:
> On Thu, 2 May 2019 16:31:10 +0200
> Greg KH wrote:
>
> > On Thu, May 02, 2019 at 04:17:58PM +0200, Martin Schwidefsky wrote:
> > > On Thu, 2 May 2019 14:21:28 +0200
> > > Greg KH wrote:
> > >
> > > > On Mon, Apr 15, 2019
This test uses the PMU to count branch prediction hits/misses for a
known loop, and compare the result to the reported spectre v2
mitigation.
This gives us a way of sanity checking that the reported mitigation is
actually in effect.
Sample output for some cases, eg:
Power9:
sysfs reports:
Userspace isn't allowed to access certain address ranges, make sure we
actually test that to at least some degree.
This would have caught the recent bug where the SLB fault handler was
incorrectly called on an out-of-range access when using the Radix MMU.
It also would have caught the bug we had
Userspace isn't allowed to access certain address ranges, make sure we
actually test that to at least some degree.
This would have caught the recent bug where the SLB fault handler was
incorrectly called on an out-of-range access when using the Radix MMU.
It also would have caught the bug we had
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. And is user's responsibility to identify if this
wakeup source he is
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.
This driver depends on PM wakeup source framework which help to
collect wake information.
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are Little
Endian. So add this optional property to help identify them.
Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc
On Mon, May 20, 2019 at 11:54:37AM +0900, Masahiro Yamada wrote:
> I just thought it was a good idea to scan builtin.modules in the name
> uniqueness checking, but Stephen reported a false positive.
>
> ppc64_defconfig produces:
>
> warning: same basename if the following are built as modules:
On Mon, May 20, 2019 at 4:57 AM Masahiro Yamada
wrote:
>
> I just thought it was a good idea to scan builtin.modules in the name
> uniqueness checking, but Stephen reported a false positive.
>
> ppc64_defconfig produces:
>
> warning: same basename if the following are built as modules:
>
Hi!
> > > > You are right, but the current code is "interesting". What about
> > > >
> > > > ws = NULL;
> > > > while (ws = wakeup_source_get_next(NULL)) ...
> > > >
> > > > then?
> > >
> > > Did you mean:
> > > ws = NULL;
> > > while (ws = wakeup_source_get_next(ws)) ...
> > >
Hi,
Somehow the subject of this patch didn't appear completely here.
The Subject of this patch is as follows,
`Subject [PATCH] powerpc/perf: Use cpumask_last() to determine the
designated cpu for nest/core units.`
Thanks,
Anju
On 5/20/19 2:35 PM, Anju T Sudhakar wrote:
Nest and core
Hi Pavel,
On Monday, May 20, 2019 17:08 Pavel Machek wrote:
> > > Hi!
> > >
> > > > > > +static int rcpm_pm_prepare(struct device *dev) {
> > > > > > + struct device_node *np = dev->of_node;
> > > > > > + struct wakeup_source *ws;
> > > > > > + struct rcpm *rcpm;
> > > > > > + u32
On Mon, 20 May 2019 09:16:18 +0200
Frederic Barrat wrote:
> If we couldn't fully init a context, we were leaking memory.
>
> Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts")
Oops... missed that during review :-\
> Signed-off-by: Frederic Barrat
> ---
>
>
On Mon 2019-05-20 09:03:50, Ran Wang wrote:
> Hi Pavel,
>
> On Monday, May 20, 2019 16:57, Pavel Machek wrote:
> >
> > Hi!
> >
> > > > > +static int rcpm_pm_prepare(struct device *dev) {
> > > > > + struct device_node *np = dev->of_node;
> > > > > + struct wakeup_source *ws;
> > > > > +
Nest and core imc(In-memory Collection counters) assigns a particular
cpu as the designated target for counter data collection.
During system boot, the first online cpu in a chip gets assigned as
the designated cpu for that chip(for nest-imc) and the first online cpu
in a core gets assigned as the
Hi Pavel,
On Monday, May 20, 2019 16:57, Pavel Machek wrote:
>
> Hi!
>
> > > > +static int rcpm_pm_prepare(struct device *dev) {
> > > > + struct device_node *np = dev->of_node;
> > > > + struct wakeup_source *ws;
> > > > + struct rcpm *rcpm;
> > > > + u32
Currently init_imc_pmu() can be failed either because
an IMC unit with invalid domain(i.e an IMC node not
supported by the kernel) is attempted a pmu-registration
or something went wrong while registering a valid IMC unit.
In both the cases kernel provides a 'Registration failed'
error message.
Nicholas Piggin wrote:
Naveen N. Rao's on May 18, 2019 5:02 am:
With -mprofile-kernel, gcc emits 'mflr r0', followed by 'bl _mcount' to
enable function tracing and profiling. So far, with dynamic ftrace, we
used to only patch out the branch to _mcount(). However, Nick Piggin
points out that
Hi!
> > > +static int rcpm_pm_prepare(struct device *dev) {
> > > + struct device_node *np = dev->of_node;
> > > + struct wakeup_source *ws;
> > > + struct rcpm *rcpm;
> > > + u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
> > > + int i, ret;
> > > +
> > > + rcpm = dev_get_drvdata(dev);
> > > +
On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
> Bharata B Rao's on May 20, 2019 3:56 pm:
> > On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
> >> >> > git bisect points to
> >> >> >
> >> >> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
> >> >> > Author:
Allow arch to provide the supported alignments and use hugepage alignment only
if we support hugepage. Right now we depend on compile time configs whereas this
patch switch this to runtime discovery.
Architectures like ppc64 can have THP enabled in code, but then can have
hugepage size disabled
Hi Arndt,
-Original Message-
From: Arnd Bergmann
Sent: 2019年5月17日 16:59
To: Xiaowei Bao
Cc: Bjorn Helgaas ; Rob Herring ; Mark
Rutland ; Shawn Guo ; Leo Li
; Kishon ; Lorenzo Pieralisi
; gregkh ; M.h. Lian
; Mingkai Hu ; Roy Zang
; Kate Stewart ; Philippe
Ombredanne ; Shawn Lin ;
Hi Pavel,
On Monday, May 20, 2019 15:27: Pavel Machek wrote:
>
> Hi!
>
> > The NXP's QorIQ Processors based on ARM Core have RCPM module (Run
> > Control and Power Management), which performs all device-level tasks
> > associated with power management such as wakeup source control.
> >
> > This
Hi!
> The NXP's QorIQ Processors based on ARM Core have RCPM module
> (Run Control and Power Management), which performs all device-level
> tasks associated with power management such as wakeup source control.
>
> This driver depends on PM wakeup source framework which help to
> collect wake
Acked-by: Andrew Donnellan
On 20/5/19 5:16 pm, Frederic Barrat wrote:
If we couldn't fully init a context, we were leaking memory.
Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts")
Signed-off-by: Frederic Barrat
---
Changelog:
v2: reset context pointer in case of
If we couldn't fully init a context, we were leaking memory.
Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts")
Signed-off-by: Frederic Barrat
---
Changelog:
v2: reset context pointer in case of allocation failure (Andrew)
drivers/misc/ocxl/context.c | 2 ++
1 file
Bharata B Rao's on May 20, 2019 3:56 pm:
> On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
>> >> > git bisect points to
>> >> >
>> >> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
>> >> > Author: Nicholas Piggin
>> >> > Date: Fri Jul 27 21:48:17 2018 +1000
>> >> >
>> >> >
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.
This driver depends on PM wakeup source framework which help to
collect wake information.
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. And is user's responsibility to identify if this
wakeup source he is
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are Little
Endian. So add this optional property to help identify them.
Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc
Le 20/05/2019 à 03:45, Andrew Donnellan a écrit :
On 18/5/19 12:20 am, Frederic Barrat wrote:
If we couldn't fully init a context, we were leaking memory.
Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI
contexts")
Signed-off-by: Frederic Barrat
Acked-by: Andrew
Hi Pavel,
On Monday, May 20, 2019 05:39, Pavel Machek wrote:
>
> Hi!
>
>
> > +
> > +struct rcpm {
> > + unsigned int wakeup_cells;
> > + void __iomem *ippdexpcr_base;
> > + boollittle_endian;
> > +};
>
> Inconsistent whitespace
OK, will make them aligned.
>
> > +static int
On Sat, May 18, 2019 at 11:25:23AM -0300, Claudio Carvalho wrote:
> From: Paul Mackerras
>
> - Pass SRR1 in r11 for UV_RETURN because SRR0 and SRR1 get set by
> the sc 2 instruction. (Note r3 - r10 potentially have hcall return
> values in them.)
>
> - Fix kvmppc_msr_interrupt to preserve
On Sat, May 18, 2019 at 11:25:22AM -0300, Claudio Carvalho wrote:
> From: Sukadev Bhattiprolu
>
> All hcalls from a secure VM go to the ultravisor from where they are
> reflected into the HV. When we (HV) complete processing such hcalls,
> we should return to the UV rather than to the guest
On Sat, May 18, 2019 at 11:25:21AM -0300, Claudio Carvalho wrote:
> From: Ram Pai
>
> When the ultravisor firmware is available, it takes control over the
> LDBAR register. In this case, thread-imc updates and save/restore
> operations on the LDBAR register are handled by ultravisor.
>
>
COMPILE TESTED ONLY.
mount -t fwvarfs opal_secvar /fw
Signed-off-by: Daniel Axtens
---
Documentation/filesystems/fwvarfs.txt | 3 +
fs/fwvarfs/Kconfig| 11 ++
fs/fwvarfs/Makefile | 1 +
fs/fwvarfs/fwvarfs.c | 3 +
Replace it with a generic API.
Compile tested only.
Signed-off-by: Daniel Axtens
---
arch/powerpc/include/asm/opal-secvar.h | 58 +++
arch/powerpc/platforms/Kconfig | 3 -
arch/powerpc/platforms/powernv/Kconfig | 5 +-
From: Claudio Carvalho
[dja: this is a WIP version - a new version is coming that changes
the interface. I also had to renumber the opal calls to get this
to apply. Basically, this is an illustration of the concept: more
work would be required to get this to actually function.]
The X.509
Add a read-only EFI backend. This does not rely on efivarfs at all
(although it does borrow heavily from the code).
It only supports reading the variables, but it supports the same
format as efivarfs so tools like efivar continue to work if you
mount this filesystem in the same place.
Two small
Sometimes it is helpful to be able to access firmware variables as
file, like efivarfs, but not all firmware is EFI. Create a framework
that allows generic access to firmware variables exposed by a
implementations of a simple backend API.
Add a demonstration memory-based backend.
Signed-off-by:
I'm building a generic firmware variable filesystem on top of kernfs
and I'd like to be able to create and unlink files.
The hooks are fairly straightforward. create() returns a kernfs_node*,
which is safe with regards to cleanup on error paths, because there
is no way that things can fail after
Hi all,
As PowerNV moves towards secure boot, we need a place to put secure
variables. One option that has been canvassed is to make our secure
variables look like EFI variables. This is an early sketch of another
approach where we create a generic firmware variable file system,
fwvarfs, and an
On 04/05/2019 06:16, Daniel Jordan wrote:
> locked_vm accounting is done roughly the same way in five places, so
> unify them in a helper. Standardize the debug prints, which vary
> slightly.
And I rather liked that prints were different and tell precisely which
one of three each printk is.
No one is using this header anymore.
Signed-off-by: Christoph Hellwig
Acked-by: Arnd Bergmann
---
MAINTAINERS| 1 -
arch/mips/include/asm/ptrace.h | 5 ---
include/asm-generic/ptrace.h | 74 --
3 files changed, 80 deletions(-)
delete
Doing the indirection through macros for the regs accessors just
makes them harder to read, so implement the helpers directly.
Note that only the helpers actually used are implemented now.
Signed-off-by: Christoph Hellwig
Acked-by: Ingo Molnar
---
arch/x86/include/asm/ptrace.h | 30
1 - 100 of 105 matches
Mail list logo