usage:
$ genl monitor <family> <multicats group>
this subcommand allows to monitor the message from a multicast group
of a given family when received.
If it knows how to parse the messages received it will dump the decoded
version, otherwise it will just inform a new message has been received
So far it only knows how to parse nlctrl notify messages, but the plan
to allow to make the parsing extensible via lua scripts
Differential Revision: https://reviews.freebsd.org/D40372
Client one is supposed to be assigend 198.51.100.2, but sometimes it
loses the race and the address ends up assigned to client two. When this
happened one would try to ping itself, which failed because the loopback
interface isn't up.
Ideally we'd generate static address assignments, but that would
complicate the test. Activate loopback interfaces so the test always
passes, and just try to ping both possible addresses.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add bsddialog(1) to bsdconfig(8). This can be considered an increment not a
replacement, `$DIALOG=dialog' restores dialog(1).
Differential Revision: https://reviews.freebsd.org/D37480
The EXAMPLES mis-comments caused an obnoxious amount of blank space
above SEE ALSO when rendered by mandoc to a terminal. The missing
termination of .Xo meant the description of -h ran together with the
subcommand synopsis. The other changes were generally ignored tags due
to context that simply don't need to be there.
Provoked by: grahamperrin
So when we call the fast_rsm retransmit path, we should always move
snd_nxt back up to snd_max. In fact during ack-processing if snd_nxt
falls behind it should be moved up there as well. Otherwise what
can happen is we have an incorrect mark on snd_nxt and incorrectly
calculate the offset when we go through the front path (which is
what skzyall was able to do) then when we go to clean up the
send the offset is all wrong and we crash.
Special thanks to Gleb for pointing out the problem and the email
that had the reproducer so I could find the issue.
Reported-by: syzbot+f5061a372f74f021ec02@syzkaller.appspotmail.com
Sponsored by: Netflix Inc
This function isn't generic and has a different signature on arm64. No
functional change intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40991
There is no HPET on arm64 and vm_get_hpet_capabilities() is not
implemented there. Move the vm_get_hpet_capabilities() call into
build_hpet(): I cannot see a downside, and doing so eliminates a global
variable and reduces the amount of code that needs to be conditionally
compiled. No functional change intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40990
Prior to initializing PCI devices, main() calls a number of
initialization routines, many of which are amd64-specific. Move this
list of calls to bhyverun_machdep.c. Similarly, add an MD function to
handle late initialization.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40989
- Make handling of x86 config options, like x86.x2apic, conditional to
amd64.
- Move fbsdrun_set_capabilities() and spinup_vcpu() to a new file,
bhyverun_machdep.c. The moved code is all highly x86 specific.
I'm not sure how best to handle the namespace. I'm using "bhyve_" for
MD functions called from MI code. We also have "fbsdrun_" for some MI
routines that are typically called from MD code. The file name is
prefixed by "bhyverun_".
Reviewed by: corvink
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40987
Add a BHYVE_GDB_SUPPORT make variable that can be set by per-arch
makefiles. When set, BHYVE_GDB is defined and can be used as a
preprocessor predicate. Use it to guard gdb stub calls in MI code.
The arm64 bhyve port currently does not have a functional gdb stub, but
that's not critical to landing the port, so this mechanism slightly
reduces the friction of adding support for a new platform.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40986
- The qemu_fwcfg interface, as implemented, is I/O port-based, but QEMU
implements an MMIO interface that we'll eventually want to port for
arm64.
- Retain support for I/O space PCI BARs, simply treat them like MMIO
BARs for most purposes, similar to what the arm64 kernel does. Such
BARs are created by virtio devices.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40741
The arm64 port does not implement VGA, so move the device model sources.
Compile framebuffer code only on amd64 for now, but do not move the
sources, as we ought to be able to add support later.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40740
Specifically, move IO-APIC, LPC and PIRQ routing code under amd64/.
Use ifdefs to conditionally compile related code in other files. In
particular, legacy PCI interrupt handling is now compiled only on amd64.
This is not too invasive, but suggestions for a more modular approach
would be appreciated.
I am not sure why qemu fwcfg handling is tied to LPC, and I suspect it
should be decoupled. In this commit I just apply an ifdef hammer, but
we will eventually want fwcfg on arm64 as well.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40739
These models register legacy PCI interrupts, which won't be supported in
the arm64 port. In principle it should be possible to make these models
work on arm64 with a bit of effort, so don't move the sources to the
amd64 subdirectory.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40738
This code is only invoked via MD vmexit handlers. No functional change
intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40737
Put it in amd64, since most of it is MD and won't be used on arm64. Add
a bit of glue to bhyverun.h to make CPU startup and shutdown work
without having to export more global variables. AP startup will be
reworked further in a future revision.
This makes bhyverun.c much more machine-independent.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40556
mptable and the e820 are both rather amd64-specific and can be moved
easily.
In the case of e820, move the registration with qemu_fwcfg into e820.c,
as it simplifies bhyverun.c a bit and I can't see any downsides.
No functional change intended.
Reviewed by: corvink, jhb, emaste
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40552
In preparation for an arm64 port, make an easy change which puts some
machine-dependent code in its own directory.
Going forward, code which is only used on one platform should live in a
MD directory. We should strive to layer modules in such a way as to
avoid polluting shared code with lots of ifdefs. For some existing
files this will take some effort.
task_switch.c and fwctl.c are an easy place to start: the former is very
x86-specific, and the latter provides an I/O port interface which can't
be used on anything other than x86. (fwcfg as implemented has the same
problem, but QEMU also supports a MMIO fwcfg interface.) So I propose
that we start by simply making those files conditional.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40501
read_config() and write_config() are externally visible, so give them
more descriptive names. No functional change intended.
MFC after: 1 week
Sponsored by: Innovate UK
Fixup a couple foo@user.noreply.github.com email addresses based other
information (either known FreeBSD user, known other commits with the
correct name, etc)
The AX88179A has two firmware modes, one of which is backward
compatible with existing AX88178A/179 driver. The active firmware mode
can be controlled through a register.
Update axge(4) man page to mention 179A support and ensure that, when
bound to a AX88179A, the driver activates the compatible firmware mode.
Reviewed by: markj
Pull Request: https://github.com/freebsd/freebsd-src/pull/854
MFC after: 1 week
Files under /var/db/freebsd-update are required during the upgrade
process, and to support rollback. They may be deleted if no upgrade is
in progress and rollback will not be required.
PR: 273601
Reviewed by: bcr
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42022
Both agp_backend.h and utsname.h have an implementation in common/
these days so the dummy headers are no longer needed.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
If we're evaluating a pfsync'd state (and have different rules on both
ends) our state may point to the default rule, which does not have
rpool.cur set. As a result we can end up dereferencing a NULL pointer.
Explicitly check for this when we try to re-construct the route-to interface.
Also add a test case which can trigger this issue.
MFC after: 3 days
See also: https://redmine.pfsense.org/issues/14804
Sponsored by: Rubicon Communications, LLC ("Netgate")
The Arm Branch Target Identification (BTI) extension guards against
branching to an unintended instruction.
To support BTI add the landing pad instructions to the SHA2 functions.
These are from the hint space so are a nop on hardware that lacks BTI
support or if BTI isn't enabled.
Reviewed-by: Allan Jude <allan@klarasystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Tino Reichardt <milky-zfs@mcmilk.de>
Signed-off-by: Andrew Turner <andrew.turner4@arm.com>
Closes#14862Closes#15339
After dbf7691999 (as indicated in that commit message) EEXISTS
errors may be seen. From current investigation that is due to the
single-VAP support in LinuxKPI 802.11 and the related calls to
mo_start() and mo_stop() and them being disabled in ic_parent()
currently. Calling mo_stop() in lkpi_ic_vap_delete() seems to
fix the problem and new VAPs (wlan interfaces) can be created again
after being destroyed.
Fixes: dbf7691999 ("improve lkpi_ic_vap_delete()")
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
[Why]
This function takes an offset and a length as argument, not a physical
address and a number of pages.
This misuse caused the `set_memory_*()` and
`arch_io_reserve_memtype_wc()` functions to return EINVAL.
Another problem was the fact that they returned errors as a positive
integer, whereas Linux uses negative integers.
[How]
Physical addresses and number of pages are converted to offset+length in
the `set_memory_*()` functions.
`arch_io_reserve_memtype_wc()` now calls `pmap_change_attr()` directly
instead of using `set_memory_wc()`.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42053
fbt computes incorrect instruction position for AArch64 kernel module symbol.
The issue is with the for loop, it does an extra increment of instr pointer
after the required instruction is found. Hence, a wrong instruction is
targeted for patching.
Signed-off-by: Igor Ostapenko <pm@igoro.pro>
Fixes: 980746e5cb ("fbt: simplify arm64 function-prologue parsing")
Reviewed by: markj
Pull Request: https://github.com/freebsd/freebsd-src/pull/855
MFC after: 1 week
While here report a sample result from running on Sapphire Rapids:
An access(2) loop slapped into will-it-scale, like so:
while (1) {
int error = access(tmpfile, R_OK);
assert(error == 0);
(*iterations)++;
}
.. operating on /usr/obj/usr/src/amd64.amd64/sys/GENERIC/vnode_if.c
In operations per second:
lockless: 3462164
locked: 1362376
While the over 3.4 mln may seem like a big number, a critical look shows
it should be significantly higher.
A poor man's profiler, counting how many times given routine was sampled:
dtrace -w -n 'profile:::profile-4999 /execname == "a.out"/ {
@[sym(arg0)] = count(); } tick-5s { system("clear"); trunc(@, 40);
printa("%40a %@16d\n", @); clear(@); }'
[snip]
kernel`kern_accessat 231
kernel`cpu_fetch_syscall_args 324
kernel`cache_fplookup_cross_mount 340
kernel`namei 346
kernel`amd64_syscall 352
kernel`tmpfs_fplookup_vexec 388
kernel`vput 467
kernel`vget_finish 499
kernel`lockmgr_unlock 529
kernel`lockmgr_slock 558
kernel`vget_prep_smr 571
kernel`vput_final 578
kernel`vdropl 1070
kernel`memcmp 1174
kernel`0xffffffff80 2080
0x0 2231
kernel`copyinstr_smap 2492
kernel`cache_fplookup 9246
This is a simple RTC driver for the rv3032 from Microcrystal.
Just the basic functionality is implemented (no timer, alarm etc ..).
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D41995
