In fact, wouldn't it be better to explicitly check the reported type to determine if the current shift is pkg_id_shift? From this PoV, the old code is correct for the leaf 0xb. And the code for leaf 0x1f would check that type is DieGroup and then explicitly assigns to pkg_id_shift.
Or at least the type can be cross-checked to ensure that microcode reports sensible data (I will not be surprised if some revisions appear to be buggy).

No this is wrong. The LoR reported is really a limitation of the witness and not the real exploitable LoR. It happens with any type of filesystem.

The test should be only enabled on 64bit userspace. I suspect even amd64 i386 compat would not allow allocating contig 2G due to AS fragmentation. armv7 should definitely fail to.

In D60035#1402282, @kib wrote:

Rebase on top of D60693

In D61384#1408168, @rcm wrote:

In D61384#1408071, @kib wrote:

Could this be done for NONE default policy as well?

It already is: without a PCB the default policy is never referenced, whether it is NONE or DISCARD. The helper name hid that, so the updated diff drops the helper. With a PCB the reference stays for both, because the PCB caches the policy; I would do that case as a follow-up.

There should be two 'files' created by the detected hang:

	debugfs_create_file("i915_error_state", 0644, minor->debugfs_root, i915,
			    &i915_error_state_fops);
	debugfs_create_file("i915_gpu_info", 0644, minor->debugfs_root, i915,
			    &i915_gpu_info_fops);

Is debugfs converted to sysctls on FreeBSD? Anyway, these are the things to look at, they were the useful source of data when I debugged i915 in drm2 times.

In D59883#1408208, @emaste wrote:

Yes I have patched drm-kmod: https://github.com/emaste/drm-kmod/commit/b686b798555c4faf4d20673f167b6559ef841c6e
This is in my WIP tree which has many other changes; I can try to reproduce on just main + these patches later on.

Hmm, I think now that if the problem is _GPU_ hanging then this patch cannot have any influence on it GPU does not share page tables with CPU, and the patch only modifies how the aliased mappings are established. There is something else going on.

In D59883#1408205, @emaste wrote:

In D59883#1408204, @kib wrote:

In D59883#1407609, @emaste wrote:

I am currently running this patch on my main laptop

You need to use swap to really test the patch, as in cause the machine to swap.

Indeed. I still observe GPU hangs with this patch when swap gets used.

In D59883#1407609, @emaste wrote:

I am currently running this patch on my main laptop

Could this be done for NONE default policy as well?

Sorry, I do not follow. This was already committed as 1a4c2eedad5bd62c4ec3cdda276bf4579ecab6c6, no?

In D58851#1407987, @rmacklem wrote:

Now I'm wondering about userland/O_DIRECT?

Would it be possible to make these helpers wire
down pages for a userspace buffer so that the
RDMA RPC can transfer them directly?
(This I can use in the client, if it isn't too hard to do.)

a.out is only supported on amd64. It is i386 as well, but i386 is going out.

I like this, but I have a small request. I am curious if you agree with it.