kgdb only uses the marked fields from dumppcb for initial frame reconstruction. This reverts commit 8f23665fed2fbaf4481359b4d2fcdd7b9feb40e3.
There are programs that depend on this structure (e.g. kernel debuggers) that breaks when the ABI changes. Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me> Reviewed by: kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D55149
This changes STACKALIGN to be type-preserving when operating on pointers. Reviewed by: brooks, kib Effort: CHERI upstreaming Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D54920
This completes the set of architectures implementing this feature. Move the calls to sched_instance_select() and link_elf_ireloc() later in initriscv(), after identify_cpu(0). There will be more information available to any resolver functions at this time. Reviewed by: imp, kib MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D55082
in kernel. Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Add an inline function hfence_gvma() for hfence.gvma instruction. Signed-off-by: Doongar Singh <doonbsd@gmail.com> Reviewed by: mhorne, markj Differential Revision: https://reviews.freebsd.org/D54857
We have reports that iwlwifi(4) works on RISC-V. While we can turn off full ACPI-specific files easily, intermittent code still relies on the header files to be present. In order to not need to completely #ifdef everything out we want to include acpi.h from LinuxKPI and as a result need this file. With this the iwlwifi(4) code compiles just fine and will do the right thing (given the functional ACPI parts are disabled/ unavailable). Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: mhorne, emaste Differential Revision: https://reviews.freebsd.org/D54691
Now that struct vm and struct vcpu are defined in headers, provide inline accessors. We could just remove the accessors outright, but they don't hurt and it would result in unneeded churn. As a part of this, consolidate definitions related to struct vm_eventinfo as well. I'm not sure if struct vm_eventinfo is really needed anymore, now that vmmops_run implementations can directly access vm and vcpu fields, but this can be resolved later. No functional change intended. MFC after: 2 months Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53586
Now that the machine-independent fields of struct vm and struct vcpu are available in a header, we can move lots of duplicated code into sys/dev/vmm/vmm_vm.c. This change does exactly that. No functional change intended. MFC after: 2 months Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53585
There is quite a lot of duplication of code between amd64, arm64 and riscv with respect to VM and vCPU state management. This is a bit tricky to resolve since struct vm and struct vcpu are private to vmm.c and both structures contain a mix of machine-dependent and machine-independent fields. To allow deduplication without also introducing a lot of churn, follow the approach of struct pcpu and 1) lift the definitions of those structures into a new header, sys/dev/vmm/vmm_vm.h, and 2) define machine-dependent macros, VMM_VM_MD_FIELDS and VMM_VCPU_MD_FIELDS which lay out the machine-dependent fields. One disadvantage of this approach is that the two structures are no longer private to vmm.c, but I think this is acceptable. No functional change intended. A follow-up change will move a good deal of machine/vmm/vmm.c into sys/dev/vmm/vmm_vm.c. MFC after: 2 months Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53584