On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> The kernel can handle retrying RTAS function calls in response to
> -2/990x in the sys_rtas() handler instead of relaying the
> intermediate
> status to user space.
>
> Justifications:
>
> * Currently i
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> Add lockdep annotations for the following properties that must hold:
>
> * Any error log retrieval must be atomically coupled with the prior
> RTAS call, without a window for another RTAS call to occur
Hi,
On 2023-03-22 23:17:35, Michael Ellerman wrote:
> Kautuk Consul writes:
> > kvmppc_hv_entry is called from only 2 locations within
> > book3s_hv_rmhandlers.S. Both of those locations set r4
> > as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
> > So, shift the r4 load instruction to kv
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> Any caller of rtas_call_unlocked() must provide an rtas_args
> parameter
> block distinct from the core rtas_args buffer used by the rtas_call()
> path. It's an unlikely error to make, but the potential c
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> The function name va_rtas_call_unlocked() is confusing: it may be
> called with or without rtas_lock held. Rename it to va_rtas_call().
>
> Signed-off-by: Nathan Lynch
Not a huge fan of the name, the v
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> Add documentation for rtas_call_unlocked(), including details on how
> it differs from rtas_call().
>
> Signed-off-by: Nathan Lynch
Reviewed-by: Andrew Donnellan
--
Andrew DonnellanOzLabs, ADL
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> Using memcpy() isn't safe when buf is identical to rtas_err_buf,
> which
> can happen during boot before slab is up. Full context which may not
> be obvious from the diff:
>
> if (altbuf) {
>
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> > From: Nathan Lynch
> >
> > CHRP and PAPR agree: "In order to make an RTAS call, the operating
> > system must construct an argument call buffer aligned on an eight
> > byte
> > boundary in physically contiguous real memory [.
been built successfully.
More configs may be tested in the coming days.
tested configs:
alphaallyesconfig gcc
alpha defconfig gcc
arc allyesconfig gcc
arc buildonly-randconfig-r003-20230322
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> The 'filter' member is a pointer, not a bool; fix the wording
> accordingly.
>
> Signed-off-by: Nathan Lynch
Reviewed-by: Andrew Donnellan
> ---
> arch/powerpc/kernel/rtas.c | 2 +-
> 1 file changed
On Wed, Mar 22, 2023 at 06:22:28PM +, Valentin Schneider wrote:
> On 22/03/23 18:22, Peter Zijlstra wrote:
> >>hackbench-157 [001]10.894320: ipi_send_cpu: cpu=3
> >> callsite=check_preempt_curr+0x37 callback=0x0
> >
> > Arguably we should be setting callback to scheduler
On Mon, Mar 06, 2023 at 09:09:13AM +0530, Athira Rajeev wrote:
+ } else if (proc_gen == proc_gen_p10) {
+ int val;
+ char al[8], xl[8], otl[8], phb[8];
Are four different variables needed here? I think you could just reuse
one temporary variable.
Hi Athira,
On Mon, Mar 06, 2023 at 09:09:11AM +0530, Athira Rajeev wrote:
Add a function dt_find_by_name_substr() that returns the child node if
it matches till first occurence at "@" of a given name, otherwise NULL.
Given this summary, I don't understand the following:
+ assert(dt_fin
On Mon, Mar 20, 2023 at 03:16:31PM +0200, Andy Shevchenko wrote:
> ...
> -#define pci_bus_for_each_resource(bus, res, i)
> \
> - for (i = 0; \
> - (res = pci_bus_resource_n(bus, i)) || i < PCI_BRIDGE_RES
Hi Andy and Mika,
I really like the improvements here. They make the code read much
better.
On Mon, Mar 20, 2023 at 03:16:30PM +0200, Andy Shevchenko wrote:
> From: Mika Westerberg
> ...
> static void fixup_winbond_82c105(struct pci_dev* dev)
> {
> - int i;
> + struct resource *r;
>
On Fri, Feb 24, 2023 at 7:58 AM Björn Töpel wrote:
>
> Alexandre Ghiti writes:
>
> > +cc linux-kbuild, llvm, Nathan, Nick
> >
> > On 2/15/23 15:36, Alexandre Ghiti wrote:
> >> From: Alexandre Ghiti
> >>
> > I tried a lot of things, but I struggle to understand, does anyone have
> > any idea? FYI
On 22/03/23 18:22, Peter Zijlstra wrote:
> On Wed, Mar 22, 2023 at 05:01:13PM +, Valentin Schneider wrote:
>
>> > So I was thinking something like this:
>
>> Hm, this does get rid of the func being passed down the helpers, but this
>> means the trace events are now stateful, i.e. I need the fir
On 3/20/23 6:55 PM, Lorenzo Bianconi wrote:
Greeting's
Warning is seen while booting kernels from 6.3.0-rc3-next-20230317 on my
powerpc Power 10 LPAR
Boots fine without warnings when below patch is reverted
commit 4d5ab0ad964df178beba031b89429a601893ff61
Author: Lorenzo Bianconi
Date: Th
On Thu, Mar 16, 2023, Michael Ellerman wrote:
> Nicholas Piggin writes:
> > Hi,
> >
> > This series adds initial KVM selftests support for powerpc
> > (64-bit, BookS).
>
> Awesome.
>
> > It spans 3 maintainers but it does not really
> > affect arch/powerpc, and it is well contained in selftests
On Wed, Mar 22, 2023 at 05:01:13PM +, Valentin Schneider wrote:
> > So I was thinking something like this:
> Hm, this does get rid of the func being passed down the helpers, but this
> means the trace events are now stateful, i.e. I need the first and last
> events in a CSD stack to figure ou
On 22/03/23 15:04, Peter Zijlstra wrote:
> On Wed, Mar 22, 2023 at 12:20:28PM +, Valentin Schneider wrote:
>> On 22/03/23 10:53, Peter Zijlstra wrote:
>
>> > Hurmph... so we only really consume @func when we IPI. Would it not be
>> > more useful to trace this thing for *every* csd enqeued?
>>
>
On Wed, Mar 22, 2023 at 12:20:28PM +, Valentin Schneider wrote:
> On 22/03/23 10:53, Peter Zijlstra wrote:
> > Hurmph... so we only really consume @func when we IPI. Would it not be
> > more useful to trace this thing for *every* csd enqeued?
>
> It's true that any CSD enqueued on that CPU's
On Tue, Mar 14, 2023 at 02:11:44PM -0600, Alex Williamson wrote:
> On Thu, 26 Jan 2023 11:37:45 -0800
> Suren Baghdasaryan wrote:
>
> > This patchset was originally published as a part of per-VMA locking [1] and
> > was split after suggestion that it's viable on its own and to facilitate
> > the
@linux-kbuild: Does anyone has an idea to solve this?
Thanks!
On 2/22/23 13:29, Alexandre Ghiti wrote:
+cc linux-kbuild, llvm, Nathan, Nick
On 2/15/23 15:36, Alexandre Ghiti wrote:
From: Alexandre Ghiti
This config allows to compile 64b kernel as PIE and to relocate it at
any virtual addres
On 22/03/23 9:23 am, Russell Currey wrote:
fail_iommu_setup() registers the fail_iommu_bus_notifier struct to both
PCI and VIO buses. struct notifier_block is a linked list node, so this
causes any notifiers later registered to either bus type to also be
registered to the other since they sha
On Mon, 6 Mar 2023 11:31:28 -0600 (CST), Timothy Pearson wrote:
>
Applied to powerpc/next.
[4/4] Add myself to MAINTAINERS for Power VFIO support
https://git.kernel.org/powerpc/c/a34d2f0d79ec890b9b1b156a90016b6330173b8a
cheers
On Mon, 6 Mar 2023 11:31:00 -0600 (CST), Timothy Pearson wrote:
> allow blocking domains
>
> 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
On Mon, 6 Mar 2023 11:30:42 -0600 (CST), Timothy Pearson wrote:
> 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.
>
> [...
On Wed, 01 Mar 2023 22:39:17 +0530, Kajol Jain wrote:
> The testcase verifies the setting of different fields in Monitor Mode
> Control Register A (MMCRA). In the current code, EV_CODE_EXTRACT macro
> is used to extract the "sample" field, which then needs to be further
> processed to fetch rand_sa
On Mon, 6 Mar 2023 11:30:20 -0600 (CST), Timothy Pearson wrote:
> 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.
>
>
On Wed, 15 Feb 2023 11:41:14 -0700, Nathan Chancellor wrote:
> Currently, CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2 is not selectable with
> ld.lld because of an explicit dependency on GNU ld, due to lack of
> testing with LLVM.
>
> Erhard was kind enough to test this option on his hardware with LLVM 15,
On Wed, 08 Mar 2023 08:36:14 +1100, Michael Neuling wrote:
> On the max config P10 machine (1920 threads and 64TB) this test fails
> with a timeout:
>
> Sending signals to all threads 10 times...!! killing vmx_signal
> !! child died by signal 15
> failure: vmx_signal
>
> [...]
Applie
On Fri, 10 Mar 2023 15:28:48 -0800, Luis Chamberlain wrote:
> We can simplify the way we do sysctl registration both by
> reducing the number of lines and also avoiding calllers which
> could do recursion. The docs are being updated to help reflect
> this better [0].
>
> [0]
> https://lore.kernel
On Mon, 31 Oct 2022 21:54:52 -0400, Bo Liu wrote:
> The current code provokes some kernel-doc warnings:
> arch/powerpc/kernel/process.c:1606: warning: This comment starts with
> '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
>
>
Applied to powerpc/n
On Sat, 18 Feb 2023 10:15:44 +0100, Christophe Leroy wrote:
> Machine name in struct machdep_calls should never be modified.
>
> Mark it const.
>
>
Patches 1-7 applied to powerpc/next.
[01/10] powerpc/machdep: Make machine name const
https://git.kernel.org/powerpc/c/0aafbdf35c75cbfec8
On 22/03/23 10:53, Peter Zijlstra wrote:
> On Tue, Mar 07, 2023 at 02:35:58PM +, Valentin Schneider wrote:
>
>> @@ -477,6 +490,25 @@ static __always_inline void csd_unlock(struct
>> __call_single_data *csd)
>> smp_store_release(&csd->node.u_flags, 0);
>> }
>>
>> +static __always_inline v
Kautuk Consul writes:
> kvmppc_hv_entry is called from only 2 locations within
> book3s_hv_rmhandlers.S. Both of those locations set r4
> as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
> So, shift the r4 load instruction to kvmppc_hv_entry and
> thus modify the calling convention of this
On 22/03/23 11:30, Peter Zijlstra wrote:
> On Wed, Mar 22, 2023 at 10:39:55AM +0100, Peter Zijlstra wrote:
>> On Tue, Mar 07, 2023 at 02:35:52PM +, Valentin Schneider wrote:
>> > +TRACE_EVENT(ipi_send_cpumask,
>> > +
>> > + TP_PROTO(const struct cpumask *cpumask, unsigned long callsite, void
On Wed, Mar 22, 2023 at 10:39:55AM +0100, Peter Zijlstra wrote:
> On Tue, Mar 07, 2023 at 02:35:52PM +, Valentin Schneider wrote:
> > trace_ipi_raise() is unsuitable for generically tracing IPI sources due to
> > its "reason" argument being an uninformative string (on arm64 all you get
> > is "
On Tue, Mar 07, 2023 at 02:35:58PM +, Valentin Schneider wrote:
> @@ -477,6 +490,25 @@ static __always_inline void csd_unlock(struct
> __call_single_data *csd)
> smp_store_release(&csd->node.u_flags, 0);
> }
>
> +static __always_inline void
> +raw_smp_call_single_queue(int cpu, struc
On Tue, Mar 07, 2023 at 02:35:52PM +, Valentin Schneider wrote:
> trace_ipi_raise() is unsuitable for generically tracing IPI sources due to
> its "reason" argument being an uninformative string (on arm64 all you get
> is "Function call interrupts" for SMP calls).
>
> Add a variant of it that
41 matches
Mail list logo
