Makes sense, LGTM.

I have two questions from the log file:

• All cores have similar perf/eff scores, which is good because it means all cores are doing similar work. Just want to verify that this is a expected result.
• Capacities should be scaled to 1024, the max one being 1024. But another issue see is that although this cpu has 6 P cores, 8 E cores, and 2 LP-E cores (22 threads in total), the capacity output doesn't match that classification.

I suggest keeping intelhfi sysctls even though we have hmp for the following reasons:

• Someone might want to debug hardware by reading values directly from the driver.
• Some people might not want to have HMP enabled in their kernel (e.g. they think hybrid scheduling is premature) but still want to observe values reported by intelhfi.

I should've tested, but I don't have direct access to machine right now. I'm trying to test this on bhyve instead, so please give me a few hours to work on that.

Return 0 not true

Also, what is WITHOUT_QEMU exactly? It's not documented under src.conf(5).

In D56837#1301961, @emaste wrote:

I did buildworld and buildkernel with no root though.

If you're explicitly passing NO_ROOT to the build you have to add WITHOUT_QEMU as well

Not sure why this happens since I did make vm-image with sudo. I did buildworld and buildkernel with no root though.

@emaste I get

Update description

add sponsored by to commit message

update man page for probe() and init() changes.

again, upload correct diff

upload correct patch

probe() and init() now returns int.

• The hmp_init() provider function is currently of type void and does not receive a return value. However, intelhfi's initialization allocates memory for things like the table cache area, and it can fail. Therefore, I'm thinking of implementing a mechanism where, if the intelhfi's _init() provider function fails, it returns a non-zero integer, and the HMP side calls hmp_default_init() to fall back into that state. What do you think?

LGTM!

In D56250#1295915, @jhb wrote:

Hmmm, cross debugging of cross-architectures does work on a FreeBSD host?

In D56547#1296220, @koinec_yahoo.co.jp wrote:

It seems that the current HMP mechanism doesn't allow for dynamic loading of providers like intelhfi using kldload.
I understand that the probe() and init() callbacks registered with HMP_PROVIDER_DECLARE are called only when HMP is initialized during the initial stages of kernel startup, and they evaluate which provider to use.

I understand that HMP providers don't require dynamic loading or unloading for their purpose, hence this approach. Is my understanding correct?

(Currently, intelhfi is being developed as a device driver, so changing to this approach would require some adjustments.)

Reflect provider and sysctl updates

Separate capacity and score providers and update sysctls

Update sysctl

In D56517#1294491, @rosenfeld_grumpf.hope-2000.org wrote:

There's currently four individual definitions of __maybe_unused the source tree, I'm just moving them to a central place as suggested by Ed.

Since we have [[maybe_unused]] in C23, could you elaborate why we need this to be in <sys/cdefs.h>?

LGTM

@koinec_yahoo.co.jp Could you please work on intelhfi based on this patch series?

Two things to add:

Reflect moving sysctl in parent revision

Move sysctl

Changes from D56547:

I overhauled the implementation which has quite different from this change. Superseded by D56546.

Duplicate of D56548 created by arc bug.

Display message on success

update commit message

update commit message

Since D56250 has changed to accomodate full dumps as well, rename this utility to dump2elf and update code and man page accordingly.

The point of this feature is to facilitate cross-platform debugging, thus this needs to accept full dumps as well. As a result, the name has changed from kvm_minidump_to_elf() to kvm_convert_to_elf(). Live kernel (/dev/mem) is still unsupported since kvm_walk_pages() doesn't work for that.

Use kvm_openfiles() instead

Duplicate of D56256.

update copyright notice

In D54674#1293419, @koinec_yahoo.co.jp wrote:

Also, based on my impression of the design of this module, do you have any ideas or approaches for integrating it into sched_ule?

Fix typo in license header

reflect @bz's suggestion on commit message

make hmp optional

In D44455#1287237, @koinec_yahoo.co.jp wrote:

Regarding the modification to save the acquired score values ​​from struct cpu_group to pcpu, I'd like to use the HMP (https://reviews.freebsd.org/D54674) API rather than creating a new, intelhfi's specific variable in pcpu for saving the values.
Are there any problems with this approach? If so, please let me know.

Rebase and fix

For now, let's share hmp_score_t for both capacity and score (same for macros like HMP_SCORE_SCALE). When we need to separate them (e.g. we confront architecture that has different type expectation for score and capacity), we can add capacity-specific types and values.

I think I'm not qualified for MFV: someone with trust (= commit bit) in the community should take this work instead.

Abandoning in favour of D56250 and D56256

Author isn't working on this anymore so I'm taking control of this revision.

Add coauthorship

This is improvement for D19253, but I moved this to libkvm so utilities like savecore(8) can invoke this easily.

After some considerations, I decided to abandon this revision based on the fact that kgdb(1) is a port and not in the base system. This means that if there is a need for this script, it should be provided via ports not through the base system. Also, I haven't heard any voice that wants this so it seems I'm trying to solve a problem that doesn't exist for now.

After talk with other FreeBSD dev at AsiaBSDCon, we concluded that score should be stored in pcpu structure, not in cpu_group for the following reasons:

LGTM, although we need approval from committer.

LGTM

Could you rebase main?

Could you rebase main?

In D44456#1277852, @koinec_yahoo.co.jp wrote:

In D44456#1272317, @minsoochoo0122_proton.me wrote:

Can we enable/disable the whole module when one or both of HMP and SMP aren't enabled? I don't see why we need to build this driver when HMP and SMP don't exist.

Thank you for the advice.
As you advised, there's no need to build this driver without specifying the SMP option, so I removed "#if defined(SMP)".

However, to prevent accidental builds, I've added a build error using "#error" if it's undefined, but I'm not sure if this is the correct practice. Any advice would be appreciated.
Also, I think it would be better to remove "#if defined(HMP)" when the ULE scheduler support and the HMP interface code support you separately posted are officially merged, but what about leaving it in during development?

Note that even without including opt_sched.h, if SMP is defined in the kernel configuration, the build error caused by #error will not occur.