History log of /freebsd-current/sys/riscv/include/md_var.h
Revision Date Author Comments
# b7312c3d 31-Jul-2024 Mitchell Horne <mhorne@FreeBSD.org>

riscv: Svpbmt extension support

The Svpbmt extension provides specification of "Page-Based Memory
Types", or memory attributes (e.g. cacheability constraints).

Extend the pmap code to apply memory attributes when creating/updating
PTEs. This is done in a way which has no effect on CPUs lacking Svpbmt
support, and is non-hostile to alternate encodings of memory attributes
-- a future change will enable this for T-HEAD CPUs, which implement
this PTE feature in an different (incompatible) way.

Reviewed by: jhb
Tested by: br
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45471


# 2ff63af9 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .h pattern

Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/


# 8bebb786 25-May-2023 Mitchell Horne <mhorne@FreeBSD.org>

riscv: S-mode extension parsing

There are now several Supervisor-mode extensions that have entered the
'ratified' status, so begin parsing and reporting a few of these.

Recognize the following extensions:
- Sstc: stimecmp/vstimecmp CSR
- Svnapot: NAPOT* translation contiguity
- Svpbmt: page-based memory types
- Svinval: fine-grained TLB invalidation instructions
- Sscofpmf: performance counter overflow

*i.e. "naturally aligned power-of-2" page granularity

For now, provide globals for Sstc and Sscofpmf, as we will make use of
these in the near future.

Plus, update the copyright statement after my recent work on this file.

Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40240


# 7245ffd1 22-May-2023 Mitchell Horne <mhorne@FreeBSD.org>

riscv: MMU detection

Detect and report the supported MMU for each CPU. Export the
capabilities to the rest of the kernel and use it in pmap_bootstrap() to
check for Sv48 support.

Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39814


# 254e4e5b 28-Dec-2021 John Baldwin <jhb@FreeBSD.org>

Simplify swi for bus_dma.

When a DMA request using bounce pages completes, a swi is triggered to
schedule pending DMA requests using the just-freed bounce pages. For
a long time this bus_dma swi has been tied to a "virtual memory" swi
(swi_vm). However, all of the swi_vm implementations are the same and
consist of checking a flag (busdma_swi_pending) which is always true
and if set calling busdma_swi. I suspect this dates back to the
pre-SMPng days and that the intention was for swi_vm to serve as a
mux. However, in the current scheme there's no need for the mux.

Instead, remove swi_vm and vm_ih. Each bus_dma implementation that
uses bounce pages is responsible for creating its own swi (busdma_ih)
which it now schedules directly. This swi invokes busdma_swi directly
removing the need for busdma_swi_pending.

One consequence is that the swi now works on RISC-V which had previously
failed to invoke busdma_swi from swi_vm.

Reviewed by: imp, kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D33447


# 1adebe3c 17-Nov-2021 Mitchell Horne <mhorne@FreeBSD.org>

minidump: Parameterize minidumpsys()

The minidump code is written assuming that certain global state will not
change, and rightly so, since it executes from a kernel debugger
context. In order to support taking minidumps of a live system, we
should allow copies of relevant global state that is likely to change to
be passed as parameters to the minidumpsys() function.

This patch does the work of parameterizing this function, by adding a
struct minidumpstate argument. For now, this struct allows for copies of
the kernel message buffer, and the bitset that tracks which pages should
be dumped (vm_page_dump). Follow-up changes will actually make use of
these arguments.

Notably, dump_avail[] does not need a snapshot, since it is not expected
to change after system initialization.

The existing minidumpsys() definitions are renamed, and a thin MI
wrapper is added to kern_dump.c, which handles the construction of
the state struct. Thus, calling minidumpsys() remains as simple as
before.

Reviewed by: kib, markj, jhb
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D31989


# ab041f71 21-Sep-2020 D Scott Phillips <scottph@FreeBSD.org>

Move vm_page_dump bitset array definition to MI code

These definitions were repeated by all architectures, with small
variations. Consolidate the common definitons in machine
independent code and use bitset(9) macros for manipulation. Many
opportunities for deduplication remain in the machine dependent
minidump logic. The only intended functional change is increasing
the bit index type to vm_pindex_t, allowing the indexing of pages
with address of 8 TiB and greater.

Reviewed by: kib, markj
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing, Inc.
Differential Revision: https://reviews.freebsd.org/D26129


# 0a0f40c7 14-Nov-2019 Mitchell Horne <mhorne@FreeBSD.org>

Add missing files from r354720

MFC with: r354720
Differential Revision: https://reviews.freebsd.org/D22326


# ffedb98b 10-Jun-2019 Mitchell Horne <mhorne@FreeBSD.org>

RISC-V: expose extension bits in AT_HWCAP

AT_HWCAP is a field in the elf auxiliary vector meant to describe
cpu-specific hardware features. For RISC-V we want to use this to
indicate the presence of any standard extensions supported by the CPU.
This allows userland applications to query the system for supported
extensions using elf_aux_info(3).

Support for an extension is indicated by the presence of its
corresponding bit in AT_HWCAP -- e.g. systems supporting the 'c'
extension (compressed instructions) will have the second bit set.

Extensions advertised through AT_HWCAP are only those that are supported
by all harts in the system.

Reviewed by: jhb, markj
Approved by: markj (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20493


# 8d7e7a98 17-Dec-2015 Ruslan Bukin <br@FreeBSD.org>

Import RISC-V machine headers. This is a minimal set required to compile
kernel and userland.

Reviewed by: andrew, imp, kib
Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D4554