Some more uses for ifuncs on x86.

[markj]

I was able to boot with this change on i386 and amd64, using D16748, D16749, D16750. e.g., on i386 we have:

(kgdb) disas sf_buf_invalidate
Dump of assembler code for function sf_buf_invalidate:
   0x00e1b5a0 <+0>:     push   %ebp
   0x00e1b5a1 <+1>:     mov    %esp,%ebp
   0x00e1b5a3 <+3>:     push   %esi
   0x00e1b5a4 <+4>:     sub    $0x10,%esp
   0x00e1b5a7 <+7>:     mov    0x8(%ebp),%esi
   0x00e1b5aa <+10>:    mov    0x10(%esi),%eax
   0x00e1b5ad <+13>:    mov    %eax,-0x8(%ebp)
   0x00e1b5b0 <+16>:    mov    0x14(%esi),%eax
   0x00e1b5b3 <+19>:    lea    -0x8(%ebp),%ecx
   0x00e1b5b6 <+22>:    mov    %ecx,0x4(%esp)
   0x00e1b5ba <+26>:    mov    %eax,(%esp)
   0x00e1b5bd <+29>:    movl   $0x1,0x8(%esp)
   0x00e1b5c5 <+37>:    call   0xe0c8b0 <pmap_qenter>
   0x00e1b5ca <+42>:    mov    0x14(%esi),%eax
   0x00e1b5cd <+45>:    lea    0x1000(%eax),%ecx
   0x00e1b5d3 <+51>:    mov    %ecx,0x4(%esp)
   0x00e1b5d7 <+55>:    mov    %eax,(%esp)
   0x00e1b5da <+58>:    call   0xe0bf50 <pmap_invalidate_cache_range_selfsnoop>
   0x00e1b5df <+63>:    add    $0x10,%esp
   0x00e1b5e2 <+66>:    pop    %esi
   0x00e1b5e3 <+67>:    pop    %ebp
   0x00e1b5e4 <+68>:    ret

[markj]

sys/dev/drm2/i915/intel_ringbuffer.c

474

Why force?

1105

Also here.

[kib]

sys/dev/drm2/i915/intel_ringbuffer.c

474

Non-forced version does nothing if CPU supports self-snoop, which are practically all Intel CPUs from PIII or P4, not sure exactly. There, the intent is to actually flush the CPU cache since older Intel GENs have non-coherent hardware. So the force version is required, this is a bug from times of my GEM porting.

[alc]

sys/amd64/amd64/pmap.c

2223–2226

This comment has been deindented, so reflowing it might save a line.

2260

This looks weird even if it is correct. Specifically, it looks like back-to-back invalidations. I would suggest renaming this function, perhaps, pmap_invalidate_cache_check_alignment().

[kib]

Handle Alan' comments.