Thanks for spotting this!

I *think* this will be fine if the equivalent code moves to PPC nexus (where it came from in the first place long ago).

Looks good to me, assuming it works anyway.

Overtaken by events long ago.

Looks good to me. Thanks! There are probably more instances of this kind of thing lying around.

Nope, that's broken too in the same way:

This update doesn't actually work, though it does build:

Thanks, fixed 0/1->false/true.

More diff context, no functional changes.

Fix some fat-fingering and rename an argument to better reflect what it does.

Instead of adjusting parameters when generating VM images, adjust makefs to make free inodes when making free space. Relevant code copied from newfs(8).

So makefs(8), by default, creates a file system that can exactly hold the input tree (no extra space, no extra inodes, no extra anything). If we change the defaults in makefs(8), it seems like there are a few options:

I should also mention: one other path here is just to delete loader.kboot, since I'm not really sure it's useful. Even my PS3 loads the kernel directly from petitboot these days.

Thanks! This looks basically sane. I'll try to smoke-test it in the next few days; if I don't report back by Wednesday, treat this comment as approval.

Fix missing newline.

In D29068#651177, @rgrimes wrote:

This is a move in the right directions, at least this is state created by the installer.

We could also have makefs use expand_number(3) instead. Apologies for breakage!

This patch looks good to me from a technical point of view. I have no opinion on /boot/efi vs. /efi, so won't comment on the ultimate merits of the change, but you're welcome to include a "Reviewed by:" from me if this goes in.

Just committed this. I agree about 13.0 -- I was planning to merge to stable/13 after 13.0 has branched and smoke-test this in HEAD for a bit in the meantime.

Now tested and working, with UFS and ZFS, including multi-disk ZFS setups. In principle ready for commit.

Now does ZFS (including redundant setups) as well. Still not fully tested.

@imp any thoughts on the gmirror solution for ZFS? I think it solves 95% of the update issues and shouldn't be too bad to implement.

Just to be pedantic: We actually *do* have /boot as separate on some systems (e.g. recent powerpc64), but those systems are mutually exclusive with EFI systems. I have a mild preference /boot/efi, but it doesn't really matter much so long as we pick something -- the status quo is it not being mounted *at all*, so reliability of mounting or whatever is obviously a second-order issue.

In D15243#545983, @jhibbits wrote:

So, HTM is removed in PowerISA 3.1 and it's broken on POWER9. Is it even worth doing at this point? I'm inclined to abandon this.

Do we know all supported 32-bit AIM CPUs do the same things with DSISR? Otherwise, it looks good to me.

I have pretty mixed feelings about this approach. It only works for ofwbus children, not simplebus children, and canonicalizes a bunch of behaviors that I don't believe are standards (I'm in an airport departure lounge and don't have the spec handy). I'm also not really sure how it interacts with multipass etc. Could you elaborate a little more on the mechanism?

Fix fat-fginering; this is the right diff. It also sets Python to use Python 2, since a handful of scripts cared.

Updates from review.

OK, sounds good, thanks for testing!

Just make the page table size really small. There's a spill counter in the statistics; when it gets small enough, you should see it moving. If spill-handling doesn't work, and you have spills, everything breaks fast.

Does this break PTE spills? This code path historically was involved in re-adding PVOs to the hashed page table on faults if they got spilled.

That's a fair point. I've used them to assess hash-table spill rates when performance is not great, but not for a long time. We could also just delete them.

Yeah, counter(9) seems like the actual solution here.

Looks good to me; do you know how much this actually helps?