We already run nda by default on all the !x86 architectures. Switch the
default to nda. nda created nvd compatibility links by default, so this
should be a nop. If this causes problems for your application, set
hw.nvme.use_nvd=1 in your loader.conf.
Sponsored by: Netflix
Stop requiring all of the PTEs to have the accessed bit set for superpage
promotion to occur. Given that change, add support for promotion to
pmap_enter_quick(), which does not set the accessed bit in the PTE that
it creates.
Since the final mapping within a superpage-aligned and sized region of a
memory-mapped file is typically created by a call to pmap_enter_quick(),
we now achieve promotions in circumstances where they did not occur
before, for example, the X server's read-only mapping of libLLVM-15.so.
See also https://www.usenix.org/system/files/atc20-zhu-weixi_0.pdf
Reviewed by: kib, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40478
Some consumers, e.g., swcr_encdec(), may call crypto_cursor_segment()
after having advanced the cursor to the end of the buffer. In this case
I believe the right behaviour is to return NULL and a length of 0.
When this occurs with a CRYPTO_BUF_VMPAGE buffer, the cc_vmpage pointer
will point past the end of the page pointer array, so
crypto_cursor_segment() ends up dereferencing a random pointer before
the function returns a length of 0. The uio-backed cursor has
a similar problem.
Address this by keeping track of the residual buffer length and
returning immediately once the length is zero.
PR: 271766
Reported by: Andrew "RhodiumToad" Gierth <andrew@tao11.riddles.org.uk>
Reviewed by: jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40428
While we had assigned dummy values so far to HE, correct the HW_MAC_CAP3
values to avoid compile time errors of drivers when shifting values out
of range.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Given https://reviews.freebsd.org/D34318 was abandoned add an empty
of.h dummy header file to at least avoid #include errors and avoid
covering those #include with CONFIG_OF.
MFC after: 10 days
In 5a9a0d7803 we omitted the initialization
of the per-hw txq settings. Fix this.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Fixes: 5a9a0d7803
Under certain circumstances a hw_scan may be downgraded to a software
scan. Handle these situations better and make sure we free resources
in all cases once. [1]
Also leave a note about scanning all bands (or we would have to switch
bands manually).
In both cases hardware doing and driver saying seem not entirely
consistent for all and all firmware.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reported by: imp [1]
Implement timer_{delete,shutdown}_sync(), which do not seem to require
anything additional to the already existing del_timer_sync().
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D40124
L_LINT macro is used with negative numbers [i.e.
L_LINT(time_freq, -MAXFREQ)], it could cause undefined
behavior. It should be similar to the L_RSHIFT(v, n) macro.
MFC after: 2 weeks
Reviewed by: cy
Pull Request: https://github.com/freebsd/freebsd-src/pull/769
Signed-off-by: Dmitriy Alexandrov <d06alexandrov@gmail.com>
This is a mapping from ID register value to offset in struct cpu_desc.
These registers may be needed with future architecture revisions either
by userspace or by bhyve.
Sponsored by: Arm Ltd
We do not want or need to propagate the error from fetching file info
when determining the file status. It could cause open(2) and similar
calls to fail when trying to access devices.
Obtained from: Juniper Networks, Inc.
So over the past few weeks we have found several bugs and updated hybrid pacing to have
more data in the low-level logging. We have also moved more of the BBlogs to "verbose" mode
so that we don't generate a lot of the debug data unless you put verbose/debug on.
There were a couple of notable bugs, one being the incorrect passing of percentage
for reduction to timely and the other the incorrect use of 20% timely Beta instead of
80%. This also expands a simply idea to be able to pace a cwnd (fillcw) as an alternate
pacing mechanism combining that with timely reduction/increase.
Reviewed by: tuexen
Sponsored by: Netflix Inc
Differential Revision:https://reviews.freebsd.org/D40391
With 14 coming, we no longer need to generate the $FreeBSD$. We can
likely MFC that to 13 as well.
MFC After: 2 weeks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39879
Due to fxsave area is os independent reimplement fxsave handmade code
using copying of a whole area.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D40443
MFC after: 2 weeks
Add a skeleton implementation of rhashtable in order to keep an
upcoming wireless driver compiling. We'll implement it as soon as
we get there.
MFC after: 10 days
Reviewed by: emaste (previous version before his suggested changes)
Differential Revision: https://reviews.freebsd.org/D40176
Given we do not seem to support ioremap() do not support the "devm"
version either and simply return NULL, which means we do not have
to keep track of the memory to be freed on device free later.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D40173
It seems struct msi_desc is setup differently (or was changed) compared
to how we added it a while ago. Catch up in order to keep drivers
directly accessing fields compiling.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D40175
Add another PCI alias to our native defines for a wireless driver.
MFC after: 10 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D40247
Add a struct_group() macro needed by a wireless driver.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D40138
Add a wrapper for ktime_get_real_ts64() used by a wireless driver.
MFC after: 10 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D40246
The amd64-gcc12 build was failing with `error: 'devctl_systems' defined
but not used`. Just move it to the C file where it's used.
PR: 271903
Sponsored by: The FreeBSD Foundation
We only need this during boot. Allocate the array before starting CPUs
to reduce the memory usage.
Reviewed by: Zach Leaf <zachary.leaf@arm.com>
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40433
To help moving to a dynamically allocated cpu_desc array reduce the
places we use it directly and create a pointer that is passed in to
functions that read it.
Reviewed by: Zach Leaf <zachary.leaf@arm.com>
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40392
If a debugger detaches from a process that has a new thread that has
not yet executed, the new thread will raise a SIGTRAP signal to report
it's thread birth event even after the detach. With the debugger
detached, this results in a SIGTRAP sent to the process and typically
a core dump. Fix this by clearing TDB_BORN from any new threads
during detach.
Bump __FreeBSD_version for debuggers to notice when the fix is
present.
Reported by: GDB's testsuite
Reviewed by: kib, markj (previous version)
Differential Revision: https://reviews.freebsd.org/D39856
Vmbus_synic_setup() is invoked via vmbus_intrhook -> vmbus_doattach
-> smp_rendezvous. On !EARLY_AP_STARTUP (e.g., aarch64), SMP isn't
functional in intrhooks and smp_rendezvous() will just call
vmbus_synic_setup() on the boot processor. There's nothing that will
initialize the pcpu data on every other AP.
To fix it we need to use SI_SUB_SMP for vmbus_doattach(). With this
patch the vmbus interrupt should work on all arm64 cpus on HyperV.
Reported by: kevans
Reviewed by: kevans, whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Obtained from: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D40279
While there, also make MODULE_PNP_INFO to reflect that the device
description is provided.
Reported-by: jrtc27
Reviewed-by: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D40430
Prepare the cubic congestion control module to better align with
the specifications in RFC8312bis.
Rename a few cubic state variables to the variable names found in
the RFC8312bis specification. This makes the code more understandable
for someone reading the RFC and the code. It also makes the variable
naming convention more uniform. Add some variables needed subsequently.
No functional change.
Submitted By: Bhaskar Pardeshi, VMware Inc.
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D40436
Both Windows (TcpMaxDataRetransmissions) and Linux (tcp_retries2)
allow to restrict the maximum number of consecutive timer based
retransmissions. Add that same capability on a per-VNet basis to
FreeBSD.
Reviewed By: cc, tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D40424
In the Hyper-V drivers we need to allocate buffers shared between the
host and guest. This memory has been allocated with bus_dma, however
it doesn't use this correctly, e.g. it is missing calls to
bus_dmamap_sync. Along with this on arm64 we need this memory to be
mapped with the correct memory type that bus_dma may not use.
Switch to contigmalloc to allocate this memory as this will correctly
allocate cacheable memory.
Reviewed by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40227
The pfil hook may modify the packet, so before we check its length (to
decide if it needs to be fragmented or not) we should re-read that
length.
This is most likely to happen when pf is reassembling packets. In that
scenario we'd receive the last fragment, which is likely to be a short
packet, pf would reassemble it (likely exceeding the interface MTU) and
then we'd transmit it without fragmenting, because we're comparing the
MTU to the length of the last fragment, not the fully reassembled
packet.
See also: https://redmine.pfsense.org/issues/14396
Reviewed by: cy
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D40395
While if_epair has no issues doing this we should drop those packets
anyway, because it improves the fidelity of the automated tests.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D40397
