Remove the i386 kernel and i386-only device drivers

[jhb]

Summary

This does not move any content from sys/x86 back to sys/amd64. A
few machine headers that are now amd64-specific may make sense to
move in the future.

This also removes all references to DEV_APIC which was only optional
on i386 and previously forced on for amd64. Now the #ifdef's are
removed and just assume DEV_APIC is always present.

[jhb]

I've split out all the other device driver removals into separate patches, and I've deferred removal of PAE #ifdef's to a followup commit. I could possibly split this up more if there are helpful things to split out, but the actual removal is hard to split further. It may be easier to review this on GitHub by finding the this commit in the list of commits here: https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel

[mchoo]

I opened a PR that moves i386 to EXTRA_ARCHES a while ago: https://github.com/freebsd/freebsd-src/pull/2052

Should we completely remove i386 from target before this change?

[kib]

sys/cddl/dev/fbt/x86/fbt_isa.c

54

I understand what 0xcc is (INT3) but I am curious what 0xf0 is? From what I remember, it is just a LOCK prefix, how it could be used for patching reliably? This is clearly unrelated to the diff.

sys/crypto/via/padlock.c

35

It is weird to have any such #ifdefs in via/padlock.c, the driver is x86 only.

82

Same.

sys/dev/bxe/bxe_stats.c

33

Does armv7 need this driver, in principle?

sys/dev/dcons/dcons_os.c

320

This is indeed broken on amd64.

sys/dev/virtio/virtqueue.c

569

Again unrelated to the patch, but 1. why use mb() 2. why only on x86?

sys/i386/include/pmap.h

143

Where is this stuff still needed?

sys/i386/include/pmap_pae.h

52

And this?

sys/i386/include/proc.h

37

Are these definitions still needed?

sys/x86/include/apicvar.h

122

124

5 can be reduced, perhaps some time later

sys/x86/pci/pci_bus.c

140

sys/x86/x86/local_apic.c

87

This value is really not a global selector; for amd64 it is ist which was mimicked to gsel to make it similar to i386. Might be worth passing 0 directly and removing the GSEL_APIC symbol altogether.

[kbowling]

sys/dev/e1000/e1000_osdep.h

141

This actually highlights the need to fix and use the kern_prefetch KPI but in general this and other drivers are used externally by things like Haiku. The effect here is negligible but I wonder if it's worth the to unifdef stuff like this versus leaving it.

[ziaee]

Note (probably to self ;P): we need to gc these from the hw-relnote template (doc/website/archetypes/release/hardware.adoc) after this lands.

[jhb]

In D60671#1391053, @mchoo wrote:

I opened a PR that moves i386 to EXTRA_ARCHES a while ago: https://github.com/freebsd/freebsd-src/pull/2052

Should we completely remove i386 from target before this change?

No, we are keeping the world, and I think we should not move it to EXTRA_ARCHES. i386 world remains Tier 2.

[jhb]

sys/cddl/dev/fbt/x86/fbt_isa.c

54

0xf0 is the old pop %cs that became the start of the 2-byte opcode map. That doesn't tell me why you would use it on i386 though. Some later comments imply we use a 2 byte marker on i386. I wonder if it is using UD2 (0x0f 0x0b)?

sys/crypto/via/padlock.c

35

Hmm, true, I might do a separate change to trim these outright. I can maybe do that before the actual removal of i386 bits?

sys/dev/bxe/bxe_stats.c

33

I'm not sure, I suspect it's some PCI card. It should perhaps just be using SIZEOF_LONG instead?

sys/dev/dcons/dcons_os.c

320

I'm not surprised, I think only firewire makes use of dcons(4). Presumably this should just use the dmap?

sys/dev/e1000/e1000_osdep.h

141

Hmmm, I did leave a few #ifdef's in for things I assumed were portable to other OS's. I assumed the osdep.h header was OS-specific however (note use of sx_assert a few lines up).

sys/dev/virtio/virtqueue.c

569

Yes, I am not sure why this is here at all. On architectures which need a fence, bus_dmamap_sync() should handle that. virtqueue doesn't use WC memory for queues AFAIK, so the barrier here seems pointless.

sys/i386/include/pmap.h

143

There are some userland bits (I think the zfs stuff in procstat) that need to include vm/pmap.h or the like and that needs some sort of 'struct pmap'. While I could have changed these to be empty, it seemed simpler to just leave them as-is.

Note that these are outside of #ifdef _KERNEL. :(

sys/i386/include/pmap_pae.h

52

There is some code in stand/ that needs <machine/pmap_pae.h>. I might not have purged everything possible from this header though.

sys/i386/include/proc.h

37

Hmmm, I thought this mattered for old-school kvm_getprocs() from a crashdump. I could try just making them empty, but code that includes <sys/proc.h> needs struct mdproc and struct mdthread to still exist.

sys/x86/x86/local_apic.c

87

Ot having some IST_xxx constants?

[markj]

sys/cddl/dev/fbt/x86/fbt_isa.c

54

The lock prefix is used to cause #UD to be raised. DTrace intercepts both #BP and #UD. I can't remember why both mechanisms exist(ed).

[kib]

sys/cddl/dev/fbt/x86/fbt_isa.c

54

But LOCK only faults if the next instruction is not RMW?

sys/x86/x86/local_apic.c

87

No, we use the numbers directly, in amd64/machdep.c. I see no point.

[markj]

sys/cddl/dev/fbt/x86/fbt_isa.c

54

Yes, I think it is used in a scenario where there is a pre-existing run of nops, created by the kernel linker. To redirect execution, the first nop is overwritten with the lock prefix, and a locked nop will trigger #UD.

I still do not understand why they (Solaris) did not instead overwrite the first nop with a breakpoint. That's what we do. Specifically, illumos still uses both tricks: breakpoints for FBT probes (where the first byte of a push %rbp; mov %rsp, %rbp prologue is overwritten with int3), and the lock prefix for SDT probes (where a hack is used to create a sequence of nops at each tracepoint during boot). On FreeBSD we use int3 for both types of probes.

[ngie]

Just a couple questions about sys/*crypto. If the headers came from OpenSSL, I think we're ok leaving them be..?

sys/crypto/blake2/config.h

1

Is this from OpenSSL?

sys/crypto/openssl/ossl_aes_gcm.c

1

Is this an OpenSSL provided header, or did we write this using logic from OpenSSL?

sys/crypto/openssl/ossl_sha512.c

2

Is this an OpenSSL provided header, or did we write this using logic from OpenSSL?