* Re: remove the nvlink2 pci_vfio subdriver v2
From: Greg Kurz @ 2021-05-04 12:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Daniel Vetter, kvm, David Airlie, linux-kernel, dri-devel,
qemu-devel, Alex Williamson, Paul Mackerras, Jason Gunthorpe,
Greg Kroah-Hartman, qemu-ppc, linux-api, linuxppc-dev
In-Reply-To: <20210326061311.1497642-1-hch@lst.de>
On Fri, 26 Mar 2021 07:13:09 +0100
Christoph Hellwig <hch@lst.de> wrote:
> Hi all,
>
> the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> feature without any open source component - what would normally be
> the normal open source userspace that we require for kernel drivers,
> although in this particular case user space could of course be a
> kernel driver in a VM. It also happens to be a complete mess that
> does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> and also pulles in over 1000 lines of code always build into powerpc
> kernels that have Power NV support enabled. Because of all these
> issues and the lack of breaking userspace when it is removed I think
> the best idea is to simply kill.
>
> Changes since v1:
> - document the removed subtypes as reserved
> - add the ACK from Greg
>
> Diffstat:
> arch/powerpc/platforms/powernv/npu-dma.c | 705 ---------------------------
> b/arch/powerpc/include/asm/opal.h | 3
> b/arch/powerpc/include/asm/pci-bridge.h | 1
> b/arch/powerpc/include/asm/pci.h | 7
> b/arch/powerpc/platforms/powernv/Makefile | 2
> b/arch/powerpc/platforms/powernv/opal-call.c | 2
> b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 -------
> b/arch/powerpc/platforms/powernv/pci.c | 11
> b/arch/powerpc/platforms/powernv/pci.h | 17
> b/arch/powerpc/platforms/pseries/pci.c | 23
> b/drivers/vfio/pci/Kconfig | 6
> b/drivers/vfio/pci/Makefile | 1
> b/drivers/vfio/pci/vfio_pci.c | 18
> b/drivers/vfio/pci/vfio_pci_private.h | 14
> b/include/uapi/linux/vfio.h | 38 -
Hi Christoph,
FYI, these uapi changes break build of QEMU.
I guess QEMU people should take some action before this percolates
to the QEMU source tree.
Cc'ing relevant QEMU lists to bring the discussion there.
Cheers,
--
Greg
> drivers/vfio/pci/vfio_pci_nvlink2.c | 490 ------------------
> 16 files changed, 12 insertions(+), 1511 deletions(-)
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/dlpar: use rtas_get_sensor()
From: Laurent Dufour @ 2021-05-04 12:42 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld
In-Reply-To: <20210504025329.1713878-1-nathanl@linux.ibm.com>
Le 04/05/2021 à 04:53, Nathan Lynch a écrit :
> Instead of making bare calls to get-sensor-state, use
> rtas_get_sensor(), which correctly handles busy and extended delay
> statuses.
Reviewed-by: Laurent Dufour <ldufour@linux.ibm.com>
> Fixes: ab519a011caa ("powerpc/pseries: Kernel DLPAR Infrastructure")
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/dlpar.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
> index 3ac70790ec7a..b1f01ac0c29e 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -289,8 +289,7 @@ int dlpar_acquire_drc(u32 drc_index)
> {
> int dr_status, rc;
>
> - rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
> - DR_ENTITY_SENSE, drc_index);
> + rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, &dr_status);
> if (rc || dr_status != DR_ENTITY_UNUSABLE)
> return -1;
>
> @@ -311,8 +310,7 @@ int dlpar_release_drc(u32 drc_index)
> {
> int dr_status, rc;
>
> - rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
> - DR_ENTITY_SENSE, drc_index);
> + rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, &dr_status);
> if (rc || dr_status != DR_ENTITY_PRESENT)
> return -1;
>
> @@ -333,8 +331,7 @@ int dlpar_unisolate_drc(u32 drc_index)
> {
> int dr_status, rc;
>
> - rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
> - DR_ENTITY_SENSE, drc_index);
> + rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, &dr_status);
> if (rc || dr_status != DR_ENTITY_PRESENT)
> return -1;
>
>
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Greg Kroah-Hartman @ 2021-05-04 12:59 UTC (permalink / raw)
To: Greg Kurz
Cc: Daniel Vetter, kvm, David Airlie, linux-kernel, dri-devel,
qemu-devel, Alex Williamson, Paul Mackerras, Jason Gunthorpe,
linux-api, qemu-ppc, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20210504142236.76994047@bahia.lan>
On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> On Fri, 26 Mar 2021 07:13:09 +0100
> Christoph Hellwig <hch@lst.de> wrote:
>
> > Hi all,
> >
> > the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> > feature without any open source component - what would normally be
> > the normal open source userspace that we require for kernel drivers,
> > although in this particular case user space could of course be a
> > kernel driver in a VM. It also happens to be a complete mess that
> > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > and also pulles in over 1000 lines of code always build into powerpc
> > kernels that have Power NV support enabled. Because of all these
> > issues and the lack of breaking userspace when it is removed I think
> > the best idea is to simply kill.
> >
> > Changes since v1:
> > - document the removed subtypes as reserved
> > - add the ACK from Greg
> >
> > Diffstat:
> > arch/powerpc/platforms/powernv/npu-dma.c | 705 ---------------------------
> > b/arch/powerpc/include/asm/opal.h | 3
> > b/arch/powerpc/include/asm/pci-bridge.h | 1
> > b/arch/powerpc/include/asm/pci.h | 7
> > b/arch/powerpc/platforms/powernv/Makefile | 2
> > b/arch/powerpc/platforms/powernv/opal-call.c | 2
> > b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 -------
> > b/arch/powerpc/platforms/powernv/pci.c | 11
> > b/arch/powerpc/platforms/powernv/pci.h | 17
> > b/arch/powerpc/platforms/pseries/pci.c | 23
> > b/drivers/vfio/pci/Kconfig | 6
> > b/drivers/vfio/pci/Makefile | 1
> > b/drivers/vfio/pci/vfio_pci.c | 18
> > b/drivers/vfio/pci/vfio_pci_private.h | 14
> > b/include/uapi/linux/vfio.h | 38 -
>
>
> Hi Christoph,
>
> FYI, these uapi changes break build of QEMU.
What uapi changes?
What exactly breaks?
Why does QEMU require kernel driver stuff?
thanks,
greg k-h
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Christoph Hellwig @ 2021-05-04 13:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: qemu-devel, Daniel Vetter, kvm, David Airlie, Greg Kurz,
dri-devel, linux-kernel, Alex Williamson, Paul Mackerras,
Jason Gunthorpe, linux-api, qemu-ppc, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <YJFFG1tSP0dUCxcX@kroah.com>
On Tue, May 04, 2021 at 02:59:07PM +0200, Greg Kroah-Hartman wrote:
> > Hi Christoph,
> >
> > FYI, these uapi changes break build of QEMU.
>
> What uapi changes?
>
> What exactly breaks?
>
> Why does QEMU require kernel driver stuff?
Looks like it pull in the uapi struct definitions unconditionally
instead of having a local copy. We could fix that by just putting
them back, but to me this seems like a rather broken configuration
in qemu when it pulls in headers from the running/installed kernel
without any feature checks before using them.
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Cornelia Huck @ 2021-05-04 13:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jason Gunthorpe, kvm, David Airlie, Greg Kroah-Hartman,
qemu-devel, dri-devel, Greg Kurz, Alex Williamson, Paul Mackerras,
Daniel Vetter, qemu-ppc, linux-api, linuxppc-dev, linux-kernel
In-Reply-To: <20210504130039.GA7711@lst.de>
On Tue, 4 May 2021 15:00:39 +0200
Christoph Hellwig <hch@lst.de> wrote:
> On Tue, May 04, 2021 at 02:59:07PM +0200, Greg Kroah-Hartman wrote:
> > > Hi Christoph,
> > >
> > > FYI, these uapi changes break build of QEMU.
> >
> > What uapi changes?
> >
> > What exactly breaks?
> >
> > Why does QEMU require kernel driver stuff?
>
> Looks like it pull in the uapi struct definitions unconditionally
> instead of having a local copy. We could fix that by just putting
> them back, but to me this seems like a rather broken configuration
> in qemu when it pulls in headers from the running/installed kernel
> without any feature checks before using them.
>
It is not pulling them from the installed kernel, but from a
development version to get new definitions. Removing things in the
kernel requires workarounds in QEMU until it can remove those things as
well. It is not a dumb update...
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Andy Shevchenko @ 2021-05-04 13:18 UTC (permalink / raw)
To: Christophe Leroy
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Documentation List,
Linux Kernel Mailing List,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT, Will Deacon,
Palmer Dabbelt, Paul Walmsley, Miguel Ojeda, Paul Mackerras,
linux-riscv, Linus Torvalds, linux-arm Mailing List
In-Reply-To: <8b5f1d57-1357-affd-565f-f4826f3ecbdf@csgroup.eu>
On Mon, May 3, 2021 at 9:17 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 01/05/2021 à 17:15, Masahiro Yamada a écrit :
> > The current minimum GCC version is 4.9 except ARCH=arm64 requiring
> > GCC 5.1.
> >
> > When we discussed last time, we agreed to raise the minimum GCC version
> > to 5.1 globally. [1]
> >
> > I'd like to propose GCC 5.2 to clean up arch/powerpc/Kconfig as well.
>
> One point I missed when I saw your patch first time, but I realised during the discussion:
>
> Up to 4.9, GCC was numbered with 3 digits, we had 4.8.0, 4.8.1, ... 4.8.5, 4.9.0, 4.9.1, .... 4.9.4
>
> Then starting at 5, GCC switched to a 2 digits scheme, with 5.0, 5.1, 5.2, ... 5.5
>
> So, that is not GCC 5.1 or 5.2 that you should target, but only GCC 5.
> Then it is up to the user to use the latest available version of GCC 5, which is 5.5 at the time
> begin, just like the user would have selected 4.9.4 when 4.9 was the minimum GCC version.
And we may end up in the case when gcc 5.x will be more buggy than
v4.9.y (as once proved by nice detective story where compiler bug
produces a file system corruption).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Andy Shevchenko @ 2021-05-04 13:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Albert Ou, Catalin Marinas, Linux Kbuild mailing list,
Greg Kroah-Hartman, Masahiro Yamada, Jonathan Corbet,
Linux Doc Mailing List, linux-kernel, Matthew Wilcox,
Miguel Ojeda, Will Deacon, Palmer Dabbelt, Paul Walmsley,
Joe Perches, Paul Mackerras, linux-riscv, Miguel Ojeda,
Linus Torvalds, Linux ARM, linuxppc-dev
In-Reply-To: <CAK8P3a0kV4ZfMEFh0DcMDjXqxA0yhj8a8CL-YFGV6B4pszHeGg@mail.gmail.com>
On Mon, May 3, 2021 at 12:29 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, May 3, 2021 at 9:35 AM Alexander Dahl <ada@thorsis.com> wrote:
> >
> > Desktops and servers are all nice, however I just want to make you
> > aware, there are embedded users forced to stick to older cross
> > toolchains for different reasons as well, e.g. in industrial
> > environment. :-)
> >
> > This is no show stopper for us, I just wanted to let you be aware.
>
> Can you be more specific about what scenarios you are thinking of,
> what the motivations are for using an old compiler with a new kernel
> on embedded systems, and what you think a realistic maximum
> time would be between compiler updates?
>
> One scenario that I've seen previously is where user space and
> kernel are built together as a source based distribution (OE, buildroot,
> openwrt, ...), and the compiler is picked to match the original sources
> of the user space because that is best tested, but the same compiler
> then gets used to build the kernel as well because that is the default
> in the build environment.
>
> There are two problems I see with this logic:
>
> - Running the latest kernel to avoid security problems is of course
> a good idea, but if one runs that with ten year old user space that
> is never updated, the system is likely to end up just as insecure.
> Not all bugs are in the kernel.
>
> - The same logic that applies to ancient user space staying with
> an ancient compiler (it's better tested in this combination) also
> applies to the kernel: running the latest kernel on an old compiler
> is something that few people test, and tends to run into more bugs
> than using the compiler that other developers used to test that
> kernel.
I understand that you are talking about embedded, but it you stuck
with a distro (esp. LTS one, like CentOS 7.x), you have gcc 4.8.5
there for everything, but they have got security updates. Seems if you
are with a distro you have to stick with its kernel with all pros and
cons of such an approach.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Greg Kroah-Hartman @ 2021-05-04 13:30 UTC (permalink / raw)
To: Greg Kurz
Cc: Daniel Vetter, kvm, David Airlie, linux-kernel, dri-devel,
qemu-devel, Alex Williamson, Paul Mackerras, Jason Gunthorpe,
linux-api, qemu-ppc, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20210504152034.18e41ec3@bahia.lan>
On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> On Tue, 4 May 2021 14:59:07 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > > Hi all,
> > > >
> > > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> > > > feature without any open source component - what would normally be
> > > > the normal open source userspace that we require for kernel drivers,
> > > > although in this particular case user space could of course be a
> > > > kernel driver in a VM. It also happens to be a complete mess that
> > > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > > and also pulles in over 1000 lines of code always build into powerpc
> > > > kernels that have Power NV support enabled. Because of all these
> > > > issues and the lack of breaking userspace when it is removed I think
> > > > the best idea is to simply kill.
> > > >
> > > > Changes since v1:
> > > > - document the removed subtypes as reserved
> > > > - add the ACK from Greg
> > > >
> > > > Diffstat:
> > > > arch/powerpc/platforms/powernv/npu-dma.c | 705 ---------------------------
> > > > b/arch/powerpc/include/asm/opal.h | 3
> > > > b/arch/powerpc/include/asm/pci-bridge.h | 1
> > > > b/arch/powerpc/include/asm/pci.h | 7
> > > > b/arch/powerpc/platforms/powernv/Makefile | 2
> > > > b/arch/powerpc/platforms/powernv/opal-call.c | 2
> > > > b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 -------
> > > > b/arch/powerpc/platforms/powernv/pci.c | 11
> > > > b/arch/powerpc/platforms/powernv/pci.h | 17
> > > > b/arch/powerpc/platforms/pseries/pci.c | 23
> > > > b/drivers/vfio/pci/Kconfig | 6
> > > > b/drivers/vfio/pci/Makefile | 1
> > > > b/drivers/vfio/pci/vfio_pci.c | 18
> > > > b/drivers/vfio/pci/vfio_pci_private.h | 14
> > > > b/include/uapi/linux/vfio.h | 38 -
> > >
> > >
> > > Hi Christoph,
> > >
> > > FYI, these uapi changes break build of QEMU.
> >
> > What uapi changes?
> >
>
> All macros and structure definitions that are being removed
> from include/uapi/linux/vfio.h by patch 1.
>
> > What exactly breaks?
> >
>
> These macros and types are used by the current QEMU code base.
> Next time the QEMU source tree updates its copy of the kernel
> headers, the compilation of affected code will fail.
So does QEMU use this api that is being removed, or does it just have
some odd build artifacts of the uapi things?
What exactly is the error messages here?
And if we put the uapi .h file stuff back, is that sufficient for qemu
to work, as it should be checking at runtime what the kernel has / has
not anyway, right?
thanks,
greg k-h
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Greg Kurz @ 2021-05-04 13:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Daniel Vetter, kvm, David Airlie, linux-kernel, dri-devel,
qemu-devel, Alex Williamson, Paul Mackerras, Jason Gunthorpe,
linux-api, qemu-ppc, linuxppc-dev, Christoph Hellwig
In-Reply-To: <YJFFG1tSP0dUCxcX@kroah.com>
On Tue, 4 May 2021 14:59:07 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > On Fri, 26 Mar 2021 07:13:09 +0100
> > Christoph Hellwig <hch@lst.de> wrote:
> >
> > > Hi all,
> > >
> > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> > > feature without any open source component - what would normally be
> > > the normal open source userspace that we require for kernel drivers,
> > > although in this particular case user space could of course be a
> > > kernel driver in a VM. It also happens to be a complete mess that
> > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > and also pulles in over 1000 lines of code always build into powerpc
> > > kernels that have Power NV support enabled. Because of all these
> > > issues and the lack of breaking userspace when it is removed I think
> > > the best idea is to simply kill.
> > >
> > > Changes since v1:
> > > - document the removed subtypes as reserved
> > > - add the ACK from Greg
> > >
> > > Diffstat:
> > > arch/powerpc/platforms/powernv/npu-dma.c | 705 ---------------------------
> > > b/arch/powerpc/include/asm/opal.h | 3
> > > b/arch/powerpc/include/asm/pci-bridge.h | 1
> > > b/arch/powerpc/include/asm/pci.h | 7
> > > b/arch/powerpc/platforms/powernv/Makefile | 2
> > > b/arch/powerpc/platforms/powernv/opal-call.c | 2
> > > b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 -------
> > > b/arch/powerpc/platforms/powernv/pci.c | 11
> > > b/arch/powerpc/platforms/powernv/pci.h | 17
> > > b/arch/powerpc/platforms/pseries/pci.c | 23
> > > b/drivers/vfio/pci/Kconfig | 6
> > > b/drivers/vfio/pci/Makefile | 1
> > > b/drivers/vfio/pci/vfio_pci.c | 18
> > > b/drivers/vfio/pci/vfio_pci_private.h | 14
> > > b/include/uapi/linux/vfio.h | 38 -
> >
> >
> > Hi Christoph,
> >
> > FYI, these uapi changes break build of QEMU.
>
> What uapi changes?
>
All macros and structure definitions that are being removed
from include/uapi/linux/vfio.h by patch 1.
> What exactly breaks?
>
These macros and types are used by the current QEMU code base.
Next time the QEMU source tree updates its copy of the kernel
headers, the compilation of affected code will fail.
> Why does QEMU require kernel driver stuff?
>
Not sure to understand the question... is there a problem
with QEMU using an already published uapi ?
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH 2/2] powerpc/64s: Fix crashes when toggling entry flush barrier
From: Michael Ellerman @ 2021-05-04 13:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nathanl, anton, npiggin, dja
In-Reply-To: <20210504134250.890401-1-mpe@ellerman.id.au>
The entry flush mitigation can be enabled/disabled at runtime via a
debugfs file (entry_flush), which causes the kernel to patch itself to
enable/disable the relevant mitigations.
However depending on which mitigation we're using, it may not be safe to
do that patching while other CPUs are active. For example the following
crash:
sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20
Shows that we returned to userspace with a corrupted LR that points into
the kernel, due to executing the partially patched call to the fallback
entry flush (ie. we missed the LR restore).
Fix it by doing the patching under stop machine. The CPUs that aren't
doing the patching will be spinning in the core of the stop machine
logic. That is currently sufficient for our purposes, because none of
the patching we do is to that code or anywhere in the vicinity.
Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry")
Cc: stable@vger.kernel.org # v5.10+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/lib/feature-fixups.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
index 8f8c8c98a6ac..679833564e19 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -299,8 +299,9 @@ void do_uaccess_flush_fixups(enum l1d_flush_type types)
: "unknown");
}
-void do_entry_flush_fixups(enum l1d_flush_type types)
+static int __do_entry_flush_fixups(void *data)
{
+ enum l1d_flush_type types = (enum l1d_flush_type)data;
unsigned int instrs[3], *dest;
long *start, *end;
int i;
@@ -369,6 +370,19 @@ void do_entry_flush_fixups(enum l1d_flush_type types)
: "ori type" :
(types & L1D_FLUSH_MTTRIG) ? "mttrig type"
: "unknown");
+
+ return 0;
+}
+
+void do_entry_flush_fixups(enum l1d_flush_type types)
+{
+ /*
+ * The call to the fallback flush can not be safely patched in/out while
+ * other CPUs are executing it. So call __do_entry_flush_fixups() on one
+ * CPU while all other CPUs spin in the stop machine core with interrupts
+ * hard disabled.
+ */
+ stop_machine_cpuslocked(__do_entry_flush_fixups, (void *)types, NULL);
}
void do_rfi_flush_fixups(enum l1d_flush_type types)
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/64s: Fix crashes when toggling stf barrier
From: Michael Ellerman @ 2021-05-04 13:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nathanl, anton, npiggin, dja
The STF (store-to-load forwarding) barrier mitigation can be
enabled/disabled at runtime via a debugfs file (stf_barrier), which
causes the kernel to patch itself to enable/disable the relevant
mitigations.
However depending on which mitigation we're using, it may not be safe to
do that patching while other CPUs are active. For example the following
crash:
User access of kernel address (c00000003fff5af0) - exploit attempt? (uid: 0)
segfault (11) at c00000003fff5af0 nip 7fff8ad12198 lr 7fff8ad121f8 code 1
code: 40820128 e93c00d0 e9290058 7c292840 40810058 38600000 4bfd9a81 e8410018
code: 2c030006 41810154 3860ffb6 e9210098 <e94d8ff0> 7d295279 39400000 40820a3c
Shows that we returned to userspace without restoring the user r13
value, due to executing the partially patched STF exit code.
Fix it by doing the patching under stop machine. The CPUs that aren't
doing the patching will be spinning in the core of the stop machine
logic. That is currently sufficient for our purposes, because none of
the patching we do is to that code or anywhere in the vicinity.
Fixes: a048a07d7f45 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit")
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/lib/feature-fixups.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
index 1fd31b4b0e13..8f8c8c98a6ac 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -14,6 +14,7 @@
#include <linux/string.h>
#include <linux/init.h>
#include <linux/sched/mm.h>
+#include <linux/stop_machine.h>
#include <asm/cputable.h>
#include <asm/code-patching.h>
#include <asm/page.h>
@@ -227,11 +228,25 @@ static void do_stf_exit_barrier_fixups(enum stf_barrier_type types)
: "unknown");
}
-
-void do_stf_barrier_fixups(enum stf_barrier_type types)
+static int __do_stf_barrier_fixups(void *data)
{
+ enum stf_barrier_type types = (enum stf_barrier_type)data;
+
do_stf_entry_barrier_fixups(types);
do_stf_exit_barrier_fixups(types);
+
+ return 0;
+}
+
+void do_stf_barrier_fixups(enum stf_barrier_type types)
+{
+ /*
+ * The call to the fallback entry flush, and the fallback/sync-ori exit
+ * flush can not be safely patched in/out while other CPUs are executing
+ * them. So call __do_stf_barrier_fixups() on one CPU while all other CPUs
+ * spin in the stop machine core with interrupts hard disabled.
+ */
+ stop_machine_cpuslocked(__do_stf_barrier_fixups, (void *)types, NULL);
}
void do_uaccess_flush_fixups(enum l1d_flush_type types)
--
2.25.1
^ permalink raw reply related
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christian Zigotzky @ 2021-05-04 13:48 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <6d3ae417-48de-3b61-f6fe-da951d74fef3@xenosoft.de>
Am 04.05.21 um 13:02 schrieb Christian Zigotzky:
> Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
>> Am 04.05.21 um 11:49 schrieb Christophe Leroy:
>>>
>>>
>>> Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
>>>> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>>>>
>>>>>
>>>>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>>>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>>>>
>>>>>>>
>>>>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>>>>> Hi Christophe,
>>>>>>>>>>
>>>>>>>>>> Thanks for your answer but I think I don't know how it works
>>>>>>>>>> with the cherry-pick.
>>>>>>>>>>
>>>>>>>>>> $ git bisect start
>>>>>>>>>
>>>>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>>>>
>>>>>>>>> git bisect start -- arch/powerpc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>>
>>>>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the
>>>>>>>>> search I think:
>>>>>>>>>
>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>> git bisect good 887f3ceb51cd3~
>>>>>>>> I tried it but without any success.
>>>>>>>>
>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>
>>>>>>>> Output:
>>>>>>>> fatal: Needed a single revision
>>>>>>>> Bad rev input: powerpc-5.13-1
>>>>>>>
>>>>>>> I don't understand, on my side it works. Maybe a difference
>>>>>>> between your version of git and mine.
>>>>>>>
>>>>>>> In that case, just use the SHA corresponding to the merge:
>>>>>>>
>>>>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>
>>>>>>> Christophe
>>>>>> Do you use a BookE machine?
>>>>>
>>>>> No I don't unfortunately, and I have tried booting in QEMU a
>>>>> kernel built with your config, but it freezes before any output.
>>>> You can use my kernels and distributions.
>>>>
>>>
>>> Ok, I'll see if I can do something with them.
>>>
>>> In the meantime, have you been able to bisect ?
>>>
>>> Thanks
>>> Christophe
>> I am bisecting currently.
>>
>> $ git bisect start -- arch/powerpc
>> $ git bisect good 887f3ceb51cd3~
>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
> OK, there is another issue after the second bisecting step. The boot
> stops after loading the dtb and uImage file. I can't solve 2 issues
> with bisecting at the same time.
Xorg restarts again and again.
Here are some interesting error messages:
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11) at
800000 nip ff6a770 lr ff6a760 code 1 in
libglib-2.0.so.0.4800.2[feaf000+11f000]
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401
3920ffff 91210054 8061005c 2f830000 419c0014 38800000 4bfc93e5
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920ffff
9121005c 2f8f0000 419e0008 <93ef0000> 418e000c 81210040 913b0000
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault
(11) at 8 nip 92dbc8 lr 92dae8 code 1 in packagekitd[920000+51000]
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code:
38800080 3be001f4 4cc63182 4802c8ad 4bffff64 60000000 81210018 80be8048
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code:
7fa6eb78 38800010 807e801c 3be0ffff <80e90008> 4cc63182 4802c881 4bffff38
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Daniel Vetter @ 2021-05-04 14:23 UTC (permalink / raw)
To: Greg Kurz
Cc: Daniel Vetter, kvm, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, qemu-devel, Alex Williamson,
Paul Mackerras, Jason Gunthorpe, qemu-ppc, linux-api,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <20210504152034.18e41ec3@bahia.lan>
On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> On Tue, 4 May 2021 14:59:07 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > > Hi all,
> > > >
> > > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> > > > feature without any open source component - what would normally be
> > > > the normal open source userspace that we require for kernel drivers,
> > > > although in this particular case user space could of course be a
> > > > kernel driver in a VM. It also happens to be a complete mess that
> > > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > > and also pulles in over 1000 lines of code always build into powerpc
> > > > kernels that have Power NV support enabled. Because of all these
> > > > issues and the lack of breaking userspace when it is removed I think
> > > > the best idea is to simply kill.
> > > >
> > > > Changes since v1:
> > > > - document the removed subtypes as reserved
> > > > - add the ACK from Greg
> > > >
> > > > Diffstat:
> > > > arch/powerpc/platforms/powernv/npu-dma.c | 705 ---------------------------
> > > > b/arch/powerpc/include/asm/opal.h | 3
> > > > b/arch/powerpc/include/asm/pci-bridge.h | 1
> > > > b/arch/powerpc/include/asm/pci.h | 7
> > > > b/arch/powerpc/platforms/powernv/Makefile | 2
> > > > b/arch/powerpc/platforms/powernv/opal-call.c | 2
> > > > b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 -------
> > > > b/arch/powerpc/platforms/powernv/pci.c | 11
> > > > b/arch/powerpc/platforms/powernv/pci.h | 17
> > > > b/arch/powerpc/platforms/pseries/pci.c | 23
> > > > b/drivers/vfio/pci/Kconfig | 6
> > > > b/drivers/vfio/pci/Makefile | 1
> > > > b/drivers/vfio/pci/vfio_pci.c | 18
> > > > b/drivers/vfio/pci/vfio_pci_private.h | 14
> > > > b/include/uapi/linux/vfio.h | 38 -
> > >
> > >
> > > Hi Christoph,
> > >
> > > FYI, these uapi changes break build of QEMU.
> >
> > What uapi changes?
> >
>
> All macros and structure definitions that are being removed
> from include/uapi/linux/vfio.h by patch 1.
Just my 2cents from drm (where we deprecate old gunk uapi quite often):
Imo it's best to keep the uapi headers as-is, but exchange the
documentation with a big "this is removed, never use again" warning:
- it occasionally serves as a good lesson for how to not do uapi (whatever
the reasons really are in the specific case)
- it's good to know which uapi numbers (like parameter extensions or
whatever they are in this case) are defacto reserved, because there are
binaries (qemu in this) that have code acting on them out there.
The only exception where we completely nuke the structs and #defines is
when uapi has been only used by testcases. Which we know, since we defacto
limit our stable uapi guarantee to the canonical open&upstream userspace
drivers only (for at least the driver-specific stuff, the cross-driver
interfaces are hopeless).
Anyway feel free to ignore since this might be different than drivers/gpu.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Greg Kurz @ 2021-05-04 14:11 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Daniel Vetter, kvm, David Airlie, linux-kernel, dri-devel,
qemu-devel, Alex Williamson, Paul Mackerras, Jason Gunthorpe,
linux-api, qemu-ppc, linuxppc-dev, Christoph Hellwig
In-Reply-To: <YJFMZ8KYVCDwUBPU@kroah.com>
On Tue, 4 May 2021 15:30:15 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> > On Tue, 4 May 2021 14:59:07 +0200
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > > Christoph Hellwig <hch@lst.de> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> > > > > feature without any open source component - what would normally be
> > > > > the normal open source userspace that we require for kernel drivers,
> > > > > although in this particular case user space could of course be a
> > > > > kernel driver in a VM. It also happens to be a complete mess that
> > > > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > > > and also pulles in over 1000 lines of code always build into powerpc
> > > > > kernels that have Power NV support enabled. Because of all these
> > > > > issues and the lack of breaking userspace when it is removed I think
> > > > > the best idea is to simply kill.
> > > > >
> > > > > Changes since v1:
> > > > > - document the removed subtypes as reserved
> > > > > - add the ACK from Greg
> > > > >
> > > > > Diffstat:
> > > > > arch/powerpc/platforms/powernv/npu-dma.c | 705 ---------------------------
> > > > > b/arch/powerpc/include/asm/opal.h | 3
> > > > > b/arch/powerpc/include/asm/pci-bridge.h | 1
> > > > > b/arch/powerpc/include/asm/pci.h | 7
> > > > > b/arch/powerpc/platforms/powernv/Makefile | 2
> > > > > b/arch/powerpc/platforms/powernv/opal-call.c | 2
> > > > > b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 -------
> > > > > b/arch/powerpc/platforms/powernv/pci.c | 11
> > > > > b/arch/powerpc/platforms/powernv/pci.h | 17
> > > > > b/arch/powerpc/platforms/pseries/pci.c | 23
> > > > > b/drivers/vfio/pci/Kconfig | 6
> > > > > b/drivers/vfio/pci/Makefile | 1
> > > > > b/drivers/vfio/pci/vfio_pci.c | 18
> > > > > b/drivers/vfio/pci/vfio_pci_private.h | 14
> > > > > b/include/uapi/linux/vfio.h | 38 -
> > > >
> > > >
> > > > Hi Christoph,
> > > >
> > > > FYI, these uapi changes break build of QEMU.
> > >
> > > What uapi changes?
> > >
> >
> > All macros and structure definitions that are being removed
> > from include/uapi/linux/vfio.h by patch 1.
> >
> > > What exactly breaks?
> > >
> >
> > These macros and types are used by the current QEMU code base.
> > Next time the QEMU source tree updates its copy of the kernel
> > headers, the compilation of affected code will fail.
>
> So does QEMU use this api that is being removed, or does it just have
> some odd build artifacts of the uapi things?
>
These are region subtypes definition and associated capabilities.
QEMU basically gets information on VFIO regions from the kernel
driver and for those regions with a nvlink2 subtype, it tries
to extract some more nvlink2 related info.
> What exactly is the error messages here?
>
[55/143] Compiling C object libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o
FAILED: libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o
cc -Ilibqemu-ppc64-softmmu.fa.p -I. -I../.. -Itarget/ppc -I../../target/ppc -I../../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g -isystem /home/greg/Work/qemu/qemu-virtiofs/linux-headers -isystem linux-headers -iquote . -iquote /home/greg/Work/qemu/qemu-virtiofs -iquote /home/greg/Work/qemu/qemu-virtiofs/include -iquote /home/greg/Work/qemu/qemu-virtiofs/disas/libvixl -iquote /home/greg/Work/qemu/qemu-virtiofs/tcg/ppc -iquote /home/greg/Work/qemu/qemu-virtiofs/accel/tcg -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIC -isystem../../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="ppc64-softmmu-config-target.h"' '-DCONFIG_DEVICES="ppc64-softmmu-config-devices.h"' -MD -MQ libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -MF libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o.d -o libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -c ../../hw/vfio/pci-quirks.c
../../hw/vfio/pci-quirks.c: In function ‘vfio_pci_nvidia_v100_ram_init’:
../../hw/vfio/pci-quirks.c:1597:36: error: ‘VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM’ undeclared (first use in this function); did you mean ‘VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD’?
VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD
../../hw/vfio/pci-quirks.c:1597:36: note: each undeclared identifier is reported only once for each function it appears in
../../hw/vfio/pci-quirks.c:1603:44: error: ‘VFIO_REGION_INFO_CAP_NVLINK2_SSATGT’ undeclared (first use in this function); did you mean ‘VFIO_REGION_INFO_CAP_SPARSE_MMAP’?
hdr = vfio_get_region_info_cap(nv2reg, VFIO_REGION_INFO_CAP_NVLINK2_SSATGT);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VFIO_REGION_INFO_CAP_SPARSE_MMAP
../../hw/vfio/pci-quirks.c:1624:49: error: dereferencing pointer to incomplete type ‘struct vfio_region_info_cap_nvlink2_ssatgt’
(void *) (uintptr_t) cap->tgt);
^~
../../hw/vfio/pci-quirks.c: In function ‘vfio_pci_nvlink2_init’:
../../hw/vfio/pci-quirks.c:1646:36: error: ‘VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD’ undeclared (first use in this function); did you mean ‘VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD’?
VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD
../../hw/vfio/pci-quirks.c:1653:36: error: ‘VFIO_REGION_INFO_CAP_NVLINK2_SSATGT’ undeclared (first use in this function); did you mean ‘VFIO_REGION_INFO_CAP_SPARSE_MMAP’?
VFIO_REGION_INFO_CAP_NVLINK2_SSATGT);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VFIO_REGION_INFO_CAP_SPARSE_MMAP
../../hw/vfio/pci-quirks.c:1661:36: error: ‘VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD’ undeclared (first use in this function); did you mean ‘VFIO_REGION_INFO_CAP_SPARSE_MMAP’?
VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VFIO_REGION_INFO_CAP_SPARSE_MMAP
../../hw/vfio/pci-quirks.c:1685:52: error: dereferencing pointer to incomplete type ‘struct vfio_region_info_cap_nvlink2_ssatgt’
(void *) (uintptr_t) captgt->tgt);
^~
../../hw/vfio/pci-quirks.c:1691:54: error: dereferencing pointer to incomplete type ‘struct vfio_region_info_cap_nvlink2_lnkspd’
(void *) (uintptr_t) capspeed->link_speed);
^~
> And if we put the uapi .h file stuff back, is that sufficient for qemu
> to work, as it should be checking at runtime what the kernel has / has
> not anyway, right?
>
Right. This will just be dead code in QEMU for newer kernels.
Anyway, as said in some other mail, it is probably time for QEMU to
start deprecating this code as well.
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christophe Leroy @ 2021-05-04 14:41 UTC (permalink / raw)
To: Christian Zigotzky, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <6d3ae417-48de-3b61-f6fe-da951d74fef3@xenosoft.de>
Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :
> Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
>> Am 04.05.21 um 11:49 schrieb Christophe Leroy:
>>>
>>>
>>> Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
>>>> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>>>>
>>>>>
>>>>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>>>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>>>>
>>>>>>>
>>>>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>>>>> Hi Christophe,
>>>>>>>>>>
>>>>>>>>>> Thanks for your answer but I think I don't know how it works with the cherry-pick.
>>>>>>>>>>
>>>>>>>>>> $ git bisect start
>>>>>>>>>
>>>>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>>>>
>>>>>>>>> git bisect start -- arch/powerpc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>>
>>>>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the search I think:
>>>>>>>>>
>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>> git bisect good 887f3ceb51cd3~
>>>>>>>> I tried it but without any success.
>>>>>>>>
>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>
>>>>>>>> Output:
>>>>>>>> fatal: Needed a single revision
>>>>>>>> Bad rev input: powerpc-5.13-1
>>>>>>>
>>>>>>> I don't understand, on my side it works. Maybe a difference between your version of git and
>>>>>>> mine.
>>>>>>>
>>>>>>> In that case, just use the SHA corresponding to the merge:
>>>>>>>
>>>>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>
>>>>>>> Christophe
>>>>>> Do you use a BookE machine?
>>>>>
>>>>> No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but
>>>>> it freezes before any output.
>>>> You can use my kernels and distributions.
>>>>
>>>
>>> Ok, I'll see if I can do something with them.
>>>
>>> In the meantime, have you been able to bisect ?
>>>
>>> Thanks
>>> Christophe
>> I am bisecting currently.
>>
>> $ git bisect start -- arch/powerpc
>> $ git bisect good 887f3ceb51cd3~
>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
> OK, there is another issue after the second bisecting step. The boot stops after loading the dtb and
> uImage file. I can't solve 2 issues with bisecting at the same time.
In that case, you can use 'git bisect skip' to skip the one that is not booting at all.
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christophe Leroy @ 2021-05-04 14:44 UTC (permalink / raw)
To: Christian Zigotzky, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <1502fb22-680c-7393-238c-f82570806717@xenosoft.de>
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>
>>
>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>
>>>>
>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>> Hi
>>>>>>
>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>> Hi Christophe,
>>>>>>>
>>>>>>> Thanks for your answer but I think I don't know how it works with the cherry-pick.
>>>>>>>
>>>>>>> $ git bisect start
>>>>>>
>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>
>>>>>> git bisect start -- arch/powerpc
>>>>>>
>>>>>>
>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>
>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the search I think:
>>>>>>
>>>>>> git bisect bad powerpc-5.13-1
>>>>>> git bisect good 887f3ceb51cd3~
>>>>> I tried it but without any success.
>>>>>
>>>>> git bisect bad powerpc-5.13-1
>>>>>
>>>>> Output:
>>>>> fatal: Needed a single revision
>>>>> Bad rev input: powerpc-5.13-1
>>>>
>>>> I don't understand, on my side it works. Maybe a difference between your version of git and mine.
>>>>
>>>> In that case, just use the SHA corresponding to the merge:
>>>>
>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>
>>>> Christophe
>>> Do you use a BookE machine?
>>
>> No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it
>> freezes before any output.
> You can use my kernels and distributions.
>
> Download Fedora 28 PPC64: http://www.xenosoft.de/fedora28-2.img.tar.gz
> Download size: 4.1 GB
> MD5 checksum: 1784ca69651531522161498720a89414
>
> Default username and password:
> Username: amigaone
> Password: amigaone
> Root Password: amigaone
>
> You can start the MATE desktop with "startx".
>
> Download MintPPC (Debian Sid) PPC32: http://www.xenosoft.de/MintPPC32-X5000.tar.gz
> MD5 checksum: b31c1c1ca1fcf5d4cdf110c4bce11654
>
> The password for both 'root' and 'mintppc' is 'mintppc'.
>
> Download kernel 5.12.0 for the AmigaOne X5000 and for the virtual e5500 QEMU machine without the bad
> commit: http://www.xenosoft.de/linux-image-5.12-X1000_X5000.tar.gz
> Download git kernel for the AmigaOne X5000 and for the virtual e5500 QEMU machine with the bad
> commit: http://www.xenosoft.de/linux-image-5.13-alpha3-X1000_X5000.tar.gz
>
> QEMU command with KVM on the X5000: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024
> -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0
> -device e1000,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci
> -device virtio-keyboard-pci -device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4
>
> QEMU command for Fedora 28 without KVM and with VNC connect: qemu-system-ppc64 -M ppce500 -cpu e5500
> -m 1024 -kernel uImage -drive format=raw,file=fedora28-2.img,index=0,if=virtio -netdev
> user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga
> -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
>
> QEMU command for MintPPC without KVM and with VNC connect: qemu-system-ppc64 -M ppce500 -cpu e5500
> -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev
> user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga
> -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
It doesn't work, it remains stuck.
But I'm probably not in the best situation: I'm on a PC running Windows 7, with Virtualbox running
Fedora core 33 and I try to run powerpc QEMU on the fedora core 33. Maybe too many layers to succeed.
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christophe Leroy @ 2021-05-04 14:48 UTC (permalink / raw)
To: Christian Zigotzky, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <070042db-0ac6-f4f6-1232-2f37c5e63d14@xenosoft.de>
Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :
> Am 04.05.21 um 13:02 schrieb Christian Zigotzky:
>> Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
>>> Am 04.05.21 um 11:49 schrieb Christophe Leroy:
>>>>
>>>>
>>>> Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
>>>>> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>>>>>
>>>>>>
>>>>>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>>>>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>>>>>> Hi Christophe,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your answer but I think I don't know how it works with the cherry-pick.
>>>>>>>>>>>
>>>>>>>>>>> $ git bisect start
>>>>>>>>>>
>>>>>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>>>>>
>>>>>>>>>> git bisect start -- arch/powerpc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>>>
>>>>>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the search I think:
>>>>>>>>>>
>>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>>> git bisect good 887f3ceb51cd3~
>>>>>>>>> I tried it but without any success.
>>>>>>>>>
>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>>
>>>>>>>>> Output:
>>>>>>>>> fatal: Needed a single revision
>>>>>>>>> Bad rev input: powerpc-5.13-1
>>>>>>>>
>>>>>>>> I don't understand, on my side it works. Maybe a difference between your version of git and
>>>>>>>> mine.
>>>>>>>>
>>>>>>>> In that case, just use the SHA corresponding to the merge:
>>>>>>>>
>>>>>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>
>>>>>>>> Christophe
>>>>>>> Do you use a BookE machine?
>>>>>>
>>>>>> No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config,
>>>>>> but it freezes before any output.
>>>>> You can use my kernels and distributions.
>>>>>
>>>>
>>>> Ok, I'll see if I can do something with them.
>>>>
>>>> In the meantime, have you been able to bisect ?
>>>>
>>>> Thanks
>>>> Christophe
>>> I am bisecting currently.
>>>
>>> $ git bisect start -- arch/powerpc
>>> $ git bisect good 887f3ceb51cd3~
>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>> OK, there is another issue after the second bisecting step. The boot stops after loading the dtb
>> and uImage file. I can't solve 2 issues with bisecting at the same time.
> Xorg restarts again and again.
>
> Here are some interesting error messages:
>
> May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11) at 800000 nip ff6a770 lr
> ff6a760 code 1 in libglib-2.0.so.0.4800.2[feaf000+11f000]
> May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401 3920ffff 91210054 8061005c
> 2f830000 419c0014 38800000 4bfc93e5
> May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920ffff 9121005c 2f8f0000 419e0008
> <93ef0000> 418e000c 81210040 913b0000
>
> May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault (11) at 8 nip 92dbc8 lr 92dae8
> code 1 in packagekitd[920000+51000]
> May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 38800080 3be001f4 4cc63182
> 4802c8ad 4bffff64 60000000 81210018 80be8048
> May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 7fa6eb78 38800010 807e801c
> 3be0ffff <80e90008> 4cc63182 4802c881 4bffff38
Yes it shows you get a segfault for some reason.
So yes, 887f3ceb51cd3 could have been the reason but 525642624783 fixes it already.
Therefore I think a proper bisect is needed to identify the culprit commit to understand the reason
and fix it.
You are running a 32 bits userspace on a 64 bits kernel ?
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christian Zigotzky @ 2021-05-04 14:52 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <dee3f4b0-e960-ce37-2f04-c95e982af64f@csgroup.eu>
Am 04.05.21 um 16:48 schrieb Christophe Leroy:
>
>
> Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :
>> Am 04.05.21 um 13:02 schrieb Christian Zigotzky:
>>> Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
>>>> Am 04.05.21 um 11:49 schrieb Christophe Leroy:
>>>>>
>>>>>
>>>>> Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
>>>>>> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>>>>>>
>>>>>>>
>>>>>>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>>>>>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>>>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>>>>>>> Hi Christophe,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your answer but I think I don't know how it
>>>>>>>>>>>> works with the cherry-pick.
>>>>>>>>>>>>
>>>>>>>>>>>> $ git bisect start
>>>>>>>>>>>
>>>>>>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>>>>>>
>>>>>>>>>>> git bisect start -- arch/powerpc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>>>>
>>>>>>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the
>>>>>>>>>>> search I think:
>>>>>>>>>>>
>>>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>>>> git bisect good 887f3ceb51cd3~
>>>>>>>>>> I tried it but without any success.
>>>>>>>>>>
>>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>>>
>>>>>>>>>> Output:
>>>>>>>>>> fatal: Needed a single revision
>>>>>>>>>> Bad rev input: powerpc-5.13-1
>>>>>>>>>
>>>>>>>>> I don't understand, on my side it works. Maybe a difference
>>>>>>>>> between your version of git and mine.
>>>>>>>>>
>>>>>>>>> In that case, just use the SHA corresponding to the merge:
>>>>>>>>>
>>>>>>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>>
>>>>>>>>> Christophe
>>>>>>>> Do you use a BookE machine?
>>>>>>>
>>>>>>> No I don't unfortunately, and I have tried booting in QEMU a
>>>>>>> kernel built with your config, but it freezes before any output.
>>>>>> You can use my kernels and distributions.
>>>>>>
>>>>>
>>>>> Ok, I'll see if I can do something with them.
>>>>>
>>>>> In the meantime, have you been able to bisect ?
>>>>>
>>>>> Thanks
>>>>> Christophe
>>>> I am bisecting currently.
>>>>
>>>> $ git bisect start -- arch/powerpc
>>>> $ git bisect good 887f3ceb51cd3~
>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>> OK, there is another issue after the second bisecting step. The boot
>>> stops after loading the dtb and uImage file. I can't solve 2 issues
>>> with bisecting at the same time.
>> Xorg restarts again and again.
>>
>> Here are some interesting error messages:
>>
>> May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11)
>> at 800000 nip ff6a770 lr ff6a760 code 1 in
>> libglib-2.0.so.0.4800.2[feaf000+11f000]
>> May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401
>> 3920ffff 91210054 8061005c 2f830000 419c0014 38800000 4bfc93e5
>> May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920ffff
>> 9121005c 2f8f0000 419e0008 <93ef0000> 418e000c 81210040 913b0000
>>
>> May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault
>> (11) at 8 nip 92dbc8 lr 92dae8 code 1 in packagekitd[920000+51000]
>> May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code:
>> 38800080 3be001f4 4cc63182 4802c8ad 4bffff64 60000000 81210018 80be8048
>> May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code:
>> 7fa6eb78 38800010 807e801c 3be0ffff <80e90008> 4cc63182 4802c881
>> 4bffff38
>
> Yes it shows you get a segfault for some reason.
> So yes, 887f3ceb51cd3 could have been the reason but 525642624783
> fixes it already.
>
> Therefore I think a proper bisect is needed to identify the culprit
> commit to understand the reason and fix it.
>
> You are running a 32 bits userspace on a 64 bits kernel ?
>
I use 32-bit and 64-bit userlands with 64-bit kernels. Both userlands
are affected by the Xorg issue.
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christian Zigotzky @ 2021-05-04 14:59 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <07541597-f309-0d33-2c29-6da8fcd10aa1@csgroup.eu>
Am 04.05.21 um 16:41 schrieb Christophe Leroy:
>
>
> Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :
>> Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
>>> Am 04.05.21 um 11:49 schrieb Christophe Leroy:
>>>>
>>>>
>>>> Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
>>>>> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>>>>>
>>>>>>
>>>>>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>>>>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>>>>>> Hi Christophe,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your answer but I think I don't know how it works
>>>>>>>>>>> with the cherry-pick.
>>>>>>>>>>>
>>>>>>>>>>> $ git bisect start
>>>>>>>>>>
>>>>>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>>>>>
>>>>>>>>>> git bisect start -- arch/powerpc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>>>
>>>>>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the
>>>>>>>>>> search I think:
>>>>>>>>>>
>>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>>> git bisect good 887f3ceb51cd3~
>>>>>>>>> I tried it but without any success.
>>>>>>>>>
>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>>
>>>>>>>>> Output:
>>>>>>>>> fatal: Needed a single revision
>>>>>>>>> Bad rev input: powerpc-5.13-1
>>>>>>>>
>>>>>>>> I don't understand, on my side it works. Maybe a difference
>>>>>>>> between your version of git and mine.
>>>>>>>>
>>>>>>>> In that case, just use the SHA corresponding to the merge:
>>>>>>>>
>>>>>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>
>>>>>>>> Christophe
>>>>>>> Do you use a BookE machine?
>>>>>>
>>>>>> No I don't unfortunately, and I have tried booting in QEMU a
>>>>>> kernel built with your config, but it freezes before any output.
>>>>> You can use my kernels and distributions.
>>>>>
>>>>
>>>> Ok, I'll see if I can do something with them.
>>>>
>>>> In the meantime, have you been able to bisect ?
>>>>
>>>> Thanks
>>>> Christophe
>>> I am bisecting currently.
>>>
>>> $ git bisect start -- arch/powerpc
>>> $ git bisect good 887f3ceb51cd3~
>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>> OK, there is another issue after the second bisecting step. The boot
>> stops after loading the dtb and uImage file. I can't solve 2 issues
>> with bisecting at the same time.
>
> In that case, you can use 'git bisect skip' to skip the one that is
> not booting at all.
In my point of view 'git bisect skip' isn't a good idea because I will
not find out if the skipped commit is good or bad and maybe the first
bad commit.
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christophe Leroy @ 2021-05-04 15:17 UTC (permalink / raw)
To: Christian Zigotzky, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <c4914f77-f8c2-e869-d731-4d0882e12af0@xenosoft.de>
Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :
> Am 04.05.21 um 16:41 schrieb Christophe Leroy:
>>
>>
>> Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :
>>> Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
>>>> Am 04.05.21 um 11:49 schrieb Christophe Leroy:
>>>>>
>>>>>
>>>>> Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
>>>>>> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>>>>>>
>>>>>>>
>>>>>>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>>>>>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>>>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>>>>>>> Hi Christophe,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your answer but I think I don't know how it works with the cherry-pick.
>>>>>>>>>>>>
>>>>>>>>>>>> $ git bisect start
>>>>>>>>>>>
>>>>>>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>>>>>>
>>>>>>>>>>> git bisect start -- arch/powerpc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>>>>
>>>>>>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the search I think:
>>>>>>>>>>>
>>>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>>>> git bisect good 887f3ceb51cd3~
>>>>>>>>>> I tried it but without any success.
>>>>>>>>>>
>>>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>>>>
>>>>>>>>>> Output:
>>>>>>>>>> fatal: Needed a single revision
>>>>>>>>>> Bad rev input: powerpc-5.13-1
>>>>>>>>>
>>>>>>>>> I don't understand, on my side it works. Maybe a difference between your version of git and
>>>>>>>>> mine.
>>>>>>>>>
>>>>>>>>> In that case, just use the SHA corresponding to the merge:
>>>>>>>>>
>>>>>>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>>
>>>>>>>>> Christophe
>>>>>>>> Do you use a BookE machine?
>>>>>>>
>>>>>>> No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config,
>>>>>>> but it freezes before any output.
>>>>>> You can use my kernels and distributions.
>>>>>>
>>>>>
>>>>> Ok, I'll see if I can do something with them.
>>>>>
>>>>> In the meantime, have you been able to bisect ?
>>>>>
>>>>> Thanks
>>>>> Christophe
>>>> I am bisecting currently.
>>>>
>>>> $ git bisect start -- arch/powerpc
>>>> $ git bisect good 887f3ceb51cd3~
>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>> OK, there is another issue after the second bisecting step. The boot stops after loading the dtb
>>> and uImage file. I can't solve 2 issues with bisecting at the same time.
>>
>> In that case, you can use 'git bisect skip' to skip the one that is not booting at all.
> In my point of view 'git bisect skip' isn't a good idea because I will not find out if the skipped
> commit is good or bad and maybe the first bad commit.
The second problem may be completely unrelated to the first one so it could work.
In any case, if 'git bisect' finds out that the bad commit is in the middle of a skipped area, it
will tell you. So I think it is worth it.
The second solution could be to first focus on that 'boot stops after loading problem' and try to
find out which commit introduces the bug, then which one fixes it. But it may not be necessary.
Other solution, as you were thinking that the conversion of 'booke' to C interrupt entry/exit, you
can also try around that: See if d738ee8 has the problem and 2e2a441 doesn't have the problem.
If so, you can bisect between those two commits (There are 8 commits inbetween).
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Alex Williamson @ 2021-05-04 15:33 UTC (permalink / raw)
To: Greg Kurz
Cc: Daniel Vetter, kvm, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, qemu-devel, Paul Mackerras,
Jason Gunthorpe, qemu-ppc, linux-api, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <20210504161131.2ed74d7b@bahia.lan>
On Tue, 4 May 2021 16:11:31 +0200
Greg Kurz <groug@kaod.org> wrote:
> On Tue, 4 May 2021 15:30:15 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> > > On Tue, 4 May 2021 14:59:07 +0200
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > >
> > > > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > > > Christoph Hellwig <hch@lst.de> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> > > > > > feature without any open source component - what would normally be
> > > > > > the normal open source userspace that we require for kernel drivers,
> > > > > > although in this particular case user space could of course be a
> > > > > > kernel driver in a VM. It also happens to be a complete mess that
> > > > > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > > > > and also pulles in over 1000 lines of code always build into powerpc
> > > > > > kernels that have Power NV support enabled. Because of all these
> > > > > > issues and the lack of breaking userspace when it is removed I think
> > > > > > the best idea is to simply kill.
> > > > > >
> > > > > > Changes since v1:
> > > > > > - document the removed subtypes as reserved
> > > > > > - add the ACK from Greg
> > > > > >
> > > > > > Diffstat:
> > > > > > arch/powerpc/platforms/powernv/npu-dma.c | 705 ---------------------------
> > > > > > b/arch/powerpc/include/asm/opal.h | 3
> > > > > > b/arch/powerpc/include/asm/pci-bridge.h | 1
> > > > > > b/arch/powerpc/include/asm/pci.h | 7
> > > > > > b/arch/powerpc/platforms/powernv/Makefile | 2
> > > > > > b/arch/powerpc/platforms/powernv/opal-call.c | 2
> > > > > > b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 -------
> > > > > > b/arch/powerpc/platforms/powernv/pci.c | 11
> > > > > > b/arch/powerpc/platforms/powernv/pci.h | 17
> > > > > > b/arch/powerpc/platforms/pseries/pci.c | 23
> > > > > > b/drivers/vfio/pci/Kconfig | 6
> > > > > > b/drivers/vfio/pci/Makefile | 1
> > > > > > b/drivers/vfio/pci/vfio_pci.c | 18
> > > > > > b/drivers/vfio/pci/vfio_pci_private.h | 14
> > > > > > b/include/uapi/linux/vfio.h | 38 -
> > > > >
> > > > >
> > > > > Hi Christoph,
> > > > >
> > > > > FYI, these uapi changes break build of QEMU.
> > > >
> > > > What uapi changes?
> > > >
> > >
> > > All macros and structure definitions that are being removed
> > > from include/uapi/linux/vfio.h by patch 1.
> > >
> > > > What exactly breaks?
> > > >
> > >
> > > These macros and types are used by the current QEMU code base.
> > > Next time the QEMU source tree updates its copy of the kernel
> > > headers, the compilation of affected code will fail.
> >
> > So does QEMU use this api that is being removed, or does it just have
> > some odd build artifacts of the uapi things?
> >
>
> These are region subtypes definition and associated capabilities.
> QEMU basically gets information on VFIO regions from the kernel
> driver and for those regions with a nvlink2 subtype, it tries
> to extract some more nvlink2 related info.
Urgh, let's put the uapi header back in place with a deprecation
notice. Userspace should never have a dependency on the existence of a
given region, but clearly will have code to parse the data structure
describing that region. I'll post a patch. Thanks,
Alex
^ permalink raw reply
* [PATCH] vfio/pci: Revert nvlink removal uAPI breakage
From: Alex Williamson @ 2021-05-04 15:52 UTC (permalink / raw)
To: kvm, groug, hch, gregkh, daniel
Cc: qemu-ppc, linux-api, linuxppc-dev, linux-kernel, qemu-devel
Revert the uAPI changes from the below commit with notice that these
regions and capabilities are no longer provided.
Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
Reported-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
Greg (Kurz), please double check this resolves the issue. Thanks!
include/uapi/linux/vfio.h | 46 +++++++++++++++++++++++++++++++++++++++++----
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 34b1f53a3901..ef33ea002b0b 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -333,10 +333,21 @@ struct vfio_region_info_cap_type {
#define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG (3)
/* 10de vendor PCI sub-types */
-/* subtype 1 was VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM, don't use */
+/*
+ * NVIDIA GPU NVlink2 RAM is coherent RAM mapped onto the host address space.
+ *
+ * Deprecated, region no longer provided
+ */
+#define VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM (1)
/* 1014 vendor PCI sub-types */
-/* subtype 1 was VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD, don't use */
+/*
+ * IBM NPU NVlink2 ATSD (Address Translation Shootdown) register of NPU
+ * to do TLB invalidation on a GPU.
+ *
+ * Deprecated, region no longer provided
+ */
+#define VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD (1)
/* sub-types for VFIO_REGION_TYPE_GFX */
#define VFIO_REGION_SUBTYPE_GFX_EDID (1)
@@ -630,9 +641,36 @@ struct vfio_device_migration_info {
*/
#define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE 3
-/* subtype 4 was VFIO_REGION_INFO_CAP_NVLINK2_SSATGT, don't use */
+/*
+ * Capability with compressed real address (aka SSA - small system address)
+ * where GPU RAM is mapped on a system bus. Used by a GPU for DMA routing
+ * and by the userspace to associate a NVLink bridge with a GPU.
+ *
+ * Deprecated, capability no longer provided
+ */
+#define VFIO_REGION_INFO_CAP_NVLINK2_SSATGT 4
+
+struct vfio_region_info_cap_nvlink2_ssatgt {
+ struct vfio_info_cap_header header;
+ __u64 tgt;
+};
-/* subtype 5 was VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD, don't use */
+/*
+ * Capability with an NVLink link speed. The value is read by
+ * the NVlink2 bridge driver from the bridge's "ibm,nvlink-speed"
+ * property in the device tree. The value is fixed in the hardware
+ * and failing to provide the correct value results in the link
+ * not working with no indication from the driver why.
+ *
+ * Deprecated, capability no longer provided
+ */
+#define VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD 5
+
+struct vfio_region_info_cap_nvlink2_lnkspd {
+ struct vfio_info_cap_header header;
+ __u32 link_speed;
+ __u32 __pad;
+};
/**
* VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,
^ permalink raw reply related
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Jason Gunthorpe @ 2021-05-04 15:53 UTC (permalink / raw)
To: Greg Kurz, Greg Kroah-Hartman, Christoph Hellwig,
Michael Ellerman, Alex Williamson, kvm, David Airlie,
linux-kernel, dri-devel, Paul Mackerras, linux-api, linuxppc-dev,
qemu-devel, qemu-ppc
In-Reply-To: <YJFY7NjEBtCSlJHw@phenom.ffwll.local>
On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote:
> Just my 2cents from drm (where we deprecate old gunk uapi quite often):
> Imo it's best to keep the uapi headers as-is, but exchange the
> documentation with a big "this is removed, never use again" warning:
We in RDMA have been doing the opposite, the uapi headers are supposed
to reflect the current kernel. This helps make the kernel
understandable.
When userspace needs backwards compat to ABI that the current kernel
doesn't support then userspace has distinct copies of that information
in some compat location. It has happened a few times over the last 15
years.
We keep full copies of the current kernel headers in the userspace
source tree, when the kernel headers change in a compile incompatible
way we fix everything while updating to the new kernel headers.
> - it's good to know which uapi numbers (like parameter extensions or
> whatever they are in this case) are defacto reserved, because there are
> binaries (qemu in this) that have code acting on them out there.
Numbers and things get marked reserved or the like
> Anyway feel free to ignore since this might be different than drivers/gpu.
AFAIK drives/gpu has a lot wider userspace, rdma manages this OK
because we only have one library package that provides the user/kernel
interface.
Jason
^ permalink raw reply
* Re: [PATCH] vfio/pci: Revert nvlink removal uAPI breakage
From: Cornelia Huck @ 2021-05-04 16:06 UTC (permalink / raw)
To: Alex Williamson
Cc: kvm, qemu-devel, gregkh, linux-kernel, groug, qemu-ppc, daniel,
linux-api, linuxppc-dev, hch
In-Reply-To: <162014341432.3807030.11054087109120670135.stgit@omen>
On Tue, 04 May 2021 09:52:02 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> Revert the uAPI changes from the below commit with notice that these
> regions and capabilities are no longer provided.
>
> Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
> Reported-by: Greg Kurz <groug@kaod.org>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>
> Greg (Kurz), please double check this resolves the issue. Thanks!
>
> include/uapi/linux/vfio.h | 46 +++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 42 insertions(+), 4 deletions(-)
I had already hacked up a QEMU patch that moved the definitions into
local headers, but this one is less of a hassle. (Code compiles fine
after doing a headers update.)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH] vfio/pci: Revert nvlink removal uAPI breakage
From: Greg Kurz @ 2021-05-04 16:11 UTC (permalink / raw)
To: Alex Williamson
Cc: kvm, gregkh, linux-kernel, qemu-devel, qemu-ppc, daniel,
linux-api, linuxppc-dev, hch
In-Reply-To: <162014341432.3807030.11054087109120670135.stgit@omen>
On Tue, 04 May 2021 09:52:02 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> Revert the uAPI changes from the below commit with notice that these
> regions and capabilities are no longer provided.
>
> Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
> Reported-by: Greg Kurz <groug@kaod.org>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>
> Greg (Kurz), please double check this resolves the issue. Thanks!
>
It does. Feel free to add:
Reviewed-by: Greg Kurz <groug@kaod.org>
and
Tested-by: Greg Kurz <groug@kaod.org>
Thanks for the quick fix.
Cheers,
--
Greg
> include/uapi/linux/vfio.h | 46 +++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 34b1f53a3901..ef33ea002b0b 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -333,10 +333,21 @@ struct vfio_region_info_cap_type {
> #define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG (3)
>
> /* 10de vendor PCI sub-types */
> -/* subtype 1 was VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM, don't use */
> +/*
> + * NVIDIA GPU NVlink2 RAM is coherent RAM mapped onto the host address space.
> + *
> + * Deprecated, region no longer provided
> + */
> +#define VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM (1)
>
> /* 1014 vendor PCI sub-types */
> -/* subtype 1 was VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD, don't use */
> +/*
> + * IBM NPU NVlink2 ATSD (Address Translation Shootdown) register of NPU
> + * to do TLB invalidation on a GPU.
> + *
> + * Deprecated, region no longer provided
> + */
> +#define VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD (1)
>
> /* sub-types for VFIO_REGION_TYPE_GFX */
> #define VFIO_REGION_SUBTYPE_GFX_EDID (1)
> @@ -630,9 +641,36 @@ struct vfio_device_migration_info {
> */
> #define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE 3
>
> -/* subtype 4 was VFIO_REGION_INFO_CAP_NVLINK2_SSATGT, don't use */
> +/*
> + * Capability with compressed real address (aka SSA - small system address)
> + * where GPU RAM is mapped on a system bus. Used by a GPU for DMA routing
> + * and by the userspace to associate a NVLink bridge with a GPU.
> + *
> + * Deprecated, capability no longer provided
> + */
> +#define VFIO_REGION_INFO_CAP_NVLINK2_SSATGT 4
> +
> +struct vfio_region_info_cap_nvlink2_ssatgt {
> + struct vfio_info_cap_header header;
> + __u64 tgt;
> +};
>
> -/* subtype 5 was VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD, don't use */
> +/*
> + * Capability with an NVLink link speed. The value is read by
> + * the NVlink2 bridge driver from the bridge's "ibm,nvlink-speed"
> + * property in the device tree. The value is fixed in the hardware
> + * and failing to provide the correct value results in the link
> + * not working with no indication from the driver why.
> + *
> + * Deprecated, capability no longer provided
> + */
> +#define VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD 5
> +
> +struct vfio_region_info_cap_nvlink2_lnkspd {
> + struct vfio_info_cap_header header;
> + __u32 link_speed;
> + __u32 __pad;
> +};
>
> /**
> * VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox