FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F13.3 2024-02-19T09:51:07Z 2024-02-19T09:51:07Z Andriy Gapon avg@FreeBSD.org 2024-01-30T06:45:01Z urn:sha1:75316a59b39ee83ed8b0e98597abb7baeea6a788 rdmsr_safe and wrmsr_safe can be called while pcb_onfault is already set, so the functions are modified to preserve the handler rather than resetting it before returning. One case where that happens is when AMD microcode update routine is executed on a stack where copyin / copyout was already active. Here is a sample panic message from a crash caused by resetting the handler: <118>Updating CPU Microcode... Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x11ed0de6000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80c2df03 stack pointer = 0x28:0xfffffe01ce4a4c70 frame pointer = 0x28:0xfffffe01ce4a4c70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 117 (logger) trap number = 12 panic: page fault cpuid = 3 time = 1681462027 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80615deb = db_trace_self_wrapper+0x2b/frame 0xfffffe01ce4a4830 kdb_backtrace() at 0xffffffff80943c77 = kdb_backtrace+0x37/frame 0xfffffe01ce4a48e0 vpanic() at 0xffffffff808f5fe5 = vpanic+0x185/frame 0xfffffe01ce4a4940 panic() at 0xffffffff808f5da3 = panic+0x43/frame 0xfffffe01ce4a49a0 trap_fatal() at 0xffffffff80c31849 = trap_fatal+0x379/frame 0xfffffe01ce4a4a00 trap_pfault() at 0xffffffff80c318b5 = trap_pfault+0x65/frame 0xfffffe01ce4a4a60 trap() at 0xffffffff80c30f5f = trap+0x29f/frame 0xfffffe01ce4a4b80 trap_check() at 0xffffffff80c31c29 = trap_check+0x29/frame 0xfffffe01ce4a4ba0 calltrap() at 0xffffffff80c07fd8 = calltrap+0x8/frame 0xfffffe01ce4a4ba0 --- trap 0xc, rip = 0xffffffff80c2df03, rsp = 0xfffffe01ce4a4c70, rbp = 0xfffffe01ce4a4c70 --- copyout_nosmap_std() at 0xffffffff80c2df03 = copyout_nosmap_std+0x63/frame 0xfffffe01ce4a4c70 uiomove_faultflag() at 0xffffffff8095f0d5 = uiomove_faultflag+0xe5/frame 0xfffffe01ce4a4cb0 uiomove() at 0xffffffff8095efeb = uiomove+0xb/frame 0xfffffe01ce4a4cc0 pipe_read() at 0xffffffff80968860 = pipe_read+0x230/frame 0xfffffe01ce4a4d30 dofileread() at 0xffffffff809653cb = dofileread+0x8b/frame 0xfffffe01ce4a4d80 sys_read() at 0xffffffff80964fa0 = sys_read+0xc0/frame 0xfffffe01ce4a4df0 amd64_syscall() at 0xffffffff80c3221a = amd64_syscall+0x18a/frame 0xfffffe01ce4a4f30 fast_syscall_common() at 0xffffffff80c088eb = fast_syscall_common+0xf8/frame 0xfffffe01ce4a4f30 --- syscall (3, FreeBSD ELF64, read), rip = 0x11ece41cfaa, rsp = 0x11ecbec4908, rbp = 0x11ecbec4920 --- Uptime: 41s And another one: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x800a22000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80b2c7ca stack pointer = 0x28:0xfffffe01c55b5480 frame pointer = 0x28:0xfffffe01c55b5480 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 68418 (pfctl) trap number = 12 panic: page fault cpuid = 4 time = 1625184463 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff805c1e8b = db_trace_self_wrapper+0x2b/frame 0xfffffe01c55b5040 kdb_backtrace() at 0xffffffff808874b7 = kdb_backtrace+0x37/frame 0xfffffe01c55b50f0 vpanic() at 0xffffffff808449d8 = vpanic+0x188/frame 0xfffffe01c55b5150 panic() at 0xffffffff808445f3 = panic+0x43/frame 0xfffffe01c55b51b0 trap_fatal() at 0xffffffff80b300a5 = trap_fatal+0x375/frame 0xfffffe01c55b5210 trap_pfault() at 0xffffffff80b30180 = trap_pfault+0x80/frame 0xfffffe01c55b5280 trap() at 0xffffffff80b2f729 = trap+0x289/frame 0xfffffe01c55b5390 trap_check() at 0xffffffff80b304d9 = trap_check+0x29/frame 0xfffffe01c55b53b0 calltrap() at 0xffffffff80b0bb28 = calltrap+0x8/frame 0xfffffe01c55b53b0 --- trap 0xc, rip = 0xffffffff80b2c7ca, rsp = 0xfffffe01c55b5480, rbp = 0xfffffe01c55b5480 --- copyout_nosmap_std() at 0xffffffff80b2c7ca = copyout_nosmap_std+0x15a/frame 0xfffffe01c55b5480 pfioctl() at 0xffffffff85539358 = pfioctl+0x4d28/frame 0xfffffe01c55b5940 devfs_ioctl() at 0xffffffff807176cf = devfs_ioctl+0xcf/frame 0xfffffe01c55b59a0 VOP_IOCTL_APV() at 0xffffffff80bb26e2 = VOP_IOCTL_APV+0x92/frame 0xfffffe01c55b59c0 VOP_IOCTL() at 0xffffffff80928014 = VOP_IOCTL+0x34/frame 0xfffffe01c55b5a10 vn_ioctl() at 0xffffffff80923330 = vn_ioctl+0xc0/frame 0xfffffe01c55b5b00 devfs_ioctl_f() at 0xffffffff80717bbe = devfs_ioctl_f+0x1e/frame 0xfffffe01c55b5b20 fo_ioctl() at 0xffffffff808abc6b = fo_ioctl+0xb/frame 0xfffffe01c55b5b30 kern_ioctl() at 0xffffffff808abc01 = kern_ioctl+0x1d1/frame 0xfffffe01c55b5b80 sys_ioctl() at 0xffffffff808ab982 = sys_ioctl+0x132/frame 0xfffffe01c55b5c50 syscallenter() at 0xffffffff80b30cc9 = syscallenter+0x159/frame 0xfffffe01c55b5ca0 amd64_syscall() at 0xffffffff80b309a5 = amd64_syscall+0x15/frame 0xfffffe01c55b5d30 fast_syscall_common() at 0xffffffff80b0c44e = fast_syscall_common+0xf8/frame 0xfffffe01c55b5d30 PR: 276426 Reviewed by: kib, markj Approved by: re (cperciva) (cherry picked from commit 486b265a8fb6b2aad37f2819fa04feacf8184d53) 2024-01-18T23:27:25Z Colin Percival cperciva@FreeBSD.org 2023-12-27T08:09:08Z urn:sha1:122ac7ca14244a865a2252c853f3601816398a95 Each bus gets 1 MB of address space; the actual base address for an MCFG bus range is the address from the table plus the starting bus number times 1 MB. The PCI spec is unclear on this point, but this change matches what Linux does, which is likely enough of a de facto standard regardless of what any de jure standard might attempt to say. Fixes: f54a3890b1f4 ("x86: Support multiple PCI MCFG regions") Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D43206 (cherry picked from commit 61e2161367bb4e68e603f53b1107f9427f988861) 2024-01-18T23:27:25Z John Baldwin jhb@FreeBSD.org 2023-11-29T18:32:39Z urn:sha1:0fb0306a89adf80f9d9af9044cb1f7af8a2f9155 In particular, this enables support for PCI config access for domains (segments) other than 0. Reported by: cperciva Tested by: cperciva (m7i.metal-48xl AWS instance) Reviewed by: imp Relnotes: yes Differential Revision: https://reviews.freebsd.org/D42828 (cherry picked from commit f54a3890b1f419d4a9edc99000efef52b9071b8f) 2024-01-18T23:27:25Z John Baldwin jhb@FreeBSD.org 2023-11-29T18:32:16Z urn:sha1:ac64ca647dfce284bba09104c65d5aff35be0ce5 Split out some bits of pcie_cfgregopen that only need to be executed once into helper functions in preparation for supporting multiple MCFG entries. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D42829 (cherry picked from commit 9893a4fd31fa4b2e19a7b9cf786f49b9de50b407) 2024-01-18T23:27:25Z John Baldwin jhb@FreeBSD.org 2024-01-18T23:19:11Z urn:sha1:d72a6e5310221822aeb336d84e38ab5ecd37ea64 This is a direct commit to stable/14 to preserve the ABI of the the pci_cfgregread and pci_cfgregwrite functions. The new routines are renamed to add a _domain suffix and macros map the new API to the new functions. Note: No API compatibility has been provided as modules in ports should not be using this internal API (normal PCI drivers use pci_read_config and pci_write_config with a device_t). (cherry picked from commit b5d2a06b2c4f50fd20774928602a3b5f0f27b127) 2024-01-18T23:27:22Z John Baldwin jhb@FreeBSD.org 2023-11-29T18:31:47Z urn:sha1:325e60b1e6527a6bdc9e9bca2c9ad5ff0b4f22fd This commit changes the API of pci_cfgreg(read|write) to add a domain argument (referred to as a segment in ACPI parlance) (note that this is not the same as a NUMA domain, but something PCI-specific). This does not yet enable access to domains other than 0, but updates the API to support domains. Places that use hard-coded bus/slot/function addresses have been updated to hardcode a domain of 0. A few places that have the PCI domain (segment) available such as the acpi_pcib_acpi.c Host-PCI bridge driver pass the PCI domain. The hpt27xx(4) and hptnr(4) drivers fail to attach to a device not on domain 0 since they provide APIs to their binary blobs that only permit bus/slot/function addressing. The x86 non-ACPI PCI bus drivers all hardcode a domain of 0 as they do not support multiple domains. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D42827 (cherry picked from commit 1587a9db92c03c738bb3f0fc5874b43c961e7c99) 2024-01-10T03:07:46Z Ceri Davies ceri@FreeBSD.org 2021-05-20T08:26:02Z urn:sha1:677a7402cea46eb253a241b443471ab072e2b6a7 While here, fix all links to older en_US.ISO8859-1 documentation in the src/ tree. PR: 255026 Reported by: Michael Büker <freebsd@michael-bueker.de> Reviewed by: dbaio Differential Revision: https://reviews.freebsd.org/D30265 (cherry picked from commit c1a148873d6488f1dac1cfb207a5927cef89888e) 2024-01-02T01:12:45Z Mark Johnston markj@FreeBSD.org 2023-12-26T01:39:39Z urn:sha1:bcced8754840857be3fe86540de796db4832fe5b Some implementations copy data to userspace, an operation which can in principle fail. In preparation for adding a __result_use_check annotation to copyin() and related functions, let implementations of cpu_set_upcall() return an error, and check for errors when copying data to user memory. Reviewed by: kib, jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D43100 (cherry picked from commit 7b68fb5ab2a276ccd081cc1a43cebf0fb315e952) 2023-12-25T03:58:03Z Konstantin Belousov kib@FreeBSD.org 2023-12-20T23:40:00Z urn:sha1:7f5511c698bc5d1f036067df9470d2045ffcdb9e (cherry picked from commit 7c8f16318499d2b05e916abd66148e5409284a9d) 2023-12-21T13:35:48Z Olivier Certner olce.freebsd@certner.fr 2023-09-11T14:18:30Z urn:sha1:7552dce0470201fc150b0fc7a2c1b5c452dc35ca Applies only to bare-metal Zen2 processors. The system currently automatically applies it to all of them. Tunable/sysctl 'machdep.mitigations.zenbleed.enable' can be used to forcibly enable or disable the mitigation at boot or run-time. Possible values are: 0: Mitigation disabled 1: Mitigation enabled 2: Run the automatic determination. Currently, value 2 is the default and has identical effect as value 1. This might change in the future if we choose to take into account microcode revisions in the automatic determination process. The tunable/sysctl value is simply ignored on non-applicable CPU models, which is useful to apply the same configuration on a set of machines that do not all have Zen2 processors. Trying to set it to any integer value not listed above is silently equivalent to setting it to value 2 (automatic determination). The current mitigation state can be queried through sysctl 'machdep.mitigations.zenbleed.state', which returns "Not applicable", "Mitigation enabled" or "Mitigation disabled". Note that this state is not guaranteed to be accurate in case of intervening modifications of the corresponding chicken bit directly via cpuctl(4) (this includes the cpucontrol(8) utility). Resetting the desired policy through 'machdep.mitigations.zenbleed.enable' (possibly to its current value) will reset the hardware state and ensure that the reported state is again coherent with it. Reviewed by: kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41817 (cherry picked from commit ebaea1bcd2eb0aa90937637ed305184b6fedc69b) Approved by: markj (mentor)