[powerpc:next-test] BUILD SUCCESS e2fc3a5d89adb5ca4a719942122475bd121c9143

2023-04-14 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next-test
branch HEAD: e2fc3a5d89adb5ca4a719942122475bd121c9143  powerpc/configs: Make 
pseries_defconfig an alias for ppc64le_guest

elapsed time: 724m

configs tested: 49
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alphaallyesconfig   gcc  
alpha   defconfig   gcc  
arc  allyesconfig   gcc  
arc defconfig   gcc  
arm  allmodconfig   gcc  
arm  allyesconfig   gcc  
arm defconfig   gcc  
arm64allyesconfig   gcc  
arm64   defconfig   gcc  
cskydefconfig   gcc  
i386 allyesconfig   gcc  
i386  debian-10.3   gcc  
i386defconfig   gcc  
i386 randconfig-a001-20230410   clang
i386 randconfig-a002-20230410   clang
i386 randconfig-a003-20230410   clang
i386 randconfig-a004-20230410   clang
i386 randconfig-a005-20230410   clang
i386 randconfig-a006-20230410   clang
ia64 allmodconfig   gcc  
ia64defconfig   gcc  
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarch   defconfig   gcc  
m68k allmodconfig   gcc  
m68kdefconfig   gcc  
mips allmodconfig   gcc  
mips allyesconfig   gcc  
nios2   defconfig   gcc  
parisc  defconfig   gcc  
parisc64defconfig   gcc  
powerpc  allmodconfig   gcc  
powerpc   allnoconfig   gcc  
riscvallmodconfig   gcc  
riscv allnoconfig   gcc  
riscv   defconfig   gcc  
riscv  rv32_defconfig   gcc  
s390 allmodconfig   gcc  
s390 allyesconfig   gcc  
s390defconfig   gcc  
sh   allmodconfig   gcc  
sparc   defconfig   gcc  
um i386_defconfig   gcc  
um   x86_64_defconfig   gcc  
x86_64allnoconfig   gcc  
x86_64   allyesconfig   gcc  
x86_64  defconfig   gcc  
x86_64  kexec   gcc  
x86_64   rhel-8.3   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests


RE: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms

2023-04-14 Thread Leo Li


> -Original Message-
> From: Michael Ellerman 
> Sent: Thursday, April 13, 2023 9:14 PM
> To: Leo Li ; Paul Gortmaker
> 
> Cc: Scott Wood ; Paul Mackerras ;
> Claudiu Manoil ; linuxppc-dev@lists.ozlabs.org;
> Pali Rohár 
> Subject: Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation
> platforms
> 
> Li Yang  writes:
> > On Tue, Feb 21, 2023 at 1:52 PM Paul Gortmaker
> >  wrote:
> >>
> >> [This RFC is proposed for v6.4 and hence is based off linux-next.]
> >>
> >> In a similar theme to the e300/MPC83xx evaluation platform
> >> removal[1], this targets removal of some 13 --> 21 year old
> >> e500/MPC85xx evaluation boards that were produced in limited numbers
> >> and primarily made available to hardware/software developers to shape
> their own boards and BSPs.
> >
> > These e500 platforms are similar to the e300 platforms that they are
> > still being shipped, the targeting market probably caused it to have a
> > longer life cycle.
> >
> ...
> >
> > The difference here from the e300 platforms is that MPC8540ADS,
> > MPC8560ADS, MPC8548CDS, MPC8568-MDS are the only reference
> platforms
> > supplied by us for these SoCs.  We don't have a separation of
> > evaluation platforms vs product-like platforms like we did later.
> > That probably means even if they don't look like "hobbyist" friendly
> > they are more likely to be still in use.
> 
> OK. But what is the chance anyone is booting upstream kernels on them?

We do still have these parts shipped, which means that there are definitely 
active users of these silicons.  But it is really hard to say how many of they 
are running latest upstream kernel.  IMO, if the nature of the application is 
critical it is likely they will need to update the kernel to get all the 
security fixes.  And the reference board will be helpful as a starting point 
when they update the kernel.

> 
> I assume no one at NXP is testing upstream on those boards?

To be frank they are not included in the routine tests carried out by the 
development team now which is not ideal to me.  But I think the support team 
are probably willing to help on issues with latest kernel when needed.

Regards,
Leo


[PATCH 6/7] mm/gup: remove vmas parameter from pin_user_pages()

2023-04-14 Thread Lorenzo Stoakes
After the introduction of FOLL_SAME_FILE we no longer require vmas for any
invocation of pin_user_pages(), so eliminate this parameter from the
function and all callers.

This clears the way to removing the vmas parameter from GUP altogether.

Signed-off-by: Lorenzo Stoakes 
---
 arch/powerpc/mm/book3s64/iommu_api.c   | 2 +-
 drivers/infiniband/hw/qib/qib_user_pages.c | 2 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c   | 2 +-
 drivers/infiniband/sw/siw/siw_mem.c| 2 +-
 drivers/media/v4l2-core/videobuf-dma-sg.c  | 2 +-
 drivers/vdpa/vdpa_user/vduse_dev.c | 2 +-
 drivers/vhost/vdpa.c   | 2 +-
 include/linux/mm.h | 3 +--
 io_uring/rsrc.c| 2 +-
 mm/gup.c   | 9 +++--
 mm/gup_test.c  | 9 -
 net/xdp/xdp_umem.c | 2 +-
 12 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/iommu_api.c 
b/arch/powerpc/mm/book3s64/iommu_api.c
index 81d7185e2ae8..d19fb1f3007d 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -105,7 +105,7 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
unsigned long ua,
 
ret = pin_user_pages(ua + (entry << PAGE_SHIFT), n,
FOLL_WRITE | FOLL_LONGTERM,
-   mem->hpages + entry, NULL);
+   mem->hpages + entry);
if (ret == n) {
pinned += n;
continue;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c 
b/drivers/infiniband/hw/qib/qib_user_pages.c
index f693bc753b6b..1bb7507325bc 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -111,7 +111,7 @@ int qib_get_user_pages(unsigned long start_page, size_t 
num_pages,
ret = pin_user_pages(start_page + got * PAGE_SIZE,
 num_pages - got,
 FOLL_LONGTERM | FOLL_WRITE,
-p + got, NULL);
+p + got);
if (ret < 0) {
mmap_read_unlock(current->mm);
goto bail_release;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c 
b/drivers/infiniband/hw/usnic/usnic_uiom.c
index 2a5cac2658ec..84e0f41e7dfa 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -140,7 +140,7 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t 
size, int writable,
ret = pin_user_pages(cur_base,
 min_t(unsigned long, npages,
 PAGE_SIZE / sizeof(struct page *)),
-gup_flags, page_list, NULL);
+gup_flags, page_list);
 
if (ret < 0)
goto out;
diff --git a/drivers/infiniband/sw/siw/siw_mem.c 
b/drivers/infiniband/sw/siw/siw_mem.c
index f51ab2ccf151..e6e25f15567d 100644
--- a/drivers/infiniband/sw/siw/siw_mem.c
+++ b/drivers/infiniband/sw/siw/siw_mem.c
@@ -422,7 +422,7 @@ struct siw_umem *siw_umem_get(u64 start, u64 len, bool 
writable)
umem->page_chunk[i].plist = plist;
while (nents) {
rv = pin_user_pages(first_page_va, nents, foll_flags,
-   plist, NULL);
+   plist);
if (rv < 0)
goto out_sem_up;
 
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c 
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 53001532e8e3..405b89ea1054 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -180,7 +180,7 @@ static int videobuf_dma_init_user_locked(struct 
videobuf_dmabuf *dma,
data, size, dma->nr_pages);
 
err = pin_user_pages(data & PAGE_MASK, dma->nr_pages, gup_flags,
-dma->pages, NULL);
+dma->pages);
 
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c 
b/drivers/vdpa/vdpa_user/vduse_dev.c
index 0c3b48616a9f..1f80254604f0 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -995,7 +995,7 @@ static int vduse_dev_reg_umem(struct vduse_dev *dev,
goto out;
 
pinned = pin_user_pages(uaddr, npages, FOLL_LONGTERM | FOLL_WRITE,
-   page_list, NULL);
+   page_list);
if (pinned != npages) {
ret = pinned < 0 ? pinned : -ENOMEM;
goto out;
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c

Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling

2023-04-14 Thread Bjorn Helgaas
On Thu, Apr 13, 2023 at 03:38:07PM +0200, Robert Richter wrote:
> On 12.04.23 16:29:01, Bjorn Helgaas wrote:
> > On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:
> > > From: Robert Richter 
> > > 
> > > RCEC AER corrected and uncorrectable internal errors (CIE/UIE) are
> > > disabled by default.

> > > +static void cxl_unmask_internal_errors(struct pci_dev *rcec)
> 
> Also renaming this to cxl_enable_rcec() to more generalize the
> function.

I didn't follow this.  "cxl_enable_rcec" doesn't say anything about
"unmasking" or "internal errors", which seems like the whole point.
And the function doesn't actually *enable* and RCEC.

> > > +{
> > > + if (!handles_cxl_errors(rcec))
> > > + return;
> > > +
> > > + if (__cxl_unmask_internal_errors(rcec))
> > > + dev_err(>dev, "cxl: Failed to unmask internal errors");
> > > + else
> > > + dev_dbg(>dev, "cxl: Internal errors unmasked");
> 
> I am going to change this to a pci_info() for alignment with other
> messages around:
> 
> [   14.200265] pcieport :40:00.3: PME: Signaling with IRQ 44
> [   14.213925] pcieport :40:00.3: AER: cxl: Internal errors unmasked
> [   14.228413] pcieport :40:00.3: AER: enabled with IRQ 44
> 
> Plus, using pci_err() instead of dev_err().

Thanks for that!

Bjorn


Re: [PATCH v3 5/6] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler

2023-04-14 Thread Bjorn Helgaas
On Thu, Apr 13, 2023 at 01:40:52PM +0200, Robert Richter wrote:
> On 12.04.23 17:02:33, Bjorn Helgaas wrote:
> > On Tue, Apr 11, 2023 at 01:03:01PM -0500, Terry Bowman wrote:
> > > From: Robert Richter 

> ...
> Let's assume just a simple CXL RCH topology:
> 
> PCI hierarchy:
> 
>   -
>   | ACPI0016  |--   Host bridge (CXL host)
>   | - CEDT| |
>---|   - RCRB base | |
>|  - :
>|   |
>|   |
>|  --- -
>|  | RCiEP   |.| RCEC  | Endpoint (CXL dev)
>|  | - BDF   | | - BDF |
>|  |   | - PCIe AER  | -
>|  |   | - CXL dvsec |
>|  |   |   (v2: reg loc) |
>|  |   |   - Comp regs   |
>|  |   | - CXL RAS   |
>|  |   ---
>:  :
>   
> CXL hierarchy:
> 
>::
>:  --|
>|  | CXL root port  |<
>|  ||
>|->| - dport RCRB   |<
>|  |   - PCIe AER   ||
>|  |   - Comp regs  ||
>|  | - CXL RAS  ||
>|  --|
>|  : |
>|  |   --|
>|  --->| CXL endpoint   |-
>|  | (v1: RCRB) |
>-->| - uport RCRB   |
>   |   - Comp regs  |
>   | - CXL RAS  |
>   --
> 
> Dport detected errors are reported using PCIe AER and CXL RAS caps in
> the dports RCRB.
> 
> Uport detected errors are reported using RCiEP's PCIe AER cap and
> either the uport's RCRB RAS cap or the RAS cap of the comp regs
> located using CXL DVSEC register locator.
> 
> In all cases the RCEC is used with either the RCEC (dport errors) or
> the RCiEP (uport errors) error source id (BDF: bus, dev, func).

I'm mostly interested in the PCI entities involved because that's all
aer.c can deal with.  For the above, I think the PCI core only knows
about these:

  00:00.0 RCEC  with AER, RCEC EA includes 00:01.0
  00:01.0 RCiEP with AER

aer_irq() would handle AER interrupts from 00:00.0.
cxl_handle_error() would be called for 00:00.0 and would call
handle_error_source() for everything below it (only 00:01.0 here).

> > The current code uses pcie_walk_rcec() in this path, which basically
> > searches below a Root Port or RCEC for devices that have an AER error
> > status bit set, add them to the e_info[] list, and call
> > handle_error_source() for each one:
> 
> For reference, this series adds support to handle RCH downstream
> port-detected errors as described in CXL 3.0, 12.2.1.1.
> 
> This flow looks correct to me, see comments inline.

We seem to be on the same page here, so I'll trim it out.

> ...
> > So we insert cxl_handle_error() in handle_error_source(), where it
> > gets called for the RCEC, and then it uses pcie_walk_rcec() again to
> > forcibly call handle_error_source() for *every* device "below" the
> > RCEC (even though they don't have AER error status bits set).
> 
> The CXL device contains the links to the dport's caps. Also, there can
> be multiple RCs with CXL devs connected to it. So we must search for
> all CXL devices now, determine the corresponding dport and inspect
> both, PCIe AER and CXL RAS caps.
> 
> > Then handle_error_source() ultimately calls the CXL driver err_handler
> > entry points (.cor_error_detected(), .error_detected(), etc), which
> > can look at the CXL-specific error status in the CXL RAS or RCRB or
> > whatever.
> 
> The AER driver (portdrv) does not have the knowledge of CXL internals.
> Thus the approach is to pass dport errors to the cxl_mem driver to
> handle it there in addition to cxl mem dev errors.
> 
> > So this basically looks like a workaround for the fact that the AER
> > code only calls handle_error_source() when it finds AER error status,
> > and CXL doesn't *set* that AER error status.  There's not that much
> > code here, but it seems like a quite a bit of complexity in an area
> > that is already pretty complicated.

My main point here (correct me if I got this wrong) is that:

  - A RCEC generates an AER interrupt

  - find_source_device() searches all devices below the RCEC and
builds a list everything for which to call handle_error_source()

  - cxl_handle_error() *again* looks at all devices below the same
RCEC and calls handle_error_source() for each one

So the main difference here is that the existing flow only calls
handle_error_source() when it finds an error logged in an AER status
register, while the new CXL flow calls handle_error_source() for
*every* device below the RCEC.

I think it's 

Re: linux-next: manual merge of the drm tree with the powerpc tree

2023-04-14 Thread Mark Brown
On Thu, Apr 13, 2023 at 11:47:25AM -0700, Nathan Chancellor wrote:
> On Wed, Apr 12, 2023 at 11:22:13AM +1000, Stephen Rothwell wrote:

>   select SND_HDA_COMPONENT if SND_HDA_CORE
>   # !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
> - select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 && 
> KERNEL_MODE_NEON && !CC_IS_CLANG))
> + select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 && 
> KERNEL_MODE_NEON && !CC_IS_CLANG))
>   help
> Choose this option if you want to use the new display engine
> support for AMDGPU. This adds required support for Vega and

> Please consider resolving this in a future -next update, I was rather
> surprised that my AMD test machine's graphical output was not working
> until I noticed the configuration difference :)

Done.


signature.asc
Description: PGP signature


Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling

2023-04-14 Thread Robert Richter
On 14.04.23 12:55:43, Jonathan Cameron wrote:
> On Fri, 14 Apr 2023 13:21:37 +0200
> Robert Richter  wrote:

> > The version I have ready after addressing Bjorn's comments is pretty
> > much the same, apart from error checking of the read/writes.
> > 
> > From your patch proposed you will need it in aer.c too and we do not
> > need to export it.
> 
> I think for the other components we'll want to call it from 
> cxl_pci_ras_unmask()
> so an export needed.
> 
> I also wonder if a more generic function would be better as seems likely
> similar code will be needed for errors other than this pair.

There are only a few masked by default, but not only internals. Will
consider that and also make it easy to export later once needed.

Thanks,

-Robert


Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.

2023-04-14 Thread Michal Suchánek
Hello,

On Fri, Apr 14, 2023 at 10:11:24PM +1000, Michael Ellerman wrote:
> Laurent Dufour  writes:
> > On 13/04/2023 15:37:59, Michael Ellerman wrote:
> >> Laurent Dufour  writes:
> >>> There is no SMT level recorded in the kernel neither in user space.
> >>> Indeed there is no real constraint about that and mixed SMT levels are
> >>> allowed and system is working fine this way.
> >>>
> >>> However when new CPU are added, the kernel is onlining all the threads
> >>> which is leading to mixed SMT levels and confuse end user a bit.
> >>>
> >>> To prevent this exports a SMT level from the kernel so user space
> >>> application like the energy daemon, could read it to adjust their 
> >>> settings.
> >>> There is no action unless recording the value when a SMT value is written
> >>> into the new sysfs entry. User space applications like ppc64_cpu should
> >>> update the sysfs when changing the SMT level to keep the system 
> >>> consistent.
> >>>
> >>> Suggested-by: Srikar Dronamraju 
> >>> Signed-off-by: Laurent Dufour 
> >>> ---
> >>>  arch/powerpc/platforms/pseries/pseries.h |  3 ++
> >>>  arch/powerpc/platforms/pseries/smp.c | 39 
> >>>  2 files changed, 42 insertions(+)
> >>
> >> There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
> >>
> >> I think we should be enabling that on powerpc and then adapting it to
> >> our needs, rather than adding a pseries specific file.
> >
> > Thanks Michael, I was not aware of this sysfs interface.
> >
> >> Currently the generic code is only aware of SMT on/off, so it would need
> >> to be taught about SMT4 and 8 at least.
> >
> > Do you think we should limit our support to SMT4 and SMT8 only?
> 
> Possibly? Currently the SMT state is represented by an enum:
> 
> enum cpuhp_smt_control {
>   CPU_SMT_ENABLED,
>   CPU_SMT_DISABLED,
>   CPU_SMT_FORCE_DISABLED,
>   CPU_SMT_NOT_SUPPORTED,
>   CPU_SMT_NOT_IMPLEMENTED,
> };
> 
> Adding two states for SMT4 and SMT8 seeems like it might be acceptable.
> 
> On the other hand if we want to support artbitrary SMT values from 3 to
> 8 then it might be better to store that value separately from the state
> enum.
> 
> TBH I'm not sure whether we want to support values other than 1/2/4/8
> via this interface.
> 
> A user who wants some odd numbered SMT value can always configure that
> manually using the existing tools.
> 
> But maybe it's less confusing if this interface supports all values?
> Even if they're unlikely to get much usage.

It looks like ppc64_cpu simply enables first n threads of the CPU where
n is the smt value without any interleaving hoping that the architecture
does the right thing. Under this implementation smt=3 is well-defined.

For the dual cluster P9 CPUs that have two clusters of four this might
work out well for some workloads, and others might want that
interleaving. With that the odd smt values are not well-definedd
anymore.

Nonetheless, if the kernel does support some smt=n parameter whatever
the semantic this should be also supported by the runtime knob.

If it's too difficult to get right there is always that option to not
enable any thread by default, and let the userspace to implement
arbitrarily complex schemes :)

Thanks

Michal


Re: [PATCH v3 5/6] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler

2023-04-14 Thread Robert Richter
On 14.04.23 13:19:50, Jonathan Cameron wrote:
> On Tue, 11 Apr 2023 13:03:01 -0500
> Terry Bowman  wrote:
> 
> > From: Robert Richter 
> > 
> > In Restricted CXL Device (RCD) mode a CXL device is exposed as an
> > RCiEP, but CXL downstream and upstream ports are not enumerated and
> > not visible in the PCIe hierarchy. Protocol and link errors are sent
> > to an RCEC.
> > 
> > Restricted CXL host (RCH) downstream port-detected errors are signaled
> > as internal AER errors, either Uncorrectable Internal Error (UIE) or
> > Corrected Internal Errors (CIE). The error source is the id of the
> > RCEC. A CXL handler must then inspect the error status in various CXL
> > registers residing in the dport's component register space (CXL RAS
> > cap) or the dport's RCRB (AER ext cap). [1]
> > 
> > Errors showing up in the RCEC's error handler must be handled and
> > connected to the CXL subsystem. Implement this by forwarding the error
> > to all CXL devices below the RCEC. Since the entire CXL device is
> > controlled only using PCIe Configuration Space of device 0, Function
> > 0, only pass it there [2]. These devices have the Memory Device class
> > code set (PCI_CLASS_MEMORY_CXL, 502h) and the existing cxl_pci driver
> > can implement the handler.
> 
> This comment implies only class code compliant drivers.  Sure we don't
> have drivers for anything else yet, but we should try to avoid saying
> there won't be any (which I think above implies).
> 
> You have a comment in the code, but maybe relaxing the description above
> to "currently support devices have..."

It is used here to identify CXL memory devices and limit the
enablement to those. The spec requires this to be set for CXL mem devs
(see cxl 3.0, 8.1.12.2).

There could be other CXL devices (e.g. cache), but other drivers are
not yet implemented. That is what I am referring to. The check makes
sure there is actually a driver with a handler for it (cxl_pci).

> 
> > In addition to errors directed to the CXL
> > endpoint device, the handler must also inspect the CXL downstream
> > port's CXL RAS and PCIe AER external capabilities that is connected to
> > the device.
> > 
> > Since CXL downstream port errors are signaled using internal errors,
> > the handler requires those errors to be unmasked. This is subject of a
> > follow-on patch.
> > 
> > The reason for choosing this implementation is that a CXL RCEC device
> > is bound to the AER port driver, but the driver does not allow it to
> > register a custom specific handler to support CXL. Connecting the RCEC
> > hard-wired with a CXL handler does not work, as the CXL subsystem
> > might not be present all the time. The alternative to add an
> > implementation to the portdrv to allow the registration of a custom
> > RCEC error handler isn't worth doing it as CXL would be its only user.
> > Instead, just check for an CXL RCEC and pass it down to the connected
> > CXL device's error handler. With this approach the code can entirely
> > be implemented in the PCIe AER driver and is independent of the CXL
> > subsystem. The CXL driver only provides the handler.
> > 
> > [1] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors
> > [2] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices
> > 
> > Co-developed-by: Terry Bowman 
> > Signed-off-by: Robert Richter 
> > Signed-off-by: Terry Bowman 
> > Cc: "Oliver O'Halloran" 
> > Cc: Bjorn Helgaas 
> > Cc: Mahesh J Salgaonkar 
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux-...@vger.kernel.org
> 
> Generally looks good to me.  A few trivial comments inline.
> 
> > ---
> >  drivers/pci/pcie/Kconfig |  8 ++
> >  drivers/pci/pcie/aer.c   | 61 
> >  2 files changed, 69 insertions(+)
> > 
> > diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
> > index 228652a59f27..b0dbd864d3a3 100644
> > --- a/drivers/pci/pcie/Kconfig
> > +++ b/drivers/pci/pcie/Kconfig
> > @@ -49,6 +49,14 @@ config PCIEAER_INJECT
> >   gotten from:
> >  
> > https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
> >  
> > +config PCIEAER_CXL
> > +   bool "PCI Express CXL RAS support"
> 
> Description makes this sound too general. I'd mentioned restricted
> hosts even in the menu option title.
> 
> 
> > +   default y
> > +   depends on PCIEAER && CXL_PCI
> > +   help
> > + This enables CXL error handling for Restricted CXL Hosts
> > + (RCHs).
> 
> Spec term is probably fine in the title, but in the help I'd 
> expand it as per the CXL 3.0 glossary to include
> "CXL Host that is operating in RCD mode."
> It might otherwise surprise people that this matters on their shiny
> new CXL X.0 host (because they found an old CXL 1.1 card in a box
> and decided to plug it in)
> 
> Do we actually need this protection at all?  It's a tiny amount of code
> and I can't see anything immediately that requires the CXL_PCI dependency
> other than it's a bit pointless if that isn't here.
> 
> > +
> >  #
> >  # PCI Express ECRC

Re: [PATCH] Revert "powerpc/rtas: Implement reentrant rtas call"

2023-04-14 Thread Michal Suchánek
Hello,

On Fri, Sep 16, 2022 at 04:56:18PM -0500, Nathan Lynch wrote:
> "Nicholas Piggin"  writes:
> > On Wed Sep 14, 2022 at 3:39 AM AEST, Leonardo Brás wrote:
> >> On Mon, 2022-09-12 at 14:58 -0500, Nathan Lynch wrote:
> >> > Leonardo Brás  writes:
> >> > > On Fri, 2022-09-09 at 09:04 -0500, Nathan Lynch wrote:

> >> > > > No, it means the premise of commit b664db8e3f97 ("powerpc/rtas:
> >> > > > Implement reentrant rtas call") change is incorrect. The "reentrant"
> >> > > > property described in the spec applies only to the individual RTAS
> >> > > > functions. The OS can invoke (for example) ibm,set-xive on multiple 
> >> > > > CPUs
> >> > > > simultaneously, but it must adhere to the more general requirement to
> >> > > > serialize with other RTAS functions.
> >> > > > 
> >> > > 
> >> > > I see. Thanks for explaining that part!
> >> > > I agree: reentrant calls that way don't look as useful on Linux than I
> >> > > previously thought.
> >> > > 
> >> > > OTOH, I think that instead of reverting the change, we could make use 
> >> > > of the
> >> > > correct information and fix the current implementation. (This could 
> >> > > help when we
> >> > > do the same rtas call in multiple cpus)
> >> > 
> >> > Hmm I'm happy to be mistaken here, but I doubt we ever really need to do
> >> > that. I'm not seeing the need.
> >> > 
> >> > > I have an idea of a patch to fix this. 
> >> > > Do you think it would be ok if I sent that, to prospect being an 
> >> > > alternative to
> >> > > this reversion?
> >> > 
> >> > It is my preference, and I believe it is more common, to revert to the
> >> > well-understood prior state, imperfect as it may be. The revert can be
> >> > backported to -stable and distros while development and review of
> >> > another approach proceeds.
> >>
> >> Ok then, as long as you are aware of the kdump bug, I'm good.
> >>
> >> FWIW:
> >> Reviewed-by: Leonardo Bras 
> >
> > A shame. I guess a reader/writer lock would not be much help because
> > the crash is probably more likely to hit longer running rtas calls?
> >
> > Alternative is just cheat and do this...?
> >
> > Thanks,
> > Nick
> >
> > diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> > index 693133972294..89728714a06e 100644
> > --- a/arch/powerpc/kernel/rtas.c
> > +++ b/arch/powerpc/kernel/rtas.c
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -97,6 +98,19 @@ static unsigned long lock_rtas(void)
> >  {
> > unsigned long flags;
> >  
> > +   if (atomic_read(_cpu) == raw_smp_processor_id()) {
> > +   /*
> > +* Crash in progress on this CPU. Other CPUs should be
> > +* stopped by now, so skip the lock in case it was being
> > +* held, and is now needed for crashing e.g., kexec
> > +* (machine_kexec_mask_interrupts) requires rtas calls.
> > +*
> > +* It's possible this could have caused rtas state
> > breakage
> > +* but the alternative is deadlock.
> > +*/
> > +   return 0;
> > +   }
> > +
> > local_irq_save(flags);
> > preempt_disable();
> > arch_spin_lock();
> > @@ -105,6 +119,9 @@ static unsigned long lock_rtas(void)
> >  
> >  static void unlock_rtas(unsigned long flags)
> >  {
> > +   if (atomic_read(_cpu) == raw_smp_processor_id())
> > +   return;
> > +
> > arch_spin_unlock();
> > local_irq_restore(flags);
> > preempt_enable();
> 
> Looks correct.
> 
> I wonder - would it be worth making the panic path use a separate
> "emergency" rtas_args buffer as well? If a CPU is actually "stuck" in
> RTAS at panic time, then leaving rtas.args untouched might make the
> ibm,int-off, ibm,set-xive, ibm,os-term, and any other RTAS calls we
> incur on the panic path more likely to succeed.

Was some fix for the case of crashing in rtas merged?

Looks like there is none unless I missed something.

The paramater area allocator might help with the latter
but the former does not seem addressed.

Thanks

Michal


Re: [PATCH v2 1/2] Remove POWER10_CPU dependency.

2023-04-14 Thread Danny Tsen

Thanks Michael.

-Danny

On 4/14/23 8:08 AM, Michael Ellerman wrote:

Danny Tsen  writes:

Remove Power10 dependency in Kconfig and detect Power10 feature at runtime.

... using the existing call to module_cpu_feature_match() :)


Signed-off-by: Danny Tsen 
---
  arch/powerpc/crypto/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Michael Ellerman  (powerpc)

cheers


diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig
index 1f8f02b494e1..7113f9355165 100644
--- a/arch/powerpc/crypto/Kconfig
+++ b/arch/powerpc/crypto/Kconfig
@@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE
  
  config CRYPTO_AES_GCM_P10

tristate "Stitched AES/GCM acceleration support on P10 or later CPU 
(PPC)"
-   depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN
+   depends on PPC64 && CPU_LITTLE_ENDIAN
select CRYPTO_LIB_AES
select CRYPTO_ALGAPI
select CRYPTO_AEAD
--
2.31.1


[PATCH 32/32] powerpc/configs: Make pseries_defconfig an alias for ppc64le_guest

2023-04-14 Thread Michael Ellerman
Rather than trying to keep multiple configs up to date, make
pseries_defconfig an alias for ppc64le_guest_defconfig.

NOTE, pseries_defconfig was a big endian config, but this commit
switches it to little endian.

Almost all distros are ppc64le these days, so little endian is much more
likely to be what a user wants when they build for "pseries".

For an actual big endian guest, use ppc64_guest_defconfig.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Makefile  |   3 +
 arch/powerpc/configs/pseries_defconfig | 323 -
 2 files changed, 3 insertions(+), 323 deletions(-)
 delete mode 100644 arch/powerpc/configs/pseries_defconfig

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 5b332d222ede..b7c44ebbf923 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -263,6 +263,9 @@ generated_configs += ppc64_guest_defconfig
 generated_configs += pseries_le_defconfig
 pseries_le_defconfig: ppc64le_guest_defconfig
 
+generated_configs += pseries_defconfig
+pseries_defconfig: ppc64le_guest_defconfig
+
 generated_configs += powernv_be_defconfig
 powernv_be_defconfig:
$(call merge_into_defconfig,powernv_defconfig,be)
diff --git a/arch/powerpc/configs/pseries_defconfig 
b/arch/powerpc/configs/pseries_defconfig
deleted file mode 100644
index 7497e17ea657..
--- a/arch/powerpc/configs/pseries_defconfig
+++ /dev/null
@@ -1,323 +0,0 @@
-CONFIG_PPC64=y
-CONFIG_NR_CPUS=2048
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_AUDIT=y
-# CONFIG_CONTEXT_TRACKING_USER_FORCE is not set
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
-CONFIG_TASKSTATS=y
-CONFIG_TASK_DELAY_ACCT=y
-CONFIG_TASK_XACCT=y
-CONFIG_TASK_IO_ACCOUNTING=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=18
-CONFIG_LOG_CPU_MAX_BUF_SHIFT=13
-CONFIG_NUMA_BALANCING=y
-CONFIG_CGROUPS=y
-CONFIG_MEMCG=y
-CONFIG_CGROUP_SCHED=y
-CONFIG_CGROUP_FREEZER=y
-CONFIG_CPUSETS=y
-CONFIG_CGROUP_DEVICE=y
-CONFIG_CGROUP_CPUACCT=y
-CONFIG_CGROUP_PERF=y
-CONFIG_CGROUP_BPF=y
-CONFIG_USER_NS=y
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_BPF_SYSCALL=y
-# CONFIG_COMPAT_BRK is not set
-CONFIG_PROFILING=y
-CONFIG_KPROBES=y
-CONFIG_JUMP_LABEL=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODVERSIONS=y
-CONFIG_MODULE_SRCVERSION_ALL=y
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_PPC_SPLPAR=y
-CONFIG_DTL=y
-CONFIG_PPC_SMLPAR=y
-CONFIG_IBMEBUS=y
-CONFIG_LIBNVDIMM=m
-CONFIG_PAPR_SCM=m
-CONFIG_PPC_SVM=y
-# CONFIG_PPC_PMAC is not set
-CONFIG_RTAS_FLASH=m
-CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
-CONFIG_HZ_100=y
-CONFIG_BINFMT_MISC=m
-CONFIG_PPC_TRANSACTIONAL_MEM=y
-CONFIG_KEXEC=y
-CONFIG_KEXEC_FILE=y
-CONFIG_IRQ_ALL_CPUS=y
-CONFIG_MEMORY_HOTPLUG=y
-CONFIG_MEMORY_HOTREMOVE=y
-CONFIG_KSM=y
-CONFIG_TRANSPARENT_HUGEPAGE=y
-CONFIG_SCHED_SMT=y
-CONFIG_HOTPLUG_PCI=y
-CONFIG_HOTPLUG_PCI_RPA=m
-CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_XFRM_USER=m
-CONFIG_NET_KEY=m
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_NET_IPIP=y
-CONFIG_SYN_COOKIES=y
-CONFIG_INET_AH=m
-CONFIG_INET_ESP=m
-CONFIG_INET_IPCOMP=m
-# CONFIG_IPV6 is not set
-CONFIG_NETFILTER=y
-# CONFIG_NETFILTER_ADVANCED is not set
-CONFIG_BRIDGE=m
-CONFIG_VLAN_8021Q=m
-CONFIG_NET_SCHED=y
-CONFIG_NET_CLS_BPF=m
-CONFIG_NET_CLS_ACT=y
-CONFIG_NET_ACT_BPF=m
-CONFIG_BPF_JIT=y
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_PARPORT=m
-CONFIG_PARPORT_PC=m
-CONFIG_BLK_DEV_FD=m
-CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_DEV_NBD=m
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=65536
-CONFIG_VIRTIO_BLK=m
-CONFIG_BLK_DEV_NVME=y
-CONFIG_BLK_DEV_SD=y
-CONFIG_CHR_DEV_ST=m
-CONFIG_BLK_DEV_SR=y
-CONFIG_CHR_DEV_SG=y
-CONFIG_SCSI_CONSTANTS=y
-CONFIG_SCSI_FC_ATTRS=y
-CONFIG_SCSI_CXGB3_ISCSI=m
-CONFIG_SCSI_CXGB4_ISCSI=m
-CONFIG_SCSI_BNX2_ISCSI=m
-CONFIG_BE2ISCSI=m
-CONFIG_SCSI_MPT2SAS=m
-CONFIG_SCSI_IBMVSCSI=y
-CONFIG_SCSI_IBMVFC=m
-CONFIG_SCSI_SYM53C8XX_2=m
-CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
-CONFIG_SCSI_IPR=y
-CONFIG_SCSI_QLA_FC=m
-CONFIG_SCSI_QLA_ISCSI=m
-CONFIG_SCSI_LPFC=m
-CONFIG_SCSI_VIRTIO=m
-CONFIG_SCSI_DH=y
-CONFIG_SCSI_DH_RDAC=m
-CONFIG_SCSI_DH_ALUA=m
-CONFIG_ATA=y
-CONFIG_SATA_AHCI=y
-CONFIG_PATA_AMD=y
-CONFIG_ATA_GENERIC=y
-CONFIG_MD=y
-CONFIG_BLK_DEV_MD=y
-CONFIG_MD_LINEAR=y
-CONFIG_MD_RAID0=y
-CONFIG_MD_RAID1=y
-CONFIG_MD_RAID10=m
-CONFIG_MD_RAID456=m
-CONFIG_MD_MULTIPATH=m
-CONFIG_MD_FAULTY=m
-CONFIG_BLK_DEV_DM=y
-CONFIG_DM_CRYPT=m
-CONFIG_DM_SNAPSHOT=m
-CONFIG_DM_THIN_PROVISIONING=m
-CONFIG_DM_MIRROR=m
-CONFIG_DM_ZERO=m
-CONFIG_DM_MULTIPATH=m
-CONFIG_DM_MULTIPATH_QL=m
-CONFIG_DM_MULTIPATH_ST=m
-CONFIG_DM_UEVENT=y
-CONFIG_BONDING=m
-CONFIG_DUMMY=m
-CONFIG_MACVLAN=m
-CONFIG_MACVTAP=m
-CONFIG_VXLAN=m
-CONFIG_NETCONSOLE=y
-CONFIG_TUN=m
-CONFIG_VETH=m
-CONFIG_VIRTIO_NET=m
-CONFIG_VORTEX=m
-CONFIG_ACENIC=m
-CONFIG_ACENIC_OMIT_TIGON_I=y
-CONFIG_PCNET32=m
-CONFIG_TIGON3=y
-CONFIG_BNX2X=m
-CONFIG_CHELSIO_T1=m
-CONFIG_BE2NET=m
-CONFIG_S2IO=m
-CONFIG_IBMVETH=y
-CONFIG_EHEA=y
-CONFIG_IBMVNIC=y

[PATCH 31/32] powerpc/configs: Make pseries_le an alias for ppc64le_guest

2023-04-14 Thread Michael Ellerman
Rather than trying to keep multiple configs up to date, make
pseries_le_defconfig an alias for ppc64le_guest_defconfig.

ppc64le_guest_defconfig should work in all cases that
pseries_le_defconfig currently does, but if not we can update it.

Move pseries_le_defconfig down in the Makefile, so it appears after
ppc64le_guest_defconfig in the help output.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Makefile | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 55c9b7968fbf..5b332d222ede 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -248,10 +248,6 @@ PHONY += bootwrapper_install
 
 include $(srctree)/scripts/Makefile.defconf
 
-generated_configs += pseries_le_defconfig
-pseries_le_defconfig:
-   $(call merge_into_defconfig,pseries_defconfig,le)
-
 generated_configs += ppc64le_defconfig
 ppc64le_defconfig:
$(call merge_into_defconfig,ppc64_defconfig,le)
@@ -264,6 +260,9 @@ generated_configs += ppc64_guest_defconfig
 ppc64_guest_defconfig:
$(call merge_into_defconfig,ppc64_defconfig,be guest kvm_guest)
 
+generated_configs += pseries_le_defconfig
+pseries_le_defconfig: ppc64le_guest_defconfig
+
 generated_configs += powernv_be_defconfig
 powernv_be_defconfig:
$(call merge_into_defconfig,powernv_defconfig,be)
-- 
2.39.2



[PATCH 30/32] powerpc/configs: Incorporate generic kvm_guest.config into guest configs

2023-04-14 Thread Michael Ellerman
Incorporate the generic kvm_guest.config into the powerpc guest configs,
ppc64[le]_guest_defconfig.

This brings in some useful options, in particular 9P support, and also
means future additions to the generic file will be automatically picked
up by the powerpc configs.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Makefile | 4 ++--
 arch/powerpc/configs/kvm_guest.config | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)
 create mode 12 arch/powerpc/configs/kvm_guest.config

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index e86a989d445c..55c9b7968fbf 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -258,11 +258,11 @@ generated_configs += ppc64le_defconfig
 
 generated_configs += ppc64le_guest_defconfig
 ppc64le_guest_defconfig:
-   $(call merge_into_defconfig,ppc64_defconfig,le guest)
+   $(call merge_into_defconfig,ppc64_defconfig,le guest kvm_guest)
 
 generated_configs += ppc64_guest_defconfig
 ppc64_guest_defconfig:
-   $(call merge_into_defconfig,ppc64_defconfig,be guest)
+   $(call merge_into_defconfig,ppc64_defconfig,be guest kvm_guest)
 
 generated_configs += powernv_be_defconfig
 powernv_be_defconfig:
diff --git a/arch/powerpc/configs/kvm_guest.config 
b/arch/powerpc/configs/kvm_guest.config
new file mode 12
index ..a5f7a2fa74ef
--- /dev/null
+++ b/arch/powerpc/configs/kvm_guest.config
@@ -0,0 +1 @@
+../../../kernel/configs/kvm_guest.config
\ No newline at end of file
-- 
2.39.2



[PATCH 29/32] powerpc/configs: Add IBMVETH=y and IBMVNIC=y to guest configs

2023-04-14 Thread Michael Ellerman
These drivers are sometimes required to have functional networking in a
guest, so build them in when building ppc64[le]_guest_defconfig.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/guest.config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/configs/guest.config 
b/arch/powerpc/configs/guest.config
index 209f58515d88..fece83487215 100644
--- a/arch/powerpc/configs/guest.config
+++ b/arch/powerpc/configs/guest.config
@@ -10,3 +10,5 @@ CONFIG_EPAPR_PARAVIRT=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VHOST_NET=y
 CONFIG_VHOST=y
+CONFIG_IBMVETH=y
+CONFIG_IBMVNIC=y
-- 
2.39.2



[PATCH 22/32] powerpc/configs/64s: Enable IO_STRICT_DEVMEM

2023-04-14 Thread Michael Ellerman
Distros enable it.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 2cee399d3abc..4c347f6be401 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -416,6 +416,7 @@ CONFIG_STACK_TRACER=y
 CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_BLK_DEV_IO_TRACE=y
+CONFIG_IO_STRICT_DEVMEM=y
 CONFIG_PPC_EMULATED_STATS=y
 CONFIG_CODE_PATCHING_SELFTEST=y
 CONFIG_FTR_FIXUP_SELFTEST=y
-- 
2.39.2



[PATCH 28/32] powerpc/configs/64s: Enable Device Mapper options

2023-04-14 Thread Michael Ellerman
Add device mapper options for test coverage and in case folks are
booting systems that require them.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 037219dda19f..a17cb31105e3 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -167,18 +167,30 @@ CONFIG_BLK_DEV_MD=y
 CONFIG_MD_LINEAR=y
 CONFIG_MD_RAID0=y
 CONFIG_MD_RAID1=y
-CONFIG_MD_RAID10=m
-CONFIG_MD_RAID456=m
 CONFIG_MD_MULTIPATH=m
 CONFIG_MD_FAULTY=m
 CONFIG_BLK_DEV_DM=y
+CONFIG_DM_UNSTRIPED=m
 CONFIG_DM_CRYPT=m
 CONFIG_DM_SNAPSHOT=m
+CONFIG_DM_THIN_PROVISIONING=m
+CONFIG_DM_CACHE=m
+CONFIG_DM_WRITECACHE=m
+CONFIG_DM_EBS=m
+CONFIG_DM_ERA=m
+CONFIG_DM_CLONE=m
 CONFIG_DM_MIRROR=m
+CONFIG_DM_LOG_USERSPACE=m
+CONFIG_DM_RAID=m
 CONFIG_DM_ZERO=m
 CONFIG_DM_MULTIPATH=m
 CONFIG_DM_MULTIPATH_QL=m
 CONFIG_DM_MULTIPATH_ST=m
+CONFIG_DM_MULTIPATH_HST=m
+CONFIG_DM_MULTIPATH_IOA=m
+CONFIG_DM_DELAY=m
+CONFIG_DM_DUST=m
+CONFIG_DM_INIT=y
 CONFIG_DM_UEVENT=y
 CONFIG_ADB_PMU=y
 CONFIG_PMAC_SMU=y
-- 
2.39.2



[PATCH 27/32] powerpc/configs/64s: Enable PSTORE

2023-04-14 Thread Michael Ellerman
Like pseries & powernv_defconfig, enable PSTORE.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 833847b775ec..037219dda19f 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -341,6 +341,7 @@ CONFIG_SQUASHFS=m
 CONFIG_SQUASHFS_XATTR=y
 CONFIG_SQUASHFS_LZO=y
 CONFIG_SQUASHFS_XZ=y
+CONFIG_PSTORE=y
 CONFIG_NFS_FS=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
-- 
2.39.2



[PATCH 26/32] powerpc/configs/64s: Enable VLAN support

2023-04-14 Thread Michael Ellerman
Most other configs, and distros enable it.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index b88155ddab65..833847b775ec 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -111,6 +111,7 @@ CONFIG_INET_IPCOMP=m
 CONFIG_NETFILTER=y
 # CONFIG_NETFILTER_ADVANCED is not set
 CONFIG_BRIDGE=m
+CONFIG_VLAN_8021Q=m
 CONFIG_NET_SCHED=y
 CONFIG_NET_CLS_BPF=m
 CONFIG_NET_CLS_ACT=y
-- 
2.39.2



[PATCH 25/32] powerpc/configs/64s: Enable BLK_DEV_NVME

2023-04-14 Thread Michael Ellerman
Copy powernv_defconfig and enable BLK_DEV_NVME.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 12d49f3e56b7..b88155ddab65 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -129,6 +129,7 @@ CONFIG_BLK_DEV_NBD=m
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=65536
 CONFIG_VIRTIO_BLK=m
+CONFIG_BLK_DEV_NVME=m
 CONFIG_BLK_DEV_SD=y
 CONFIG_CHR_DEV_ST=m
 CONFIG_BLK_DEV_SR=y
-- 
2.39.2



[PATCH 24/32] powerpc/configs/64s: Drop REISERFS

2023-04-14 Thread Michael Ellerman
No reason to use this anymore.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index b7c6cd72a0ce..12d49f3e56b7 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -312,10 +312,6 @@ CONFIG_EXT2_FS_SECURITY=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
 CONFIG_EXT4_FS_SECURITY=y
-CONFIG_REISERFS_FS=m
-CONFIG_REISERFS_FS_XATTR=y
-CONFIG_REISERFS_FS_POSIX_ACL=y
-CONFIG_REISERFS_FS_SECURITY=y
 CONFIG_JFS_FS=m
 CONFIG_JFS_POSIX_ACL=y
 CONFIG_JFS_SECURITY=y
-- 
2.39.2



[PATCH 23/32] powerpc/configs/64s: Use SHA512 for module signatures

2023-04-14 Thread Michael Ellerman
Modern distros use SHA512 for module signing.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 4c347f6be401..b7c6cd72a0ce 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -77,6 +77,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
+CONFIG_MODULE_SIG_SHA512=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_BINFMT_MISC=m
 CONFIG_ZSWAP=y
-- 
2.39.2



[PATCH 16/32] powerpc/configs/64s: Enable YAMA, LANDLOCK & BPF LSMs

2023-04-14 Thread Michael Ellerman
Multiple distros enable these.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 0aafe64cd1d7..8673277f9b20 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -6,6 +6,7 @@ CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BPF_SYSCALL=y
 CONFIG_BPF_JIT=y
+CONFIG_BPF_LSM=y
 CONFIG_PREEMPT_VOLUNTARY=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_BSD_PROCESS_ACCT_V3=y
@@ -357,8 +358,10 @@ CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_UTF8=y
 CONFIG_SECURITY=y
+CONFIG_SECURITY_YAMA=y
 CONFIG_SECURITY_LOCKDOWN_LSM=y
 CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
+CONFIG_SECURITY_LANDLOCK=y
 CONFIG_INTEGRITY_SIGNATURE=y
 CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
 CONFIG_INTEGRITY_PLATFORM_KEYRING=y
-- 
2.39.2



[PATCH 21/32] powerpc/configs/64s: Enable SCHEDSTATS

2023-04-14 Thread Michael Ellerman
Distros enable it.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 3154f307bba6..2cee399d3abc 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -407,6 +407,7 @@ CONFIG_DEBUG_VM=y
 CONFIG_DEBUG_STACKOVERFLOW=y
 CONFIG_SOFTLOCKUP_DETECTOR=y
 CONFIG_HARDLOCKUP_DETECTOR=y
+CONFIG_SCHEDSTATS=y
 CONFIG_DEBUG_MUTEXES=y
 CONFIG_FUNCTION_TRACER=y
 CONFIG_LOCK_TORTURE_TEST=m
-- 
2.39.2



[PATCH 20/32] powerpc/configs/64s: Enable DEBUG_VM & other options

2023-04-14 Thread Michael Ellerman
Fedora enables DEBUG_VM, which has led to occasions where a VM_BUG_ON()
is not caught by upstream testing, but rather is first found in Fedora,
which is not how it's meant to be.

PAGE_OWNER & PAGE_POISONING both need to be enabled on the kernel
command line, so should not add much overhead in normal operation.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index c8b49e33fd81..3154f307bba6 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -397,14 +397,20 @@ CONFIG_PRINTK_TIME=y
 CONFIG_PRINTK_CALLER=y
 CONFIG_DEBUG_KERNEL=y
 CONFIG_MAGIC_SYSRQ=y
+CONFIG_PAGE_OWNER=y
+CONFIG_PAGE_POISONING=y
 CONFIG_DEBUG_RODATA_TEST=y
+CONFIG_DEBUG_WX=y
 CONFIG_DEBUG_STACK_USAGE=y
+CONFIG_DEBUG_VM=y
+# CONFIG_DEBUG_VM_PGTABLE is not set
 CONFIG_DEBUG_STACKOVERFLOW=y
 CONFIG_SOFTLOCKUP_DETECTOR=y
 CONFIG_HARDLOCKUP_DETECTOR=y
 CONFIG_DEBUG_MUTEXES=y
 CONFIG_FUNCTION_TRACER=y
 CONFIG_LOCK_TORTURE_TEST=m
+CONFIG_BUG_ON_DATA_CORRUPTION=y
 CONFIG_STACK_TRACER=y
 CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
-- 
2.39.2



[PATCH 14/32] powerpc/configs/64s: Enable ZSWAP & ZRAM

2023-04-14 Thread Michael Ellerman
Most distros enable these. In particular Fedore uses zram in the default
install.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 07a92f02e1f8..59b9d8eb1c7b 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -78,6 +78,9 @@ CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_BINFMT_MISC=m
+CONFIG_ZSWAP=y
+CONFIG_Z3FOLD=y
+CONFIG_ZSMALLOC=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_MEMORY_HOTPLUG=y
 CONFIG_MEMORY_HOTREMOVE=y
@@ -114,6 +117,7 @@ CONFIG_ELECTRA_CF=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_BLK_DEV_FD=y
+CONFIG_ZRAM=m
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_NBD=m
 CONFIG_BLK_DEV_RAM=y
-- 
2.39.2



[PATCH 19/32] powerpc/configs/64s: Enable EMULATED_STATS

2023-04-14 Thread Michael Ellerman
This is enabled in some of the other powerpc configs, and can be useful
for debugging, so enable it in ppc64[le]_defconfig.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 8d4231fd878a..c8b49e33fd81 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -409,6 +409,7 @@ CONFIG_STACK_TRACER=y
 CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_BLK_DEV_IO_TRACE=y
+CONFIG_PPC_EMULATED_STATS=y
 CONFIG_CODE_PATCHING_SELFTEST=y
 CONFIG_FTR_FIXUP_SELFTEST=y
 CONFIG_MSI_BITMAP_SELFTEST=y
-- 
2.39.2



[PATCH 18/32] powerpc/configs/64s: Enable KUNIT and most tests

2023-04-14 Thread Michael Ellerman
All built as modules, so the tests only happen when the modules are
loaded, not affecting normal boot time.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 43 
 1 file changed, 43 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 946307c54afa..8d4231fd878a 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -397,12 +397,14 @@ CONFIG_PRINTK_TIME=y
 CONFIG_PRINTK_CALLER=y
 CONFIG_DEBUG_KERNEL=y
 CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_RODATA_TEST=y
 CONFIG_DEBUG_STACK_USAGE=y
 CONFIG_DEBUG_STACKOVERFLOW=y
 CONFIG_SOFTLOCKUP_DETECTOR=y
 CONFIG_HARDLOCKUP_DETECTOR=y
 CONFIG_DEBUG_MUTEXES=y
 CONFIG_FUNCTION_TRACER=y
+CONFIG_LOCK_TORTURE_TEST=m
 CONFIG_STACK_TRACER=y
 CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
@@ -412,3 +414,44 @@ CONFIG_FTR_FIXUP_SELFTEST=y
 CONFIG_MSI_BITMAP_SELFTEST=y
 CONFIG_XMON=y
 CONFIG_BOOTX_TEXT=y
+CONFIG_KUNIT=m
+CONFIG_KUNIT_ALL_TESTS=m
+CONFIG_LKDTM=m
+CONFIG_TEST_MIN_HEAP=m
+CONFIG_TEST_DIV64=m
+CONFIG_BACKTRACE_SELF_TEST=m
+CONFIG_TEST_REF_TRACKER=m
+CONFIG_RBTREE_TEST=m
+CONFIG_REED_SOLOMON_TEST=m
+CONFIG_INTERVAL_TREE_TEST=m
+CONFIG_PERCPU_TEST=m
+CONFIG_ATOMIC64_SELFTEST=m
+CONFIG_ASYNC_RAID6_TEST=m
+CONFIG_TEST_HEXDUMP=m
+CONFIG_STRING_SELFTEST=m
+CONFIG_TEST_STRING_HELPERS=m
+CONFIG_TEST_KSTRTOX=m
+CONFIG_TEST_PRINTF=m
+CONFIG_TEST_SCANF=m
+CONFIG_TEST_BITMAP=m
+CONFIG_TEST_UUID=m
+CONFIG_TEST_XARRAY=m
+CONFIG_TEST_MAPLE_TREE=m
+CONFIG_TEST_RHASHTABLE=m
+CONFIG_TEST_IDA=m
+CONFIG_TEST_BITOPS=m
+CONFIG_TEST_VMALLOC=m
+CONFIG_TEST_USER_COPY=m
+CONFIG_TEST_BPF=m
+CONFIG_TEST_BLACKHOLE_DEV=m
+CONFIG_FIND_BIT_BENCHMARK=m
+CONFIG_TEST_FIRMWARE=m
+CONFIG_TEST_SYSCTL=m
+CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_TEST_UDELAY=m
+CONFIG_TEST_STATIC_KEYS=m
+CONFIG_TEST_KMOD=m
+CONFIG_TEST_MEMCAT_P=m
+CONFIG_TEST_MEMINIT=m
+CONFIG_TEST_FREE_PAGES=m
+CONFIG_MEMTEST=y
-- 
2.39.2



[PATCH 17/32] powerpc/configs/64s: Enable SELINUX

2023-04-14 Thread Michael Ellerman
Fedora, CentOS, RHEL & SUSE all enable it.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 8673277f9b20..946307c54afa 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -358,6 +358,9 @@ CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_UTF8=y
 CONFIG_SECURITY=y
+CONFIG_SECURITY_NETWORK=y
+CONFIG_SECURITY_SELINUX=y
+CONFIG_SECURITY_SELINUX_BOOTPARAM=y
 CONFIG_SECURITY_YAMA=y
 CONFIG_SECURITY_LOCKDOWN_LSM=y
 CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
-- 
2.39.2



[PATCH 15/32] powerpc/configs/64s: Enable SLAB hardening options

2023-04-14 Thread Michael Ellerman
Fedora & CentOS enable these.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 59b9d8eb1c7b..0aafe64cd1d7 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -81,6 +81,10 @@ CONFIG_BINFMT_MISC=m
 CONFIG_ZSWAP=y
 CONFIG_Z3FOLD=y
 CONFIG_ZSMALLOC=y
+# CONFIG_SLAB_MERGE_DEFAULT is not set
+CONFIG_SLAB_FREELIST_RANDOM=y
+CONFIG_SLAB_FREELIST_HARDENED=y
+CONFIG_SHUFFLE_PAGE_ALLOCATOR=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_MEMORY_HOTPLUG=y
 CONFIG_MEMORY_HOTREMOVE=y
-- 
2.39.2



[PATCH 13/32] powerpc/configs/64s: Enable CHECKPOINT_RESTORE

2023-04-14 Thread Michael Ellerman
Most distros enable this.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index e853905c4e7e..07a92f02e1f8 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -32,6 +32,7 @@ CONFIG_CGROUP_PERF=y
 CONFIG_CGROUP_BPF=y
 CONFIG_CGROUP_MISC=y
 CONFIG_USER_NS=y
+CONFIG_CHECKPOINT_RESTORE=y
 CONFIG_SCHED_AUTOGROUP=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_PROFILING=y
-- 
2.39.2



[PATCH 12/32] powerpc/configs/64s: Enable common CGROUP & related options

2023-04-14 Thread Michael Ellerman
Distros enable these options.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 7e265cbbeaef..e853905c4e7e 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -19,15 +19,20 @@ CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=18
 CONFIG_LOG_CPU_MAX_BUF_SHIFT=13
 CONFIG_NUMA_BALANCING=y
-CONFIG_CGROUPS=y
 CONFIG_MEMCG=y
-CONFIG_CGROUP_SCHED=y
+CONFIG_BLK_CGROUP=y
+CONFIG_CFS_BANDWIDTH=y
+CONFIG_CGROUP_PIDS=y
 CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_HUGETLB=y
 CONFIG_CPUSETS=y
 CONFIG_CGROUP_DEVICE=y
 CONFIG_CGROUP_CPUACCT=y
 CONFIG_CGROUP_PERF=y
 CONFIG_CGROUP_BPF=y
+CONFIG_CGROUP_MISC=y
+CONFIG_USER_NS=y
+CONFIG_SCHED_AUTOGROUP=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_PROFILING=y
 CONFIG_PPC64=y
-- 
2.39.2



[PATCH 11/32] powerpc/configs/64s: Enable NO_HZ_FULL

2023-04-14 Thread Michael Ellerman
At least Fedora & SUSE enable it.

VIRT_CPU_ACCOUNTING_GEN is selected so no longer needs to be in the
defconfig.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index ecad254eee6c..7e265cbbeaef 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -1,13 +1,12 @@
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
-# CONFIG_CONTEXT_TRACKING_USER_FORCE is not set
 CONFIG_AUDIT=y
+CONFIG_NO_HZ_FULL=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BPF_SYSCALL=y
 CONFIG_BPF_JIT=y
 CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_BSD_PROCESS_ACCT_V3=y
 CONFIG_TASKSTATS=y
-- 
2.39.2



[PATCH 10/32] powerpc/configs/64s: Enable common accounting options

2023-04-14 Thread Michael Ellerman
These options are enabled by most distros.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 0e3b420aaa6e..ecad254eee6c 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -8,8 +8,13 @@ CONFIG_BPF_SYSCALL=y
 CONFIG_BPF_JIT=y
 CONFIG_PREEMPT_VOLUNTARY=y
 CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
 CONFIG_TASKSTATS=y
 CONFIG_TASK_DELAY_ACCT=y
+CONFIG_TASK_XACCT=y
+CONFIG_TASK_IO_ACCOUNTING=y
+CONFIG_PSI=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=18
-- 
2.39.2



[PATCH 09/32] powerpc/configs/64s: Enable AUDIT

2023-04-14 Thread Michael Ellerman
Essentially all distros enable it.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index b332b05a668f..0e3b420aaa6e 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -1,6 +1,7 @@
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
 # CONFIG_CONTEXT_TRACKING_USER_FORCE is not set
+CONFIG_AUDIT=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BPF_SYSCALL=y
-- 
2.39.2



[PATCH 08/32] powerpc/configs/64s: Enable PREEMPT_VOLUNTARY

2023-04-14 Thread Michael Ellerman
Traditionally on powerpc servers PREEMPT_NONE was used, but these days
multiple distros are building with PREEMPT_VOLUNTARY - Ubuntu, Fedora &
CentOS all enable it.

So update the upstream config to reflect that, and get test coverage
before code hits the distros.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index f185adc128db..b332b05a668f 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -5,6 +5,7 @@ CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BPF_SYSCALL=y
 CONFIG_BPF_JIT=y
+CONFIG_PREEMPT_VOLUNTARY=y
 CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
 CONFIG_TASKSTATS=y
 CONFIG_TASK_DELAY_ACCT=y
-- 
2.39.2



[PATCH 07/32] powerpc/configs/64s: Select ARCH_WANT_DEFAULT_BPF_JIT

2023-04-14 Thread Michael Ellerman
Tell the generic BPF code that the JIT should be enabled by default,
rather than the interpreter. Most distros use CONFIG_BPF_JIT_ALWAYS_ON=y
anyway, so this just updates upstream to more closely match that.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9fed732807fa..f8179e17325b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -164,6 +164,7 @@ config PPC
select ARCH_USE_CMPXCHG_LOCKREF if PPC64
select ARCH_USE_MEMTEST
select ARCH_USE_QUEUED_RWLOCKS  if PPC_QUEUED_SPINLOCKS
+   select ARCH_WANT_DEFAULT_BPF_JIT
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
-- 
2.39.2



[PATCH 06/32] powerpc/configs/64s: Add secure boot options to defconfig

2023-04-14 Thread Michael Ellerman
Add the numerous options required to get secure boot enabled.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index d98fe52a5892..f185adc128db 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -54,6 +54,7 @@ CONFIG_CRASH_DUMP=y
 CONFIG_FA_DUMP=y
 CONFIG_IRQ_ALL_CPUS=y
 CONFIG_SCHED_SMT=y
+CONFIG_PPC_SECURE_BOOT=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
@@ -335,13 +336,25 @@ CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_UTF8=y
+CONFIG_SECURITY=y
+CONFIG_SECURITY_LOCKDOWN_LSM=y
+CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
+CONFIG_INTEGRITY_SIGNATURE=y
+CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
+CONFIG_INTEGRITY_PLATFORM_KEYRING=y
+CONFIG_IMA=y
+CONFIG_IMA_KEXEC=y
+CONFIG_IMA_DEFAULT_HASH_SHA256=y
+CONFIG_IMA_WRITE_POLICY=y
+CONFIG_IMA_APPRAISE=y
+CONFIG_IMA_ARCH_POLICY=y
+CONFIG_IMA_APPRAISE_MODSIG=y
 CONFIG_CRYPTO_TEST=m
 CONFIG_CRYPTO_BLOWFISH=m
 CONFIG_CRYPTO_CAST6=m
 CONFIG_CRYPTO_SERPENT=m
 CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_PCBC=m
-CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_SHA256=y
 CONFIG_CRYPTO_WP512=m
@@ -352,6 +365,8 @@ CONFIG_CRYPTO_SHA1_PPC=m
 CONFIG_CRYPTO_DEV_NX=y
 CONFIG_CRYPTO_DEV_NX_ENCRYPT=m
 CONFIG_CRYPTO_DEV_VMX=y
+CONFIG_SYSTEM_TRUSTED_KEYRING=y
+CONFIG_SYSTEM_BLACKLIST_KEYRING=y
 CONFIG_PRINTK_TIME=y
 CONFIG_PRINTK_CALLER=y
 CONFIG_DEBUG_KERNEL=y
-- 
2.39.2



[PATCH 03/32] powerpc/configs/64s: Drop IPV6 which is default y

2023-04-14 Thread Michael Ellerman
Since commit de551f2eb22a ("net: Build IPv6 into kernel by default"),
IPV6 is default y.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 0a3a2fefb652..c4f3ce96d924 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -84,7 +84,6 @@ CONFIG_SYN_COOKIES=y
 CONFIG_INET_AH=m
 CONFIG_INET_ESP=m
 CONFIG_INET_IPCOMP=m
-CONFIG_IPV6=y
 CONFIG_NETFILTER=y
 # CONFIG_NETFILTER_ADVANCED is not set
 CONFIG_BRIDGE=m
-- 
2.39.2



[PATCH 05/32] powerpc/configs/64s: Enable PAPR_SCM

2023-04-14 Thread Michael Ellerman
This is a powerpc specific driver so add the symbols required to enable
it so it gets some build/boot test coverage.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 74477f89c108..d98fe52a5892 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -29,6 +29,7 @@ CONFIG_NR_CPUS=2048
 CONFIG_DTL=y
 CONFIG_PPC_SMLPAR=y
 CONFIG_IBMEBUS=y
+CONFIG_PAPR_SCM=m
 CONFIG_PPC_SVM=y
 CONFIG_PPC_MAPLE=y
 CONFIG_PPC_PASEMI=y
@@ -69,6 +70,7 @@ CONFIG_MEMORY_HOTPLUG=y
 CONFIG_MEMORY_HOTREMOVE=y
 CONFIG_KSM=y
 CONFIG_TRANSPARENT_HUGEPAGE=y
+CONFIG_ZONE_DEVICE=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
-- 
2.39.2



[PATCH 04/32] powerpc/configs/6s: Drop obsolete crypto ALGs

2023-04-14 Thread Michael Ellerman
These algorithms were marked obsolete in commit 1674aea5f080 ("crypto:
Kconfig - mark unused ciphers as obsolete").

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index c4f3ce96d924..74477f89c108 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -343,9 +343,6 @@ CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_SHA256=y
 CONFIG_CRYPTO_WP512=m
-CONFIG_CRYPTO_ANUBIS=m
-CONFIG_CRYPTO_KHAZAD=m
-CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_LZO=m
 CONFIG_CRYPTO_CRC32C_VPMSUM=m
 CONFIG_CRYPTO_MD5_PPC=m
-- 
2.39.2



[PATCH 01/32] powerpc/configs/64s: Update defconfig for symbol movement

2023-04-14 Thread Michael Ellerman
Update ppc64_defconfig to account for symbols moving around, no actual
changes.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 42 ++--
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index d6949a6c5b2b..1028b90ce121 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -3,6 +3,8 @@ CONFIG_POSIX_MQUEUE=y
 # CONFIG_CONTEXT_TRACKING_USER_FORCE is not set
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BPF_SYSCALL=y
+CONFIG_BPF_JIT=y
 CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
 CONFIG_TASKSTATS=y
 CONFIG_TASK_DELAY_ACCT=y
@@ -21,8 +23,6 @@ CONFIG_CGROUP_CPUACCT=y
 CONFIG_CGROUP_PERF=y
 CONFIG_CGROUP_BPF=y
 CONFIG_BLK_DEV_INITRD=y
-CONFIG_BPF_SYSCALL=y
-# CONFIG_COMPAT_BRK is not set
 CONFIG_PROFILING=y
 CONFIG_PPC64=y
 CONFIG_NR_CPUS=2048
@@ -54,15 +54,9 @@ CONFIG_CRASH_DUMP=y
 CONFIG_FA_DUMP=y
 CONFIG_IRQ_ALL_CPUS=y
 CONFIG_SCHED_SMT=y
-CONFIG_HOTPLUG_PCI=y
-CONFIG_HOTPLUG_PCI_RPA=m
-CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
-CONFIG_PCCARD=y
-CONFIG_ELECTRA_CF=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
-CONFIG_VHOST_NET=m
 CONFIG_KPROBES=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
@@ -71,6 +65,7 @@ CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_BINFMT_MISC=m
+# CONFIG_COMPAT_BRK is not set
 CONFIG_MEMORY_HOTPLUG=y
 CONFIG_MEMORY_HOTREMOVE=y
 CONFIG_KSM=y
@@ -98,7 +93,11 @@ CONFIG_NET_SCHED=y
 CONFIG_NET_CLS_BPF=m
 CONFIG_NET_CLS_ACT=y
 CONFIG_NET_ACT_BPF=m
-CONFIG_BPF_JIT=y
+CONFIG_HOTPLUG_PCI=y
+CONFIG_HOTPLUG_PCI_RPA=m
+CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
+CONFIG_PCCARD=y
+CONFIG_ELECTRA_CF=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_BLK_DEV_FD=y
@@ -267,9 +266,9 @@ CONFIG_LEDS_POWERNV=m
 CONFIG_INFINIBAND=m
 CONFIG_INFINIBAND_USER_MAD=m
 CONFIG_INFINIBAND_USER_ACCESS=m
-CONFIG_INFINIBAND_MTHCA=m
 CONFIG_INFINIBAND_CXGB4=m
 CONFIG_MLX4_INFINIBAND=m
+CONFIG_INFINIBAND_MTHCA=m
 CONFIG_INFINIBAND_IPOIB=m
 CONFIG_INFINIBAND_IPOIB_CM=y
 CONFIG_INFINIBAND_SRP=m
@@ -280,8 +279,9 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_DS1307=y
 CONFIG_VIRTIO_PCI=m
 CONFIG_VIRTIO_BALLOON=m
-CONFIG_LIBNVDIMM=y
+CONFIG_VHOST_NET=m
 CONFIG_RAS=y
+CONFIG_LIBNVDIMM=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y
@@ -336,38 +336,38 @@ CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_UTF8=y
 CONFIG_CRYPTO_TEST=m
+CONFIG_CRYPTO_BLOWFISH=m
+CONFIG_CRYPTO_CAST6=m
+CONFIG_CRYPTO_SERPENT=m
+CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_HMAC=y
-CONFIG_CRYPTO_CRC32C_VPMSUM=m
-CONFIG_CRYPTO_MD5_PPC=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
-CONFIG_CRYPTO_SHA1_PPC=m
 CONFIG_CRYPTO_SHA256=y
 CONFIG_CRYPTO_WP512=m
 CONFIG_CRYPTO_ANUBIS=m
-CONFIG_CRYPTO_BLOWFISH=m
-CONFIG_CRYPTO_CAST6=m
 CONFIG_CRYPTO_KHAZAD=m
-CONFIG_CRYPTO_SERPENT=m
 CONFIG_CRYPTO_TEA=m
-CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_LZO=m
+CONFIG_CRYPTO_CRC32C_VPMSUM=m
+CONFIG_CRYPTO_MD5_PPC=m
+CONFIG_CRYPTO_SHA1_PPC=m
 CONFIG_CRYPTO_DEV_NX=y
 CONFIG_CRYPTO_DEV_NX_ENCRYPT=m
 CONFIG_CRYPTO_DEV_VMX=y
 CONFIG_PRINTK_TIME=y
 CONFIG_PRINTK_CALLER=y
-CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_KERNEL=y
+CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_STACK_USAGE=y
 CONFIG_DEBUG_STACKOVERFLOW=y
 CONFIG_SOFTLOCKUP_DETECTOR=y
 CONFIG_HARDLOCKUP_DETECTOR=y
 CONFIG_DEBUG_MUTEXES=y
 CONFIG_FUNCTION_TRACER=y
-CONFIG_FTRACE_SYSCALLS=y
-CONFIG_SCHED_TRACER=y
 CONFIG_STACK_TRACER=y
+CONFIG_SCHED_TRACER=y
+CONFIG_FTRACE_SYSCALLS=y
 CONFIG_BLK_DEV_IO_TRACE=y
 CONFIG_CODE_PATCHING_SELFTEST=y
 CONFIG_FTR_FIXUP_SELFTEST=y
-- 
2.39.2



[PATCH 02/32] powerpc/configs/64s: Drop SPLPAR which is default y

2023-04-14 Thread Michael Ellerman
SPLPAR is default y since commit 20c0e8269e9d ("powerpc/pseries:
Implement paravirt qspinlocks for SPLPAR"), so doesn't need to be in the
defconfig.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/configs/ppc64_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 1028b90ce121..0a3a2fefb652 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -26,7 +26,6 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_PROFILING=y
 CONFIG_PPC64=y
 CONFIG_NR_CPUS=2048
-CONFIG_PPC_SPLPAR=y
 CONFIG_DTL=y
 CONFIG_PPC_SMLPAR=y
 CONFIG_IBMEBUS=y
-- 
2.39.2



Re: [PATCH v2 2/2] Move Power10 feature, PPC_MODULE_FEATURE_P10.

2023-04-14 Thread Michael Ellerman
Danny Tsen  writes:
> Move Power10 feature, PPC_MODULE_FEATURE_P10, definition to be in
> arch/powerpc/include/asm/cpufeature.h.
>
> Signed-off-by: Danny Tsen 
> ---
>  arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 -
>  arch/powerpc/include/asm/cpufeature.h  | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)

Acked-by: Michael Ellerman  (powerpc)

cheers

> diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c 
> b/arch/powerpc/crypto/aes-gcm-p10-glue.c
> index 1533c8cdd26f..bd3475f5348d 100644
> --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c
> +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c
> @@ -22,7 +22,6 @@
>  #include 
>  #include 
>  
> -#define PPC_MODULE_FEATURE_P10   (32 + ilog2(PPC_FEATURE2_ARCH_3_1))
>  #define  PPC_ALIGN   16
>  #define GCM_IV_SIZE  12
>  
> diff --git a/arch/powerpc/include/asm/cpufeature.h 
> b/arch/powerpc/include/asm/cpufeature.h
> index f6f790a90367..2dcc66225e7f 100644
> --- a/arch/powerpc/include/asm/cpufeature.h
> +++ b/arch/powerpc/include/asm/cpufeature.h
> @@ -22,6 +22,7 @@
>   */
>  
>  #define PPC_MODULE_FEATURE_VEC_CRYPTO(32 + 
> ilog2(PPC_FEATURE2_VEC_CRYPTO))
> +#define PPC_MODULE_FEATURE_P10   (32 + 
> ilog2(PPC_FEATURE2_ARCH_3_1))
>  
>  #define cpu_feature(x)   (x)
>  
> -- 
> 2.31.1


Re: [PATCH v2 1/2] Remove POWER10_CPU dependency.

2023-04-14 Thread Michael Ellerman
Danny Tsen  writes:
> Remove Power10 dependency in Kconfig and detect Power10 feature at runtime.

... using the existing call to module_cpu_feature_match() :)

> Signed-off-by: Danny Tsen 
> ---
>  arch/powerpc/crypto/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Michael Ellerman  (powerpc)

cheers

> diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig
> index 1f8f02b494e1..7113f9355165 100644
> --- a/arch/powerpc/crypto/Kconfig
> +++ b/arch/powerpc/crypto/Kconfig
> @@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE
>  
>  config CRYPTO_AES_GCM_P10
>   tristate "Stitched AES/GCM acceleration support on P10 or later CPU 
> (PPC)"
> - depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN
> + depends on PPC64 && CPU_LITTLE_ENDIAN
>   select CRYPTO_LIB_AES
>   select CRYPTO_ALGAPI
>   select CRYPTO_AEAD
> -- 
> 2.31.1


Re: [PATCH v3 5/6] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler

2023-04-14 Thread Jonathan Cameron
On Tue, 11 Apr 2023 13:03:01 -0500
Terry Bowman  wrote:

> From: Robert Richter 
> 
> In Restricted CXL Device (RCD) mode a CXL device is exposed as an
> RCiEP, but CXL downstream and upstream ports are not enumerated and
> not visible in the PCIe hierarchy. Protocol and link errors are sent
> to an RCEC.
> 
> Restricted CXL host (RCH) downstream port-detected errors are signaled
> as internal AER errors, either Uncorrectable Internal Error (UIE) or
> Corrected Internal Errors (CIE). The error source is the id of the
> RCEC. A CXL handler must then inspect the error status in various CXL
> registers residing in the dport's component register space (CXL RAS
> cap) or the dport's RCRB (AER ext cap). [1]
> 
> Errors showing up in the RCEC's error handler must be handled and
> connected to the CXL subsystem. Implement this by forwarding the error
> to all CXL devices below the RCEC. Since the entire CXL device is
> controlled only using PCIe Configuration Space of device 0, Function
> 0, only pass it there [2]. These devices have the Memory Device class
> code set (PCI_CLASS_MEMORY_CXL, 502h) and the existing cxl_pci driver
> can implement the handler.

This comment implies only class code compliant drivers.  Sure we don't
have drivers for anything else yet, but we should try to avoid saying
there won't be any (which I think above implies).

You have a comment in the code, but maybe relaxing the description above
to "currently support devices have..."

> In addition to errors directed to the CXL
> endpoint device, the handler must also inspect the CXL downstream
> port's CXL RAS and PCIe AER external capabilities that is connected to
> the device.
> 
> Since CXL downstream port errors are signaled using internal errors,
> the handler requires those errors to be unmasked. This is subject of a
> follow-on patch.
> 
> The reason for choosing this implementation is that a CXL RCEC device
> is bound to the AER port driver, but the driver does not allow it to
> register a custom specific handler to support CXL. Connecting the RCEC
> hard-wired with a CXL handler does not work, as the CXL subsystem
> might not be present all the time. The alternative to add an
> implementation to the portdrv to allow the registration of a custom
> RCEC error handler isn't worth doing it as CXL would be its only user.
> Instead, just check for an CXL RCEC and pass it down to the connected
> CXL device's error handler. With this approach the code can entirely
> be implemented in the PCIe AER driver and is independent of the CXL
> subsystem. The CXL driver only provides the handler.
> 
> [1] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors
> [2] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices
> 
> Co-developed-by: Terry Bowman 
> Signed-off-by: Robert Richter 
> Signed-off-by: Terry Bowman 
> Cc: "Oliver O'Halloran" 
> Cc: Bjorn Helgaas 
> Cc: Mahesh J Salgaonkar 
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org

Generally looks good to me.  A few trivial comments inline.

> ---
>  drivers/pci/pcie/Kconfig |  8 ++
>  drivers/pci/pcie/aer.c   | 61 
>  2 files changed, 69 insertions(+)
> 
> diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
> index 228652a59f27..b0dbd864d3a3 100644
> --- a/drivers/pci/pcie/Kconfig
> +++ b/drivers/pci/pcie/Kconfig
> @@ -49,6 +49,14 @@ config PCIEAER_INJECT
> gotten from:
>
> https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
>  
> +config PCIEAER_CXL
> + bool "PCI Express CXL RAS support"

Description makes this sound too general. I'd mentioned restricted
hosts even in the menu option title.


> + default y
> + depends on PCIEAER && CXL_PCI
> + help
> +   This enables CXL error handling for Restricted CXL Hosts
> +   (RCHs).

Spec term is probably fine in the title, but in the help I'd 
expand it as per the CXL 3.0 glossary to include
"CXL Host that is operating in RCD mode."
It might otherwise surprise people that this matters on their shiny
new CXL X.0 host (because they found an old CXL 1.1 card in a box
and decided to plug it in)

Do we actually need this protection at all?  It's a tiny amount of code
and I can't see anything immediately that requires the CXL_PCI dependency
other than it's a bit pointless if that isn't here.

> +
>  #
>  # PCI Express ECRC
>  #
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 7a25b62d9e01..171a08fd8ebd 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -946,6 +946,65 @@ static bool find_source_device(struct pci_dev *parent,
>   return true;
>  }
>  
> +#ifdef CONFIG_PCIEAER_CXL
> +
> +static bool is_cxl_mem_dev(struct pci_dev *dev)
> +{
> + /*
> +  * A CXL device is controlled only using PCIe Configuration
> +  * Space of device 0, Function 0.

That's not true in general.   Definitely true that CXL protocol
error reporting is controlled only using this Devfn, 

Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.

2023-04-14 Thread Michael Ellerman
Laurent Dufour  writes:
> On 13/04/2023 15:37:59, Michael Ellerman wrote:
>> Laurent Dufour  writes:
>>> There is no SMT level recorded in the kernel neither in user space.
>>> Indeed there is no real constraint about that and mixed SMT levels are
>>> allowed and system is working fine this way.
>>>
>>> However when new CPU are added, the kernel is onlining all the threads
>>> which is leading to mixed SMT levels and confuse end user a bit.
>>>
>>> To prevent this exports a SMT level from the kernel so user space
>>> application like the energy daemon, could read it to adjust their settings.
>>> There is no action unless recording the value when a SMT value is written
>>> into the new sysfs entry. User space applications like ppc64_cpu should
>>> update the sysfs when changing the SMT level to keep the system consistent.
>>>
>>> Suggested-by: Srikar Dronamraju 
>>> Signed-off-by: Laurent Dufour 
>>> ---
>>>  arch/powerpc/platforms/pseries/pseries.h |  3 ++
>>>  arch/powerpc/platforms/pseries/smp.c | 39 
>>>  2 files changed, 42 insertions(+)
>>
>> There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
>>
>> I think we should be enabling that on powerpc and then adapting it to
>> our needs, rather than adding a pseries specific file.
>
> Thanks Michael, I was not aware of this sysfs interface.
>
>> Currently the generic code is only aware of SMT on/off, so it would need
>> to be taught about SMT4 and 8 at least.
>
> Do you think we should limit our support to SMT4 and SMT8 only?

Possibly? Currently the SMT state is represented by an enum:

enum cpuhp_smt_control {
CPU_SMT_ENABLED,
CPU_SMT_DISABLED,
CPU_SMT_FORCE_DISABLED,
CPU_SMT_NOT_SUPPORTED,
CPU_SMT_NOT_IMPLEMENTED,
};

Adding two states for SMT4 and SMT8 seeems like it might be acceptable.

On the other hand if we want to support artbitrary SMT values from 3 to
8 then it might be better to store that value separately from the state
enum.

TBH I'm not sure whether we want to support values other than 1/2/4/8
via this interface.

A user who wants some odd numbered SMT value can always configure that
manually using the existing tools.

But maybe it's less confusing if this interface supports all values?
Even if they're unlikely to get much usage.

>> There are already hooks in the generic code to check the SMT level when
>> bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries
>> hotplug case too, though maybe we need some additional logic.
>>
>> Wiring up the basic support is pretty straight forward, something like
>> the diff below.
>
> I'll look into how to wire this up.
> Thanks a lot!

Thanks.

cheers


Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling

2023-04-14 Thread Robert Richter
On 13.04.23 18:05:08, Jonathan Cameron wrote:
> On Thu, 13 Apr 2023 15:38:07 +0200
> Robert Richter  wrote:
> 
> > On 12.04.23 16:29:01, Bjorn Helgaas wrote:
> > > On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:  

> > > With the exception of this function, this patch looks like all CXL
> > > code that maybe could be with other CXL code.  Would require making
> > > pcie_walk_rcec() available outside drivers/pci, I guess.  
> > 
> > Even this is CXL code, it implements AER support and fits better here
> > around AER code. Export of pcie_walk_rcec() (and others?) is not the
> > main issue here. CXL drivers can come as modules and would need to
> > register a hook at the aer handler.  This would add even more
> > complexity here. In contrast, current solution just adds two functions
> > for enablement and handling which are empty stubs if code is disabled.
> > 
> > I could move that code to aer_cxl.c similar to aer_inject.c. Since the
> > CXL part is small compared to the remaining aer code I left it in
> > aer.c. Also, it is guarded by #ifdef which additionally encapsulates
> > it.
> > 
> 
> To throw another option in there (what Bjorn suggested IIRC for the more
> general case..) 
> 
> Just enable internal errors always.  No need to know if they are CXL
> or something else.
> 
> There will/might be fallout and it will be fun.

I left the fun part to others. :-)

If some PCI root port goes crazy it tears down the whole system, would
avoid that.

Since internal error are implementation specific, I would only enable
them once a handler exists. What's why enablement is limited to CXL
RCECs only.

-Robert


Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling

2023-04-14 Thread Jonathan Cameron
On Fri, 14 Apr 2023 13:21:37 +0200
Robert Richter  wrote:

> On 13.04.23 15:52:36, Ira Weiny wrote:
> > Jonathan Cameron wrote:  
> > > On Wed, 12 Apr 2023 16:29:01 -0500
> > > Bjorn Helgaas  wrote:
> > >   
> > > > On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:  
> > > > > From: Robert Richter 
> > > > >   
> 
> > > > > +static int __cxl_unmask_internal_errors(struct pci_dev *rcec)
> > > > > +{
> > > > > + int aer, rc;
> > > > > + u32 mask;
> > > > > +
> > > > > + /*
> > > > > +  * Internal errors are masked by default, unmask RCEC's here
> > > > > +  * PCI6.0 7.8.4.3 Uncorrectable Error Mask Register (Offset 08h)
> > > > > +  * PCI6.0 7.8.4.6 Correctable Error Mask Register (Offset 14h)
> > > > > +  */
> > > > 
> > > > Unmasking internal errors doesn't have anything specific to do with
> > > > CXL, so I don't think it should have "cxl" in the function name.
> > > > Maybe something like "pci_aer_unmask_internal_errors()".  
> > > 
> > > This reminds me.  Not sure we resolved earlier discussion on changing
> > > the system wide policy to turn these on 
> > > https://lore.kernel.org/linux-cxl/20221229172731.GA611562@bhelgaas/
> > > which needs pretty much the same thing.
> > > 
> > > Ira, I think you were picking this one up?
> > > https://lore.kernel.org/linux-cxl/63e5fb533f304_13244829412@iweiny-mobl.notmuch/
> > >   
> > 
> > After this discussion I posted an RFC to enable those errors.
> > 
> > https://lore.kernel.org/all/20230209-cxl-pci-aer-v1-1-f9a817fa4...@intel.com/
> > 

Ah. I'd forgotten that thread. Thanks!

> > Unfortunately the prevailing opinion was that this was unsafe.  And no one
> > piped up with a reason to pursue the alternative of a pci core call to 
> > enable
> > them as needed.
> > 
> > So I abandoned the work.
> > 
> > I think the direction things where headed was to have a call like:
> > 
> > int pci_enable_pci_internal_errors(struct pci_dev *dev)
> > {
> > int pos_cap_err;
> > u32 reg;
> > 
> > if (!pcie_aer_is_native(dev))
> > return -EIO;
> > 
> > pos_cap_err = dev->aer_cap;
> > 
> > /* Unmask correctable and uncorrectable (non-fatal) internal errors */
> > pci_read_config_dword(dev, pos_cap_err + PCI_ERR_COR_MASK, );
> > reg &= ~PCI_ERR_COR_INTERNAL;
> > pci_write_config_dword(dev, pos_cap_err + PCI_ERR_COR_MASK, reg);
> > 
> > pci_read_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_SEVER, );
> > reg &= ~PCI_ERR_UNC_INTN;
> > pci_write_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_SEVER, reg);
> > 
> > pci_read_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_MASK, );
> > reg &= ~PCI_ERR_UNC_INTN;
> > pci_write_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_MASK, reg);
> > 
> > return 0;
> > }
> > 
> > ... and call this from the cxl code where it is needed.  
> 
> The version I have ready after addressing Bjorn's comments is pretty
> much the same, apart from error checking of the read/writes.
> 
> From your patch proposed you will need it in aer.c too and we do not
> need to export it.

I think for the other components we'll want to call it from cxl_pci_ras_unmask()
so an export needed.

I also wonder if a more generic function would be better as seems likely
similar code will be needed for errors other than this pair.


> 
> This patch only enables it for (CXL) RCECs. You might want to extend
> this for CXL endpoints (and ports?) then.

Definitely.  We have the same limitation you are seeing.  No errors
without turning this on.

Jonathan



> 
> > 
> > Is this an acceptable direction?  Terry is welcome to steal the above from 
> > my
> > patch and throw it into the PCI core.
> > 
> > Looking at the current state of things I think cxl_pci_ras_unmask() may
> > actually be broken now without calling something like the above.  For that I
> > dropped the ball.  
> 
> Thanks,
> 
> -Robert
> 
> > 
> > Ira  



Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling

2023-04-14 Thread Robert Richter
On 13.04.23 15:52:36, Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Wed, 12 Apr 2023 16:29:01 -0500
> > Bjorn Helgaas  wrote:
> > 
> > > On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:
> > > > From: Robert Richter 
> > > > 

> > > > +static int __cxl_unmask_internal_errors(struct pci_dev *rcec)
> > > > +{
> > > > +   int aer, rc;
> > > > +   u32 mask;
> > > > +
> > > > +   /*
> > > > +* Internal errors are masked by default, unmask RCEC's here
> > > > +* PCI6.0 7.8.4.3 Uncorrectable Error Mask Register (Offset 08h)
> > > > +* PCI6.0 7.8.4.6 Correctable Error Mask Register (Offset 14h)
> > > > +*/  
> > > 
> > > Unmasking internal errors doesn't have anything specific to do with
> > > CXL, so I don't think it should have "cxl" in the function name.
> > > Maybe something like "pci_aer_unmask_internal_errors()".
> > 
> > This reminds me.  Not sure we resolved earlier discussion on changing
> > the system wide policy to turn these on 
> > https://lore.kernel.org/linux-cxl/20221229172731.GA611562@bhelgaas/
> > which needs pretty much the same thing.
> > 
> > Ira, I think you were picking this one up?
> > https://lore.kernel.org/linux-cxl/63e5fb533f304_13244829412@iweiny-mobl.notmuch/
> 
> After this discussion I posted an RFC to enable those errors.
> 
> https://lore.kernel.org/all/20230209-cxl-pci-aer-v1-1-f9a817fa4...@intel.com/
> 
> Unfortunately the prevailing opinion was that this was unsafe.  And no one
> piped up with a reason to pursue the alternative of a pci core call to enable
> them as needed.
> 
> So I abandoned the work.
> 
> I think the direction things where headed was to have a call like:
> 
> int pci_enable_pci_internal_errors(struct pci_dev *dev)
> {
>   int pos_cap_err;
>   u32 reg;
> 
>   if (!pcie_aer_is_native(dev))
>   return -EIO;
> 
>   pos_cap_err = dev->aer_cap;
> 
>   /* Unmask correctable and uncorrectable (non-fatal) internal errors */
>   pci_read_config_dword(dev, pos_cap_err + PCI_ERR_COR_MASK, );
>   reg &= ~PCI_ERR_COR_INTERNAL;
>   pci_write_config_dword(dev, pos_cap_err + PCI_ERR_COR_MASK, reg);
>   
>   pci_read_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_SEVER, );
>   reg &= ~PCI_ERR_UNC_INTN;
>   pci_write_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_SEVER, reg);
>   
>   pci_read_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_MASK, );
>   reg &= ~PCI_ERR_UNC_INTN;
>   pci_write_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_MASK, reg);
> 
>   return 0;
> }
> 
> ... and call this from the cxl code where it is needed.

The version I have ready after addressing Bjorn's comments is pretty
much the same, apart from error checking of the read/writes.

>From your patch proposed you will need it in aer.c too and we do not
need to export it.

This patch only enables it for (CXL) RCECs. You might want to extend
this for CXL endpoints (and ports?) then.

> 
> Is this an acceptable direction?  Terry is welcome to steal the above from my
> patch and throw it into the PCI core.
> 
> Looking at the current state of things I think cxl_pci_ras_unmask() may
> actually be broken now without calling something like the above.  For that I
> dropped the ball.

Thanks,

-Robert

> 
> Ira