This approach looks weird, and I'm still unclear on what is really needed. More generally, I'd like to know why we have to do that, and I question its safety.

I have a couple of comments, but really we should first determine what to do with D54410, please see there.

In D48387#1251616, @obiwac wrote:

Fix issues pointed out by olce@ and apply some suggestions. Main changes:

• Change DSM order again to match Windows & Linux.
• Hold DSM set info in new struct dsm_set, so we can hold revision ID and DSM name.
• Print out DSM name & revision.
• Tunable to change Intel DSM set revision ID to use for debugging.

In D54409#1250752, @obiwac wrote:

Can totally use smp_rendezvous_cpus() for this instead of adding 2 new IPIs. I thought I had run into a problem using rendezvous when I first implemented this, but I just tried it again and see no problem doing it this way.

Ah, sorry... I'm pretty sure I had seen that problem during the review of D48734 at some point but forgot about it...

Oh, you're right, jails are more of an object than a subject.

We should also avoid the ugly pollution of struct acpi_softc (I completely understand this was done to get something working more quickly). Rather, let's define a new interface, called something like acpi_lpi (defined in a new acpi_lpi_if.m file), with two methods, acpi_lpi_enter() and acpi_lpi_exit(), which would be called before/after entering suspend-to-idle in acpi_EnterSleepState() (e.g., on all direct children of acpi; we'll see that in D48735). There are examples of interfaces under sys/dev/acpica, acpi_if.m and acpi_bus_if.m. The .m files are processed by sys/tools/makeobjops.awk. There's a bit more doc on kobj(9) (which device(9) relies on) in the Architecture Handbook.

Looks good (if you could move the comment about the sleep button, that would be great, see inline comment).

I'm pretty new to device management in FreeBSD, but it looks to me that allocating some memory + acpi_set_private() in DEVICE_PROBE() (here, acpi_spmc_probe()) and acpi_get_private() + deallocation in DEVICE_ATTACH() is a bad pattern, as it will cause memory leaks and in fact even panics in most cases if there are multiple candidate drivers. Since there is for now only a single driver, could you please instead fill up the acpi_spmc_softc directly and have acpi_spmc_probe() return 0 on success (which guarantees preservation of the softc up to DEVICE_ATTACH())? Let's also avoid possible bad pattern spreading by copy-pasting (incidentally, I see the same pattern in acpi_ec.c).

Looks good, except for one thing (see the inline comment in do_sleep()).

I'm not too sure about changing the type of a sysctl knob that has existed for a long time. The only compatibility problem that I can see doing this is potentially breaking reporting in an application that would call sysctl(3) (or sysctlbyname(3)) directly, passing an unitialized integer and then reading from it, as only the first byte would have been filled. Setting the boolean would still work (except on big-endian arches). The use of an old sysctl(8) utility is not affected.

"modified" => "going to be modified"

Cater to comments.

In D54553#1247786, @brooks wrote:

I'm also skeptical (and think both SMALL_SIZE and LARGE_SIZE are over aligned on e.g., armv7), but I'm wary of making functional changes here.

I fail to see any usefulness of CACHE_LARGE_PAD when it was introduced, which corresponds to aligning CACHE_ZONE_LARGE_SIZE to struct namecache_ts. So I'd just drop the corresponding roundup2(), with the benefit of not requiring a struct namecache_ts alignment for CACHE_ZONE_LARGE_SIZE (but then you have to change the corresponding static assertion).