In D57388#1320621, @pkubaj wrote:

I've just noticed that arch(7) should also be updated, but I'm not sure about one thing.

Architecture    float, double    long double
aarch64         hard             soft, quad precision
amd64           hard             hard, 80 bit
armv7           hard             hard, double precision
i386            hard             hard, 80 bit
powerpc         hard             hard, double precision
powerpcspe      hard             hard, double precision
powerpc64       hard             hard, double precision
powerpc64le     hard             hard, double precision
riscv64         hard             hard, quad precision

Obviously powerpc64le entry needs to be changed to quad. But I'm not really sure about whether it should be soft or hard. I mean, by default it will be soft, but if you build with CPUTYPE=power9 or newer, it's hard.

Closed by rGfd8d34ce

This really is funny, that we're working around broken IBM and Apple hardware by putting a quirk on the one conforming implementer.

Committed without linking to this review, rG1fc50a4e68.

Committed without attribution to the review, and can't just mark this closed.

In D56580#1295238, @markj wrote:

MFC after: 2 weeks

It looks like kexec was never MFCed?

In D51619#1295194, @markj wrote:

kldload is disallowed when securelevel > 0, but kexec_load()+reboot are not. That seems wrong--is it intentional?

If it boots, ship it!

Oops, sorry!

pvo->pvo_pte.slot is initialized to a hash mod moea64_pteg_count, then updated by the return of the H_ENTER hypercall. There are two possibilities here:

• Some kind of weird buffer overflow that scribbled onto the PVO
• A bug in Qemu

Looks fine to me, but I want Warner's opinion, too.

In D55132#1260359, @tpearson_raptorengineering.com wrote:

Updated to move this to a tunable. From what I can see MAXPHYS is only 128k, and is not available to drivers as a constant. As a result, we actually end up only allocating 8MB by default; if I missed something just let me know and I'll update the MAXPHYS to match...

LGTM. Good find! Approved.

In D15818#1259708, @fuz wrote:

@jhibbits has the following vga@0 node on firmware version 2.0:

vga@0 {

        assigned-addresses = <0x2000000 0x0 0x82010000 0x0 0xdf0000>;
        class-code = <0x30000>;
        depth = <0x20>;
        device-id = <0x2000>;
        device_type = "display";
        height = <0x300>;
        ibm,loc-code = "Backplane BMC";
        ibm,pci-config-space-type = <0x0>;
        interrupts = <0x1>;
        linux,boot-display;
        linux,opened;
        little-endian;
        phandle = <0x100003d6>;
        reg = <0xc0000 0x0 0x0 0x0 0x0>;
        revision-id = <0x30>;
        vendor-id = <0x1a03>;
        width = <0x400>;
};

Interesting, so mmu_radix depends on mmu_oea64 for bootstrap allocations, which in turn depends on its own phys_avail_count. Can you just put the extern declaration in mmu_oea64.h instead of having the extern in mmu_radix.c? mmu_radix.c already includes mmu_oea64.h, so that looks like the best place to put these shared variable declarations.

Do It!

rebooting != rebooting, but rather 'going through shutdown path'.

ofwfb needs the following properties to work correctly: