In D25798#581035, @markj wrote:

Sorry, I missed the reply somehow.

Don't other PIC drivers require a similar change then? i.e., why isn't the change in pic_ipi_send() instead?

Reviews D26128, D26129, D26130, D26131, D26132, D26133 deal with various arrays that explode in size when the last physical address becomes really huge.

In D25839#572447, @manu wrote:

LGTM.
I didn't knew this features, looks useful, is the variable reset by the
firmware ? (Or at least is supposed to be ?)

In D25798#571993, @markj wrote:

smp_rendezvous_cpus() uses a store-release to update smp_rv_waiters before
sending the IPI - why isn't that sufficient?

In D24066#529470, @grehan wrote:

It could well be worth investigating if the changes to UEFI to properly support PcdPciDisableBusEnumeration = TRUE are less invasive than allowing runtime BAR changes
(Intel ACRN has this as TRUE)

Updated with @cem's suggestions. Reposting for mentor approval.

In D22253#486458, @cem wrote:

Thanks!

Some initial tentative feedback and CCing kib@. Caveat, I haven't yet consulted any official documentation nor have I looked at the adjacent code to understand what it is doing, so my comments may just be uninformed. But, provisionally, I don't understand the motivation for some of this changeset.

In D22007#481175, @cem wrote:

Write Combining (WC) ... If the WC buffer is partially filled, the writes may be delayed until the next occurrence of a serializing event; such as, an SFENCE or MFENCE instruction, CPUID execution, a read or write to uncached memory, an interrupt occurrence, or a LOCK instruction execution.

The list is oddly specific and does not include 'mov to control registers,' but the "such as" language and cpuid example suggest to me that setting cr3 may be sufficient (if, as Konstantin points out, we actually did so).

ah sorry, here's the same patch, but with context restored.

This fixes a failure in the test suite. libvmmalloc was using more thread local storage in the inital-exec mode than rtld was reserving space for, causing the library to fail to load. Switching to the local-dynamic model fixes the issue and allows the test suite to pass.

In D21987#480367, @cem wrote:

Do Control Region SPAs have namespaces? I'm still fairly new to NFIT.

Likewise, thanks for the speedy reviews all.

• remove the machdep.intel_speed_shift tunable
• call out to hwpstate_intel's identify from est's
• show the cf_drv_dev's nameunit in dev.cpufreq.%d.freq_driver
• initialize the debug sysctl's sbuf w/o a drain function
• reject percentages outside [0, 100] in epp sysctl

• update cpufreq.4
• create hwpstate_intel.4
• guard intel_speed_shift with amd64 || i386
• undo dev => cf_dev
• some cf_drv_dev => dev
• some style fixes
• SYSCTL_ADD_STRING => SYSCTL_ADD_CONST_STRING
• SYSCTL_OUT thing

Sorry for the long delay here, I was waiting for the pmdk-1.6 release which incorporates some of our fixes upstream, and then went on vacation for the summer.

Index: stable/12

and also:

In D19976#463043, @rgrimes wrote:

The additional note on style(9) on variable order declaration is informative only, you can choose to fix at your option.

@rgrimes I believe I've addressed your comments from earlier. Would you mind taking a look at the new patch? Thanks.

In D21281#462741, @bcran wrote:

In D21281#462739, @scottph wrote:

Is this error case something that happens only sometimes? Fetching multiple files is something that has definitely worked for me before.

Yes, it only happens if a file can't be found. For example if it's asked to open /boot/foo, then it'll try /boot/foo and /boot/foo/ before failing. And the crash is only seen when booting over a secure connection: HTTP works fine, HTTPS crashes.

Is this error case something that happens only sometimes? Fetching multiple files is something that has definitely worked for me before.

Still working on fully reviewing this, but I noticed this one thing in testing.

Looks good to me

gdb_read_mem and gdb_write_mem could conceivably be factored together, though I'm not sure the complexity of that would be worth it. With or without that, this patch looks good to me.

In D19976#430794, @araujo wrote:

@scott.d.phillips_intel.com I'm wondering if sysutils/uefi-edk2-bhyve will work out of the box with these new options, or do we need to update this port as well?

reword comment about GETADDFLAGS macro

In D19975#429429, @rgrimes wrote:

A question to @jhb, should the order of the enum and the code updated to be in alphabetic order, in a separate review, it would only obfuscate the change to do it here.

bhyve.8, update .Dd, start sentences on a new line.

Note that the UEFI firmware used with this needs to have the flash variable driver added in, as in: https://github.com/freebsd/uefi-edk2/pull/8

Aside from Makefile formatting questions, this looks fine to me and makes a working UEFI binary for me.

• fix one more style(9) problem