• Fix compiler warning

• Merge with 'master'
• Address review comments

Looks good to me.

Overall the changes look ok to me.

The changes look ok to me. They seem to preserve the original logic, while avoiding the full PTE from PVO conversion.

Looks good.

• Address review's comments
• Fixed an issue in ofw_real_mtx_unlock()

• Merge branch 'master' into luporl-fix-vty
• Address review comments

In D22199#485111, @jhibbits wrote:

The trampoline for ppc64 is at 0x3ffffffffffe000 + offset, in the shared page.

• Merge branch 'master' into luporl-fix-gdb-sigtramp
• Add proper sigtramp detection for ppc64

Fix diff.

Fix diff

• Merge branch 'master'

Looks good.

• make kvatop handle dpcpu/vnet addresses properly

In D21555#473306, @jhibbits wrote:

This is very specific to AIM64 HPT. Can you rename it to kvm_..._hpt.c, or something, and add another key to the header to probe against for the particular pmap implementation? I'll want to add Book-E support, as well as AIM Radix when we do finally get radix stabilized.

[PPC64] libkvm minidump refactoring

• Avoid unnecessary page table copy
• dump_pmap_init() is now implemented only in moea64

In D21551#475431, @jhibbits wrote:

Can you add a key/sentinel into the dump structure to say what pmap it's using? libkvm will need it for properly decoding addresses, and that differential will also need to be updated to use the key and select a backend.

• Add mmu_name field to minidump header
• Move dump_pmap_init() to moea64
• Refactor dump_pmap() to allow copy elision

LGTM.

• [PPC64] Handle relocated kernels properly
• Merge branch 'master' into luporl-crashdump-libkvm

• Added startkernel, endkernel to minidump header

• Separate elf_common.h change
• Change R_PPC64_IRELATIVE to R_PPC_IRELATIVE in code

• Address reviews' comments

• Address jhibbits comments and add missing UMA bits

I'm not that familiar with this code, but overall the change looks good and seem to preserve the behavior of previous version, except for the part in the following comment.

In D21297#463780, @imp wrote:

In D21297#463778, @luporl wrote:

In D21297#463774, @imp wrote:

In D21297#463764, @luporl wrote:

I agree with @jhibbits: cas.c shouldn't be built for powerpc32, only powerpc64, but the change is OK.
If we go this way, then it is better to remove the (incorrect) conditional compilation of cas.c.
Else, powerpc/ofw/Makefile should be fixed.
This is the relevant part of it:

.if ${MACHINE_ARCH} == "powerpc64"
SRCS+=          cas.c
CFLAGS+=        -DCAS
.endif

It seems this is wrong when cross building to powerpc.
Perhaps it could be changed to something like this:

.if (!defined(TARGET_ARCH) && ${MACHINE_ARCH} == "powerpc64") || "${TARGET_ARCH}" == "powerpc64"
SRCS+=          cas.c
CFLAGS+=        -DCAS
.endif

But I'm also fine with just removing the if block.

TARGET_ARCH isn't a thing you can test anywhere outside of Makefile.inc1, so this suggestion can't be right. In the cross build case, we always set MACHINE_ARCH correctly.

Ok, but then the following use case is not supported, right?

cd /usr/src/stand && make TARGET=powerpc TARGET_ARCH=powerpc

Because the following command outputs "powerpc64":

cd src/stand
make buildenv TARGET=....

is what you need to do to cross build.

cd /usr/src/stand && make TARGET=powerpc TARGET_ARCH=powerpc -V MACHINE_ARCH

But when first performing a buildenv, then MACHINE_ARCH is correctly set:

cd /usr/src && make TARGET=powerpc TARGET_ARCH=powerpc buildenv
cd stand && make -V MACHINE_ARCH

If this is the case, the Makefile is already correct and no issues should occur on 32-bit systems.
Then this change would not be necessary, although it doesn't hurt.

It wouldn't change anything since the -m32 needed to do the cross build on powerpc64 wouldn't be included, and the wrong architecture compiler would be used if you tried it on, say, x86. We never test for TARGET or TARGET_ARCH outside of the Makefile.inc1 at the top level (well, there is an exception for gdb and maybe gcc, but the TARGET variable there isn't the same one and pre-dates the system's use of Makefile and will go away soon anyway).

In D21297#463774, @imp wrote:

In D21297#463764, @luporl wrote:

I agree with @jhibbits: cas.c shouldn't be built for powerpc32, only powerpc64, but the change is OK.
If we go this way, then it is better to remove the (incorrect) conditional compilation of cas.c.
Else, powerpc/ofw/Makefile should be fixed.
This is the relevant part of it:

.if ${MACHINE_ARCH} == "powerpc64"
SRCS+=          cas.c
CFLAGS+=        -DCAS
.endif

It seems this is wrong when cross building to powerpc.
Perhaps it could be changed to something like this:

.if (!defined(TARGET_ARCH) && ${MACHINE_ARCH} == "powerpc64") || "${TARGET_ARCH}" == "powerpc64"
SRCS+=          cas.c
CFLAGS+=        -DCAS
.endif

But I'm also fine with just removing the if block.

TARGET_ARCH isn't a thing you can test anywhere outside of Makefile.inc1, so this suggestion can't be right. In the cross build case, we always set MACHINE_ARCH correctly.

Looks good to me.

I agree with @jhibbits: cas.c shouldn't be built for powerpc32, only powerpc64, but the change is OK.

@jhibbits, this last change addresses your last comment (moving VSX code to _vsx.S files) and also adds ifunc support.

[PPC64] Optimize bcopy/memcpy/memmove

Commandeering to address issues and use ifunc to decide whether VSX should be used.

• Use ifunc to choose best implementation based on running system

Taking over to add ifunc support, which will make it possible to have the optimized strcpy version and avoid breaking POWER5 and earlier.

In D21131#459452, @jhibbits wrote:

Looks good. Can the same change apply to powerpc?

• [PPC64] strncpy - fix rtld crash

• [PPC64] strncpy - fix rtld-libc build issue

In D20827#458843, @jhibbits wrote:

Thanks for checking. Looks good. I assume you tested on bare metal, too?

This last change fixes the previous "dst not always zeroed" issue and adds ifunc support to strncpy, so that the optimized version is selected on ISAs >= 2.05 while others can use the fallback implementation in C.

• [PPC64] strncpy - fix 'dst' not zeroed issue
• Initial ifunc capable strncpy implementation

• Add missing space

Redo merge:

In D21102#458426, @markj wrote:

In D21102#458391, @luporl wrote:

Now the merge result should match the behavior seen in upstream.
Was this what you had in mind? Or is the plan to revert the local changes and apply this patch on it instead?

I think we should indeed revert the local changes and apply the two patches from upstream, but IMO it's fine to do that in a single commit. I believe that is effectively what you have done here?