On Tue, Jun 2, 2020 at 3:55 PM Alistair Popple wrote:
>
> Adds support for emulating ISAv3.1 guests by adding the appropriate PCR
> and FSCR bits.
>
> Signed-off-by: Alistair Popple
> ---
> arch/powerpc/include/asm/reg.h | 1 +
> arch/powerpc/kvm/book3s_hv.c | 11 ---
> 2 files change
Adds support for emulating ISAv3.1 guests by adding the appropriate PCR
and FSCR bits.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/reg.h | 1 +
arch/powerpc/kvm/book3s_hv.c | 11 ---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/as
Currently show_instructions() treats prefixed instructions as two
separate word instructions. '<' and '>' are placed around the
instruction at the NIP, but as a result they only wrap around the
prefix. Make '<' and '>' straddle the whole prefixed instruction.
Currently showing a prefixed instructi
Currently prefixed instructions are treated as two word instructions by
show_user_instructions(), treat them as a single instruction. '<' and
'>' are placed around the instruction at the NIP, and for prefixed
instructions this is placed around the prefix only. Make the '<' and '>'
wrap the prefix a
Currently prefixed instructions are dumped as two separate word
instructions. Use mread_instr() so that prefixed instructions are read
as such and update the incrementor in the loop to take this into
account.
'dump_func' is print_insn_powerpc() which comes from ppc-dis.c which is
taken from binuti
There are quite a few places where instructions are printed, this is
done using a '%x' format specifier. With the introduction of prefixed
instructions, this does not work well. Currently in these places,
ppc_inst_val() is used for the value for %x so only the first word of
prefixed instructions ar
On Fri, 2020-05-29 at 06:14:46 UTC, Daniel Axtens wrote:
> syzkaller is picking up a bunch of crashes that look like this:
>
> Unrecoverable exception 380 at c037ed60 (msr=80001031)
> Oops: Unrecoverable exception, sig: 6 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeri
On Tue, 2020-05-26 at 06:18:08 UTC, Michael Ellerman wrote:
> Commit 702f09805222 ("powerpc/64s/exception: Remove lite interrupt
> return") changed the interrupt return path to not restore non-volatile
> registers by default, and explicitly restore them in paths where it is
> required.
>
> But it
Hello,
On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote:
>
> Apologies for the delayed update. Its been quite some time since I
> posted the last version (v5), but I have been really caught up in some
> other critical issues.
>
> Changes since v5:
>
> - v5 can be viewed here
Le 02/06/2020 à 06:12, Ravi Bangoria a écrit :
kbuild test robot reported few build warnings with hw_breakpoint code
when compiled with clang[1]. Fix those.
[1]: https://lore.kernel.org/linuxppc-dev/202005192233.oi9cjrta%25...@intel.com/
Reported-by: kbuild test robot
Signed-off-by: Ravi Ba
>>> Please just remove the message instead, it's a tiny allocation that's
>>> unlikely to ever fail, and the caller will print an error anyway.
>>
>> How do you think about to take another look at a previous update suggestion
>> like the following?
>>
>> powerpc/nvram: Delete three error messages f
I propose removing the "extended cede" offline mode for CPUs as well
as the partition suspend code which accommodates it by temporarily
onlining all CPUs prior to suspending the LPAR.
Detailed justifications are within the individual commit messages.
I'm hoping to move the pseries partition suspe
Partition suspension, used for hibernation and migration, requires
that the OS place all but one of the LPAR's processor threads into one
of two states prior to calling the ibm,suspend-me RTAS function:
* the architected offline state (via RTAS stop-self); or
* the H_JOIN hcall, which does not
This effectively reverts commit 3aa565f53c39 ("powerpc/pseries: Add
hooks to put the CPU into an appropriate offline state"), which added
an offline mode for CPUs which uses the H_CEDE hcall instead of the
architected stop-self RTAS function in order to facilitate "folding"
of dedicated mode proces
Power10 has removed 512 bytes boundary from match criteria. i.e. The match
range can be 512 bytes unaligned as well.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/hw_breakpoint.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
kbuild test robot reported few build warnings with hw_breakpoint code
when compiled with clang[1]. Fix those.
[1]: https://lore.kernel.org/linuxppc-dev/202005192233.oi9cjrta%25...@intel.com/
Reported-by: kbuild test robot
Signed-off-by: Ravi Bangoria
---
Note: Prepared on top of powerpc/next.
The CXL_AFU_DRIVER_OPS and CXL_LIB Kconfig options were added to coordinate
merging of new features. They no longer serve any purpose, so remove them.
Signed-off-by: Andrew Donnellan
---
drivers/misc/cxl/Kconfig | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/misc/cxl/Kconfig
So far Book3S Powerpc supported only one watchpoint. But Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10. Availability
of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_br
2nd DAWR can be set/unset using H_SET_MODE hcall with resource value 5.
Enable powervm guest support with that. This has no effect on kvm guest
because kvm will return error if guest does hcall with resource value 5.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hvcall.h | 1
Current H_SET_MODE hcall macro name for setting/resetting DAWR0 is
H_SET_MODE_RESOURCE_SET_DAWR. Add suffix 0 to macro name as well.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hvcall.h | 2 +-
arch/powerpc/include/asm/plpar_wrappers.h | 2 +-
arch/powerpc/kvm/book3s_hv.c
bit 0 of byte 64 in pa-features property indicates availability of 2nd
DAWR registers. i.e. If this bit is set, 2nd DAWR is present, otherwise
not. Host generally uses "cpu-features", which masks "pa-features". But
"cpu-features" are still not used for guests and thus this change is
mostly applicab
CPU_FTR_DAWR is by default enabled for host via CPU_FTRS_DT_CPU_BASE
(controlled by CONFIG_PPC_DT_CPU_FTRS). But cpu-features device-tree
node is not PAPR compatible and thus not yet used by kvm or pHyp
guests. Enable watchpoint functionality on power10 guest (both kvm
and powervm) by adding CPU_FT
Add new device-tree feature for 2nd DAWR. If this feature is present,
2nd DAWR is supported, otherwise not.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/cputable.h | 7 +--
arch/powerpc/kernel/dt_cpu_ftrs.c | 7 +++
2 files changed, 12 insertions(+), 2 deletions(-)
diff -
Last series[1] was to add basic infrastructure support for more than
one watchpoint on Book3S powerpc. This series actually enables the 2nd
DAWR for baremetal and powervm. Kvm guest is still not supported. This
series depends on Alistair's "Base support for POWER10"[2] series.
[1]:
https://lore.k
Markus Elfring writes:
>> Please just remove the message instead, it's a tiny allocation that's
>> unlikely to ever fail, and the caller will print an error anyway.
>
> How do you think about to take another look at a previous update suggestion
> like the following?
>
> powerpc/nvram: Delete three
The bhrb_filter_map ("The Branch History Rolling Buffer") callback is
only defined in raw CPUs' power_pmu structs. The "architected" CPUs use
generic_compat_pmu which does not have this callback and crashed occur.
This add a NULL pointer check for bhrb_filter_map() which behaves as if
the call
On Tue, Jun 2, 2020, at 04:36, Segher Boessenkool wrote:
> On Tue, Jun 02, 2020 at 04:12:26AM +0200, Daniel Kolesa wrote:
> > On Tue, Jun 2, 2020, at 03:58, Segher Boessenkool wrote:
> > > I recommend new ports that cannot jump to IEEE QP float directly to use
> > > long double == double for the ti
On Fri, 2020-05-29 at 11:24 +1000, Alistair Popple wrote:
> For what it's worth I tested this series on Mambo PowerNV and it seems to
> correctly enable/disable the prefix FSCR bit based on the cpu feature so feel
> free to add:
>
> Tested-by: Alistair Popple
>
> Mikey is going to test out pse
On Tue, Jun 02, 2020 at 04:12:26AM +0200, Daniel Kolesa wrote:
> On Tue, Jun 2, 2020, at 03:58, Segher Boessenkool wrote:
> > I recommend new ports that cannot jump to IEEE QP float directly to use
> > long double == double for the time being, avoiding the extra
> > complications that IBM double do
On Tue, Jun 2, 2020, at 04:12, Segher Boessenkool wrote:
> On Mon, Jun 01, 2020 at 11:45:51PM +, Joseph Myers wrote:
> > On Tue, 2 Jun 2020, Daniel Kolesa wrote:
> > > Are you sure this would be a new port? Glibc already works in this
> > > combination, as it seems to me it'd be best if it
On Mon, Jun 01, 2020 at 11:45:51PM +, Joseph Myers wrote:
> On Tue, 2 Jun 2020, Daniel Kolesa wrote:
> > Are you sure this would be a new port? Glibc already works in this
> > combination, as it seems to me it'd be best if it was just a variant of
> > the existing 32-bit PowerPC port, sharing
On Tue, Jun 2, 2020, at 03:58, Segher Boessenkool wrote:
> On Tue, Jun 02, 2020 at 01:26:37AM +0200, Daniel Kolesa wrote:
> > On Mon, Jun 1, 2020, at 23:28, Joseph Myers wrote:
> > Are you sure this would be a new port? Glibc already works in this
> > combination, as it seems to me it'd be best if
On Mon, Jun 1, 2020 at 9:58 PM Segher Boessenkool
wrote:
>
> On Tue, Jun 02, 2020 at 01:26:37AM +0200, Daniel Kolesa wrote:
> > On Mon, Jun 1, 2020, at 23:28, Joseph Myers wrote:
> > Are you sure this would be a new port? Glibc already works in this
> > combination, as it seems to me it'd be best
On Tue, Jun 2, 2020, at 03:42, Segher Boessenkool wrote:
> Hi Joseph,
>
> On Mon, Jun 01, 2020 at 09:28:25PM +, Joseph Myers wrote:
> > On Fri, 29 May 2020, Will Springer via Binutils wrote:
> >
> > > Hey all, a couple of us over in #talos-workstation on freenode have been
> > > working on an
On Tue, Jun 02, 2020 at 01:26:37AM +0200, Daniel Kolesa wrote:
> On Mon, Jun 1, 2020, at 23:28, Joseph Myers wrote:
> Are you sure this would be a new port? Glibc already works in this
> combination, as it seems to me it'd be best if it was just a variant of the
> existing 32-bit PowerPC port, sh
Hi Joseph,
On Mon, Jun 01, 2020 at 09:28:25PM +, Joseph Myers wrote:
> On Fri, 29 May 2020, Will Springer via Binutils wrote:
>
> > Hey all, a couple of us over in #talos-workstation on freenode have been
> > working on an effort to bring up a Linux PowerPC userland that runs in
> > 32-bit
>
On Mon, Jun 01, 2020 at 12:29:56AM +0200, Daniel Kolesa wrote:
> On Sun, May 31, 2020, at 22:42, Segher Boessenkool wrote:
> > > There was just an assumption that LE == powerpc64le in libgo, spotted by
> > > q66 (daniel@ on the CC). I just pushed the patch to [1].
> >
> > Please send GCC patches
On Tue, Jun 2, 2020, at 01:55, Joseph Myers wrote:
> On Mon, 1 Jun 2020, Joseph Myers wrote:
>
> > The minimum supported architecture for powerpc64le (POWER8) has VSX. My
> > understanding was that the suggestion was for 32-bit userspace to run
> > under powerpc64le kernels running on POWER8 or
On Tue, Jun 2, 2020, at 01:45, Joseph Myers wrote:
> On Tue, 2 Jun 2020, Daniel Kolesa wrote:
>
> > Are you sure this would be a new port? Glibc already works in this
> > combination, as it seems to me it'd be best if it was just a variant of
> > the existing 32-bit PowerPC port, sharing most co
On Mon, 1 Jun 2020, Joseph Myers wrote:
> The minimum supported architecture for powerpc64le (POWER8) has VSX. My
> understanding was that the suggestion was for 32-bit userspace to run
> under powerpc64le kernels running on POWER8 or later, meaning that such a
> 32-bit LE port, and any ABI de
On Mon, 1 Jun 2020, Geert Uytterhoeven wrote:
> >
> > Sure, it could be absorbed by both asm/mac_iop.h and
> > drivers/macintosh/adb-iop.c [...]
>
> asm/mac_iop.h doesn't include asm/adb_iop.h (at least not in my tree,
> but perhaps you have plans to change that?), so there's only a single
> u
On Tue, 2 Jun 2020, Daniel Kolesa wrote:
> Are you sure this would be a new port? Glibc already works in this
> combination, as it seems to me it'd be best if it was just a variant of
> the existing 32-bit PowerPC port, sharing most conventions besides
> endianness with the BE port.
The suppor
On Mon, Jun 1, 2020, at 23:28, Joseph Myers wrote:
> On Fri, 29 May 2020, Will Springer via Binutils wrote:
>
> > Hey all, a couple of us over in #talos-workstation on freenode have been
> > working on an effort to bring up a Linux PowerPC userland that runs in
> > 32-bit
> > little-endian mode,
On Mon, Jun 01, 2020 at 09:28:25PM +, Joseph Myers wrote:
> On Fri, 29 May 2020, Will Springer via Binutils wrote:
>
> > Hey all, a couple of us over in #talos-workstation on freenode have been
> > working on an effort to bring up a Linux PowerPC userland that runs in
> > 32-bit
> > little-en
On Fri, 29 May 2020, Will Springer via Binutils wrote:
> Hey all, a couple of us over in #talos-workstation on freenode have been
> working on an effort to bring up a Linux PowerPC userland that runs in 32-bit
> little-endian mode, aka ppcle. As far as we can tell, no ABI has ever been
> designate
On Mon, Jun 01, 2020 at 05:25:18PM +0530, Bharata B Rao wrote:
> On Sat, May 30, 2020 at 07:27:50PM -0700, Ram Pai wrote:
> > H_SVM_INIT_DONE incorrectly assumes that the Ultravisor has explicitly
> > called H_SVM_PAGE_IN for all secure pages.
>
> I don't think that is quite true. HV doesn't assum
On Mon 01-06-20 17:31:50, Aneesh Kumar K.V wrote:
> On 6/1/20 3:39 PM, Jan Kara wrote:
> > On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
> > > On 5/29/20 3:22 PM, Jan Kara wrote:
> > > > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> > > > > Thanks Michal. I also missed Jeff in this email
Steven Rostedt writes:
> On Mon, 01 Jun 2020 17:31:31 +0530
> Vaibhav Jain wrote:
>
>> Hi Christoph and Steven,
>>
>> Have addressed your review comment to update the patch description and
>> title for this patch. Can you please provide your ack to this patch.
>>
>>
>
> I thought I already di
On Mon, 01 Jun 2020 17:31:31 +0530
Vaibhav Jain wrote:
> Hi Christoph and Steven,
>
> Have addressed your review comment to update the patch description and
> title for this patch. Can you please provide your ack to this patch.
>
>
I thought I already did, but it appears it was a reply to a p
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: e376ca093587eafd840bb0f9df04090e2a54249c
commit: a3871a8b701613da2a13d6d1c523d0bb29ba62de [177/198] powerpc/rtas:
Implement reentrant rtas call
config: powerpc-chrp32_defconfig (attached as .config)
compil
On 6/1/20 5:37 PM, Michal Suchánek wrote:
On Mon, Jun 01, 2020 at 05:31:50PM +0530, Aneesh Kumar K.V wrote:
On 6/1/20 3:39 PM, Jan Kara wrote:
On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
On 5/29/20 3:22 PM, Jan Kara wrote:
On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
Thanks Michal
On Mon, Jun 01, 2020 at 05:31:50PM +0530, Aneesh Kumar K.V wrote:
> On 6/1/20 3:39 PM, Jan Kara wrote:
> > On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
> > > On 5/29/20 3:22 PM, Jan Kara wrote:
> > > > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> > > > > Thanks Michal. I also missed Jef
Hi Christoph and Steven,
Have addressed your review comment to update the patch description and
title for this patch. Can you please provide your ack to this patch.
Thanks,
~ Vaibhav
Vaibhav Jain writes:
> 'seq_buf' provides a very useful abstraction for writing to a string
> buffer without
On 6/1/20 3:39 PM, Jan Kara wrote:
On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
On 5/29/20 3:22 PM, Jan Kara wrote:
On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
Thanks Michal. I also missed Jeff in this email thread.
And I think you'll also need some of the sched maintainers for th
On Sat, May 30, 2020 at 07:27:50PM -0700, Ram Pai wrote:
> H_SVM_INIT_DONE incorrectly assumes that the Ultravisor has explicitly
> called H_SVM_PAGE_IN for all secure pages.
I don't think that is quite true. HV doesn't assume anything about
secure pages by itself.
> These GFNs continue to be
> n
On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
> On 5/29/20 3:22 PM, Jan Kara wrote:
> > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> > > Thanks Michal. I also missed Jeff in this email thread.
> >
> > And I think you'll also need some of the sched maintainers for the prctl
> > bits...
>
On Sat 30-05-20 09:35:19, Dan Williams wrote:
> On Sat, May 30, 2020 at 12:18 AM Aneesh Kumar K.V
> wrote:
> >
> > On 5/30/20 12:52 AM, Dan Williams wrote:
> > > On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V
> > > wrote:
> > >>
> > >> On 5/29/20 3:22 PM, Jan Kara wrote:
> > >>> Hi!
> > >>>
> >
Hi Finn,
On Mon, Jun 1, 2020 at 2:15 AM Finn Thain wrote:
> On Sun, 31 May 2020, Geert Uytterhoeven wrote:
> > On Sun, May 31, 2020 at 1:20 AM Finn Thain
> > wrote:
> > > arch/m68k/include/asm/adb_iop.h | 1 +
> > > drivers/macintosh/adb-iop.c | 32 ++--
> >
> >
Hi Brad,
On Sun, May 31, 2020 at 10:01 PM Brad Boyer wrote:
> On Sun, May 31, 2020 at 10:38:04AM +0200, Geert Uytterhoeven wrote:
> > > arch/m68k/include/asm/adb_iop.h | 1 +
> > As this header file is used by a single source file only, perhaps it should
> > just be absorbed by the latter?
> > T
Hi Michael,
Le 07/12/2019 à 18:20, Christophe Leroy a écrit :
call_do_irq() and call_do_softirq() are simple enough to be
worth inlining.
Inlining them avoids an mflr/mtlr pair plus a save/reload on stack.
It also allows GCC to keep the saved ksp_limit in an nonvolatile reg.
This is inspired f
60 matches
Mail list logo
