Fixed in PR 259157/D32580.

Roping in @kevans since he's looked at this file recently. Kyle, since you are planning to switch amd64 to this KPI, should we try to have it use this as well? (rather than the ram pseudo-driver in sys/x86/x86/nexus.c)

Have used take the pcb into account as well, as otherwise it could exceed the total as the stack approaches its limit. Simplify the calculation of used by using total.

In D32581#735457, @kib wrote:

Doesn't this mean that in principle used might become larger than total? I think you need to base both on get_pcb_td() then.

Also did you considered using e.g. __builtin_frame_address(0) instead of &td?

Use get_pcb_td() for used as well.

Oh yes, and one question. Should sys/dev/hwpmc/pmu_dmc620.c be located elsewhere, similar to sys/arm64/arm64/cmn600.c? To me, it does not seem to belong in the hwpmc sub-directory.

Looks good, with some very minor comments.

I guess this is no longer required, but looks good regardless.

Handle markj's comment.

Thank you both for the discussion. I've studied the riscv and arm64 pmaps and it looks like the same assumptions hold - we will never free any PDE belonging to KVA - so I've applied the same checks on these platforms. From what I could see, arm and i386 should be safe as we only zero their PTEs.

These are used in D31990. I may convert some existing checks to use these macros as a follow-up change.

Handle review comments:

• Make loads atomic
• Sanity check the physical addresses of lowest-level PTEs before attempting to dump their contents

In D30726#742593, @ehem_freebsd_m5p.com wrote:

Other issue is the current locking during allocation is really gnarly. Notice how before calling xen_intr_alloc_isrc() the lock must be acquired for access to the x86 allocation variables. Once inside xen_intr_alloc_isrc() after the x86 variables are modified (xen_intr_auto_vector_count is incremented); the lock is released in order to call malloc(); then the lock is reacquired for modifying xen_intr_port_to_isrc[].

In D30187#732983, @cperciva wrote:

Is there anything boottrace gets you which TSLOG doesn't with my addition of userland TSLOG (https://reviews.freebsd.org/D32493)?

Improve the comment about when we issue an isb instruction.

What about fmal?

LGTM

I dislike this change, because truly it fixes nothing. It is just churn to appease a sense of code correctness, and code churn is not free.

In D32316#737883, @ray wrote:

In D32316#737876, @mhorne wrote:

It seems to me that only the changes to pmc_arm64_initialize() should be necessary, because it handles optional classes in the same way that pmc_intel_initialize() does, by passing the correct nclasses value to pmc_mdep_alloc().

Problem here is in static machdep class numbers. If classes will be initialized in incorrect order, adjusted ri will be incorrect. So that modification may save some time on debugging such issue for new optional classes with just little time in hwpmc(4) init.

It seems to me that only the changes to pmc_arm64_initialize() should be necessary, because it handles optional classes in the same way that pmc_intel_initialize() does, by passing the correct nclasses value to pmc_mdep_alloc().

The current version looks good to me. If you give me a day or two I can test on the FF's eMAG, and we should give @mmel a chance to make any objections known.

Rebase once more after some furthre light refactoring.

Hi, this is an interesting patch! Thanks for your effort.

In D32581#735397, @kib wrote:

As I noted in D32580, the FPU save area is allocated on the stack as well.

Take fpu save area into account as well.

In D30554#734629, @luporl wrote:

I've tested these changes on a PPC64 VM. With them, the virtual SCSI device fails to attach, making it impossible to mount root.
Below are the relevant dmesg messages:

ofwbus0: <Open Firmware Device Tree> on nexus0                                 
xicp0: <External Interrupt Presentation Controller> on ofwbus0
xicp0: Handling CPUs 0-31                                                      
vdevice0: <POWER Hypervisor Virtual Device Root> on ofwbus0                    
vscsi0: <POWER Hypervisor Virtual SCSI Bus> irq 16781571 on vdevice0
vscsi0: Could not allocate IRQ         
device_attach: vscsi0 attach returned 6

Indeed, this never landed in its entirety. I have it on a git branch somewhere...

I think I agree with you that the concept of an IRQ does not really belong to this layer, so tracking it in struct intr_event is 'wrong' in an academic sense. That said, there is clearly some practical benefit to doing so, as this patch complicates several callers which are currently quite simple. Part of the problem is the fact that we use different interrupt frameworks on different architectures, but this is the current state of things.