> On 20 Sep 2022, at 2:54 pm, Rohan McLure wrote:
>
>> On 20 Sep 2022, at 12:03 pm, Nicholas Piggin wrote:
>>
>> On Fri Sep 16, 2022 at 3:32 PM AEST, Rohan McLure wrote:
>>> Clear user state in gprs (assign to zero) to reduce the influence of user
>>> registers on speculation within kernel
Le 21/09/2022 à 05:33, Samuel Holland a écrit :
> On 9/19/22 07:37, Michael Ellerman wrote:
>> Christophe Leroy writes:
>>> Le 16/09/2022 à 07:05, Samuel Holland a écrit :
With CONFIG_PREEMPT=y (involuntary preemption enabled), it is possible
to switch away from a task inside
David Hildenbrand writes:
> Linus notes [1] that the introduction of new code that uses VM_BUG_ON()
> is just as bad as BUG_ON(), because it will crash the kernel on
> distributions that enable CONFIG_DEBUG_VM (like Fedora):
>
> VM_BUG_ON() has the exact same semantics as BUG_ON. It is
> On 20 Sep 2022, at 11:59 am, Nicholas Piggin wrote:
>
> On Fri Sep 16, 2022 at 3:32 PM AEST, Rohan McLure wrote:
>> Implement syscall wrapper as per s390, x86, arm64. When enabled
>> cause handlers to accept parameters from a stack frame rather than
>> from user scratch register state. This
On 9/21/22 07:21, Barry Song wrote:
> On Wed, Sep 21, 2022 at 1:50 PM Barry Song <21cn...@gmail.com> wrote:
>>
>> On Tue, Sep 20, 2022 at 8:45 PM Anshuman Khandual
>> wrote:
>>>
>>>
>>>
>>> On 9/20/22 09:09, Barry Song wrote:
On Tue, Sep 20, 2022 at 3:00 PM Anshuman Khandual
wrote:
On 9/19/22 07:37, Michael Ellerman wrote:
> Christophe Leroy writes:
>> Le 16/09/2022 à 07:05, Samuel Holland a écrit :
>>> With CONFIG_PREEMPT=y (involuntary preemption enabled), it is possible
>>> to switch away from a task inside copy_{from,to}_user. This left the CPU
>>> with userspace access
Nicholas Miehlbradt writes:
> There is support for DEBUG_PAGEALLOC on hash but not on radix.
> Add support on radix.
>
> Signed-off-by: Nicholas Miehlbradt
> ---
> v2: Revert change to radix_memory_block_size, instead set the size
> in radix_init_pgtable and radix__create_section_mapping
Hi,
On 2022/9/21 0:49, Ard Biesheuvel wrote:
On Thu, 15 Sept 2022 at 10:47, Peter Zijlstra wrote:
On Thu, Sep 15, 2022 at 10:56:58AM +0800, Chen Zhongjin wrote:
We have found some anonymous information on x86 in .rodata.
Well yes, but that's still a bunch of heuristics on our side.
I'm
From: Christophe Leroy
If the page is already mapped resp. already unmapped, bail out.
Signed-off-by: Christophe Leroy
Signed-off-by: Nicholas Miehlbradt
---
arch/powerpc/mm/book3s64/hash_utils.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
KFENCE support was added for ppc32 in commit 90cbac0e995d
("powerpc: Enable KFENCE for PPC32").
Enable KFENCE on ppc64 architecture with hash and radix MMUs.
It uses the same mechanism as debug pagealloc to
protect/unprotect pages. All KFENCE kunit tests pass on both
MMUs.
KFENCE memory is
From: Christophe Leroy
debug_pagealloc_enabled() is always defined and constant folds to
'false' when CONFIG_DEBUG_PAGEALLOC is not enabled.
Remove the #ifdefs, the code and associated static variables will
be optimised out by the compiler when CONFIG_DEBUG_PAGEALLOC is
not defined.
There is support for DEBUG_PAGEALLOC on hash but not on radix.
Add support on radix.
Signed-off-by: Nicholas Miehlbradt
---
v2: Revert change to radix_memory_block_size, instead set the size
in radix_init_pgtable and radix__create_section_mapping directly.
---
On Wed, Sep 21, 2022 at 1:50 PM Barry Song <21cn...@gmail.com> wrote:
>
> On Tue, Sep 20, 2022 at 8:45 PM Anshuman Khandual
> wrote:
> >
> >
> >
> > On 9/20/22 09:09, Barry Song wrote:
> > > On Tue, Sep 20, 2022 at 3:00 PM Anshuman Khandual
> > > wrote:
> > >>
> > >>
> > >> On 8/22/22 13:51,
On Tue, Sep 20, 2022 at 8:45 PM Anshuman Khandual
wrote:
>
>
>
> On 9/20/22 09:09, Barry Song wrote:
> > On Tue, Sep 20, 2022 at 3:00 PM Anshuman Khandual
> > wrote:
> >>
> >>
> >> On 8/22/22 13:51, Yicong Yang wrote:
> >>> +static inline bool arch_tlbbatch_should_defer(struct mm_struct *mm)
>
Update the 64s GENERIC_CPU option. POWER4 support has been dropped, so
make that clear in the option name. The POWER5_CPU option is dropped
because it's uncommon, and GENERIC_CPU covers it.
-mtune= before power8 is dropped because the minimum gcc version
supports power8, and tuning is made
Big-endian GENERIC_CPU supports 970, but builds with -mcpu=power5.
POWER5 is ISA v2.02 whereas 970 is v2.01 plus Altivec. 2.02 added
the popcntb instruction which a compiler might use.
Use -mcpu=power4.
Fixes: 471d7ff8b51b ("powerpc/64s: Remove POWER4 support")
Signed-off-by: Nicholas Piggin
On Wed Sep 21, 2022 at 8:16 AM AEST, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 20, 2022 at 12:01:47AM +1000, Nicholas Piggin wrote:
> > Update the 64s GENERIC_CPU option. POWER4 support has been dropped, so
> > make that clear in the option name.
>
> AFAIR the minimum now is POWER4+ (ISA
From: Paolo Bonzini
KVM_REQ_UNHALT is now unnecessary because it is replaced by the return
value of kvm_vcpu_block/kvm_vcpu_halt. Remove it.
No functional change intended.
Signed-off-by: Paolo Bonzini
Signed-off-by: Sean Christopherson
---
Documentation/virt/kvm/vcpu-requests.rst | 28
From: Paolo Bonzini
KVM_REQ_UNHALT is a weird request that simply reports the value of
kvm_arch_vcpu_runnable() on exit from kvm_vcpu_halt(). Only
MIPS and x86 are looking at it, the others just clear it. Check
the state of the vCPU directly so that the request is handled
as a nop on all
From: Paolo Bonzini
kvm_vcpu_check_block() is called while not in TASK_RUNNING, and therefore
it cannot sleep. Writing to guest memory is therefore forbidden, but it
can happen on AMD processors if kvm_check_nested_events() causes a vmexit.
Fortunately, all events that are caught by
Don't snapshot pending INIT/SIPI events prior to checking nested events,
architecturally there's nothing wrong with KVM processing (dropping) a
SIPI that is received immediately after synthesizing a VM-Exit. Taking
and consuming the snapshot makes the flow way more subtle than it needs
to be,
Explicitly check for a pending INIT/SIPI event when emulating VMXOFF
instead of blindly making an event request. There's obviously no need
to evaluate events if none are pending.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/nested.c | 4 ++--
1 file changed, 2 insertions(+), 2
Evaluate interrupts, i.e. set KVM_REQ_EVENT, if INIT or SIPI is pending
when emulating nested VM-Enter. INIT is blocked while the CPU is in VMX
root mode, but not in VMX non-root, i.e. becomes unblocked on VM-Enter.
This bug has been masked by KVM calling ->check_nested_events() in the
core run
Set KVM_REQ_EVENT if INIT or SIPI is pending when the guest enables GIF.
INIT in particular is blocked when GIF=0 and needs to be processed when
GIF is toggled to '1'. This bug has been masked by (a) KVM calling
->check_nested_events() in the core run loop and (b) hypervisors toggling
GIF from
From: Paolo Bonzini
Do not return true from kvm_vcpu_has_events() if the vCPU isn' going to
immediately process a pending INIT/SIPI. INIT/SIPI shouldn't be treated
as wake events if they are blocked.
Signed-off-by: Paolo Bonzini
[sean: rebase onto refactored INIT/SIPI helpers, massage
Rename kvm_apic_has_events() to kvm_apic_has_pending_init_or_sipi() so
that it's more obvious that "events" really just means "INIT or SIPI".
Opportunistically clean up a weirdly worded comment that referenced
kvm_apic_has_events() instead of kvm_apic_accept_events().
No functional change
Rename and invert kvm_vcpu_latch_init() to kvm_apic_init_sipi_allowed()
so as to match the behavior of {interrupt,nmi,smi}_allowed(), and expose
the helper so that it can be used by kvm_vcpu_has_events() to determine
whether or not an INIT or SIPI is pending _and_ can be taken immediately.
Set KVM_REQ_EVENT when MTF becomes pending to ensure that KVM will run
through inject_pending_event() and thus vmx_check_nested_events() prior
to re-entering the guest.
MTF currently works by virtue of KVM's hack that calls
kvm_check_nested_events() from kvm_vcpu_running(), but that hack will
be
From: Paolo Bonzini
Interrupts, NMIs etc. sent while in guest mode are already handled
properly by the *_interrupt_allowed callbacks, but other events can
cause a vCPU to be runnable that are specific to guest mode.
In the case of VMX there are two, the preemption timer and the
monitor trap.
Non-x86 folks, there's nothing interesting to see here, y'all got pulled
in because removing KVM_REQ_UNHALT requires deleting kvm_clear_request()
from arch code.
Note, this based on:
https://github.com/sean-jc/linux.git tags/kvm-x86-6.1-1
to pre-resolve conflicts with the
generic_secondary_common_init() calls LOAD_REG_ADDR(r7, nr_cpu_ids)
conditionally on CONFIG_SMP. However, if NR_CPUS == 1, kernel doesn't
use the nr_cpu_ids, and in C code, it's just:
#if NR_CPUS == 1
#define nr_cpu_ids
...
The [1] makes declaration of nr_cpu_ids conditional on NR_CPUS ==
Because Nadav asked about tracing/kprobing idle, I had another go around
and noticed not all functions calling ct_cpuidle_enter are __cpuidle.
Basically all cpuidle_driver::enter functions should be __cpuidle; i'll
do that audit shortly.
For now this is ct_cpuidle_enter / CPU_IDLE_ENTER users.
On Mon, Sep 19, 2022 at 11:59:39AM +0200, Peter Zijlstra wrote:
> Hi All!
>
> At long last, a respin of the cpuidle vs rcu cleanup patches.
>
> v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
>
> These here patches clean up the mess that is cpuidle vs rcuidle.
>
> At the
On Wed, Sep 21, 2022 at 08:20:06AM +1000, Stephen Rothwell wrote:
> Hi Yury,
>
> On Tue, 20 Sep 2022 08:29:35 -0700 Yury Norov wrote:
> >
>
> > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> > index cf2c08902c05..7cb97881635e 100644
> > ---
Hi Yury,
On Tue, 20 Sep 2022 08:29:35 -0700 Yury Norov wrote:
>
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index cf2c08902c05..7cb97881635e 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -400,7 +400,11 @@
Hi!
On Tue, Sep 20, 2022 at 12:01:47AM +1000, Nicholas Piggin wrote:
> Update the 64s GENERIC_CPU option. POWER4 support has been dropped, so
> make that clear in the option name.
AFAIR the minimum now is POWER4+ (ISA 2.01), not POWER5 (ISA 2.02).
> -mtune= before power8 is dropped because the
This is a first stab at adding serdes support on the LS1088A. Linux
hangs around when the serdes is initialized if the si5341 is enabled, so
it's commented out. The MC firmware needs to be fairly new (it must
support DPAA2_MAC_FEATURE_PROTOCOL_CHANGE), and the DPC needs to set the
macs to
This adds some modes necessary for Lynx 10G support. 2500BASE-X, also
known as 2.5G SGMII, is 1000BASE-X/SGMII overclocked to 3.125 GHz, with
autonegotiation disabled. 10GBASE-R, also known as XFI, is the protocol
spoken between the PMA and PMD ethernet layers for 10GBASE-T and
10GBASE-S/L/E. It
This adds appropriate bindings for the macs which use the SerDes. The
156.25MHz fixed clock is a crystal. The 100MHz clocks (there are
actually 3) come from a Renesas 6V49205B at address 69 on i2c0. There is
no driver for this device (and as far as I know all you can do with the
100MHz clocks is
This adds bindings for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v4)
Changes in v4:
- Convert to new bindings
Changes in v3:
- New
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 18
This adds bindings for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v4)
Changes in v4:
- Convert to new bindings
Changes in v3:
- Describe modes in device tree
Changes in v2:
- Use one phy cell
This adds support for the Lynx 10G "SerDes" devices found on various NXP
QorIQ SoCs. There may be up to four SerDes devices on each SoC, each
supporting up to eight lanes. Protocol support for each SerDes is highly
heterogeneous, with each SoC typically having a totally different
selection of
This adds ids for the Lynx 10g SerDes's internal PLLs. These may be used
with assigned-clock* to specify a particular frequency to use. For
example, to set the second PLL (at offset 0x20)'s frequency, use
LYNX10G_PLLa(1). These are for use only in the device tree, and are not
otherwise used by the
This adds a binding for the SerDes module found on QorIQ processors.
Each phy is a subnode of the top-level device, possibly supporting
multiple lanes and protocols. This "thick" #phy-cells is used due to
allow for better organization of parameters. Note that the particular
parameters necessary to
This adds support for the Lynx 10G SerDes found on the QorIQ T-series
and Layerscape series. Due to limited time and hardware, only support
for the LS1046ARDB is added in this initial series. There is a sketch
for LS1088ARDB support, but it is incomplete.
Dynamic reconfiguration does not work.
On Tuesday 20 September 2022 19:36:42 Christophe Leroy wrote:
> In addition to checking whether a page is reserved before allocating
> it to highmem, verify that it is valid memory.
>
> Otherwise the kernel Oopses as below:
>
> [0.00] mem auto-init: stack:off, heap alloc:off, heap
In addition to checking whether a page is reserved before allocating
it to highmem, verify that it is valid memory.
Otherwise the kernel Oopses as below:
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] Kernel attempted to read user page (7df58) - exploit
On Thu, 15 Sept 2022 at 10:47, Peter Zijlstra wrote:
>
> On Thu, Sep 15, 2022 at 10:56:58AM +0800, Chen Zhongjin wrote:
>
> > We have found some anonymous information on x86 in .rodata.
>
> Well yes, but that's still a bunch of heuristics on our side.
>
> > I'm not sure if those are *all* of Josh
Based on getPerfCountInfo v1.018 documentation, some of the
hv_gpci events got deprecated for platforms firmware that
supports counter_info_version 0x8 or above.
Patch fixes the hv_gpci event list by adding a new attribute
group called "hv_gpci_event_attrs_v6" and a "EVENT_ENABLE"
macro to enable
generic_secondary_common_init() calls LOAD_REG_ADDR(r7, nr_cpu_ids)
conditionally on CONFIG_SMP. However, if NR_CPUS == 1, kernel doesn't
use the nr_cpu_ids, and in C code, it's just:
#if NR_CPUS == 1
#define nr_cpu_ids
...
The [1] makes declaration of nr_cpu_ids conditional on NR_CPUS ==
On Tue, Sep 20, 2022 at 11:04:57PM +1000, Alexey Kardashevskiy wrote:
> Up until now PPC64 managed to avoid using iommu_ops. The VFIO driver
> uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
> the Type1 VFIO driver. Recent development added 2 uses of iommu_ops to
> the generic VFIO
Up until now PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development added 2 uses of iommu_ops to
the generic VFIO which broke POWER:
- a coherency capability check;
- blocking IOMMU domain -
Here is another take on iommu_ops on POWER to make VFIO work
again on POWERPC64. Tested on PPC, kudos to Fred!
The tree with all prerequisites is here:
https://github.com/aik/linux/tree/kvm-fixes-wip
The previous discussion is here:
Commit 24d33ac5b8ff ("powerpc/64s: Make prom_init require RELOCATABLE")
made prom_init depend on CONFIG_RELOCATABLE.
But it missed cleaning up a case in the linker script for RELOCATABLE=n,
and associated symbols. Remove them now.
Fixes: 24d33ac5b8ff ("powerpc/64s: Make prom_init require
PPC64 IOMMU API defines iommu_table_group_ops which handles DMA windows
for PEs: control the ownership, create/set/unset a table the hardware
for dynamic DMA windows (DDW). VFIO uses the API to implement support
on POWER.
So far only PowerNV IODA2 (POWER8 and newer machines) implemented this
and
The following patches are going to add dependency/use of iommu_ops which
is initialized in subsys_initcall as well.
This moves pciobios_init() to the next initcall level.
This should not cause behavioral change.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/pci_64.c | 2 +-
1
checkpatch does not point out that VM_BUG_ON() and friends should be
avoided, however, Linus notes:
VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally
no different, the only difference is "we can make the code smaller
because these are less important". [1]
So let's
Unused, let's drop it.
Signed-off-by: David Hildenbrand
---
arch/powerpc/kernel/prom_init.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index a6669c40c1db..d464ba412084 100644
--- a/arch/powerpc/kernel/prom_init.c
Linus notes [1] that the introduction of new code that uses VM_BUG_ON()
is just as bad as BUG_ON(), because it will crash the kernel on
distributions that enable CONFIG_DEBUG_VM (like Fedora):
VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally
no different, the only
As it seems to be rather unclear if/when to use BUG(), BUG_ON(),
VM_BUG_ON(), WARN_ON_ONCE(), ... let's try to document the result of a
recent discussion.
Details can be found in patch #1.
RFC -> v1:
* "coding-style.rst: document BUG() and WARN() rules ("do not crash the
kernel")"
->
We want to move away from using SMT priority updates for cpu_relax, and
use a 'wait' instruction which is similar to x86. As well as being a
much better fit for what everybody else uses and tests with, priority
nops are stateful which is nasty (interrupts have to consider they might
be taken at a
The wait instruction encoding changed between ISA v2.07 and ISA v3.0.
In v3.1 the instruction gained a new field.
Update the PPC_WAIT macro to the current encoding. Rename the older
incompatible one with a _v203 suffix as it was introduced in v2.03
(the WC field was introduced in v2.07 but the
On Mon, Sep 19, 2022 at 11:59:50AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again, some *four* times, before going idle is daft.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Tony Lindgren
> Tested-by: Tony Lindgren
On Tue, Sep 20, 2022 at 10:57:00AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 19, 2022 at 03:19:27PM +0200, Frederic Weisbecker wrote:
> > On Mon, Sep 19, 2022 at 11:59:42AM +0200, Peter Zijlstra wrote:
> > > cpuidle_state::enter() methods should be IRQ invariant
> >
> > Got a bit confused with
On Tue, Sep 20, 2022 at 10:58:59AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 19, 2022 at 04:21:23PM +0200, Frederic Weisbecker wrote:
> > On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> > > Doing RCU-idle outside the driver, only to then temporarily enable it
> > > again, at
On Mon, Sep 19, 2022 at 04:21:23PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> > Doing RCU-idle outside the driver, only to then temporarily enable it
> > again, at least twice, before going idle is daft.
>
> Hmm, what ends up calling
On Mon, Sep 19, 2022 at 03:19:27PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:42AM +0200, Peter Zijlstra wrote:
> > cpuidle_state::enter() methods should be IRQ invariant
>
> Got a bit confused with the invariant thing since the first chunck I
> see in this patch is a
On Mon, Sep 19, 2022 at 05:19:05PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 19, 2022 at 04:31:42PM +0200, Frederic Weisbecker wrote:
> > On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote:
> > > Doing RCU-idle outside the driver, only to then teporarily enable it
> > > again before
On Mon, Sep 19, 2022 at 6:18 PM Peter Zijlstra wrote:
>
> Current arch_cpu_idle() is called with IRQs disabled, but will return
> with IRQs enabled.
>
> However, the very first thing the generic code does after calling
> arch_cpu_idle() is raw_local_irq_disable(). This means that
> architectures
> On 20 Sep 2022, at 12:03 pm, Nicholas Piggin wrote:
>
> On Fri Sep 16, 2022 at 3:32 PM AEST, Rohan McLure wrote:
>> Clear user state in gprs (assign to zero) to reduce the influence of user
>> registers on speculation within kernel syscall handlers. Clears occur
>> at the very beginning of
On Mon Sep 19, 2022 at 3:39 PM AEST, Michael Ellerman wrote:
> kernel test robot writes:
> > Hi Nicholas,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on powerpc/next]
> > [also build test ERROR on linus/master v6.0-rc5 next-20220916]
> > [If your patch is
On Tue Sep 20, 2022 at 3:01 AM AEST, Christophe Leroy wrote:
> cpu_specs[] is full of #ifdefs depending on the different
> types of CPU.
>
> CPUs are mutually exclusive, it is therefore possible to split
> cpu_specs[] into smaller more readable pieces.
>
> Create cpu_specs_XXX.h that will each be
On 9/20/22 09:09, Barry Song wrote:
> On Tue, Sep 20, 2022 at 3:00 PM Anshuman Khandual
> wrote:
>>
>>
>> On 8/22/22 13:51, Yicong Yang wrote:
>>> +static inline bool arch_tlbbatch_should_defer(struct mm_struct *mm)
>>> +{
>>> + return true;
>>> +}
>>
>> This needs to be conditional on
On Fri Sep 16, 2022 at 8:57 PM AEST, Disha Goel wrote:
> From: Kajol Jain"
>
> Commit 57dc0eed73ca ("KVM: PPC: Book3S HV P9: Implement PMU save/restore
> in C") removed the PMU save/restore functions from assembly code and
> implemented these functions in C, for power9 and later platforms.
>
>
On Fri Sep 16, 2022 at 8:57 PM AEST, Disha Goel wrote:
> The kvm code was refactored to convert some of kvm assembly routines to C.
> This includes commits which moved code path for the kvm guest entry/exit
> for p7/8 from aseembly to C. As part of the code changes, usage of some of
> the macros
On Fri, Sep 16, 2022, at 7:32 AM, Rohan McLure wrote:
> 32-bit ABIs support passing 64-bit integers by registers via argument
> translation. Commit 59c10c52f573 ("riscv: compat: syscall: Add
> compat_sys_call_table implementation") implements the compat_arg_u64
> macro for efficiently defining
On Tue, 2022-09-20 at 05:44 +, Christophe Leroy wrote:
>
> As far as I know, cachelines are minimum 64 bytes on PPC64 aren't
> they ?
In practice maybe. I don't know what the convention is in the kernel in
cases where the ISA is less specific than what the supported machines
do.
> > Related
local_paca is declared as global register asm("r13"), it is therefore
garantied to always ever be r13.
It is therefore not required to opencode r13 in the assembly, use
a reference to local_paca->irq_soft_mask instead.
This also allows removing the 'memory' clobber in irq_soft_mask_set()
as GCC
This partialy reapply commit ef5b570d3700 ("powerpc/irq: Don't
open code irq_soft_mask helpers") which was reverted by
commit 684c68d92e2e ("Revert "powerpc/irq: Don't open code
irq_soft_mask helpers"")
irq_soft_mask_set_return() and irq_soft_mask_or_return()
are overset of irq_soft_mask_set().
79 matches
Mail list logo
