rc.suspend has gained an rcorder keyword recently. Document it alongside
the existing resume keyword.
Reviewed By: mhorne, Pau Amma <pauamma@gundo.com>
Differential Revision: https://reviews.freebsd.org/D40484
The debug options for hwpmc are not documented in detail anywhere, and
setting it up was error-prone the first time I had to figure it out (and
each time I've had to remember it). Add some explanation of the required
options and describe the kern.hwpmc.debugflags sysctl format.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40545
The option is a no-op otherwise, but this is not necessarily obvious.
Failing the compile gives the user a hint.
Reviewed by: jkoshy, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40544
- Make it clear that applications are not only encouraged to use the
pmc(3) library, but use of the hwpmc(4) interface directly is a
use-case we do not support
- Move the COMPATIBILITY section above PROGRAMMING API in hwpmc(4)
- Drop statements about the driver and library being "under development"
Reviewed by: jkoshy, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40543
Include some boilerplate similar to other section 4 man pages,
describing how to load the module at boot-time or include it in the
kernel.
Reviewed by: jkoshy, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40542
Support for these CPUs was removed in 2018 (e92a1350b5).
Reviewed by: jkoshy, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40541
This change exports interface capabilities using the standard
Netlink attribute type, bitset, and switches `ifconfig(8)` to use
it when displaying interface data.
Bitset comes in two representations. The first one is "compact",
where the bits are exported via two arrays - "mask" listing the
"valid" bits and "values, providing the values for those bits.
The second one is more verbose, listing each bit as a separate item,
with its name, id and value. The latter option is handy when submitting
update requests.
The support for setting capabilities will be added in the upcoming diffs.
Differential Revision: https://reviews.freebsd.org/D40331
Take kern.localbase into account with fallback to /usr/local and
also allow for LOCALBASE/etc/periodic.conf (similarly to what
many other utilities do).
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D40435
MFC after: 2 weeks
It is hard to reason about the contents of 'ifr' at any given time
as nearly every function sets random fields or pointers in this
structure.
Use local on-stack clean 'struct ifreq' for each function instead.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D40534
MFC after: 2 weeks
Replace several sequential searches for a segment that contains a
phyiscal address with a call to a function that does it by binary
search. In vm_page_reclaim_contig_domain_ext, find the first segment
to reclaim from, and reclaim from each subsequent appropriate segment.
Eliminate vm_phys_scan_contig.
Reviewed by: alc, markj
Differential Revision: https://reviews.freebsd.org/D40058
Add a basic emulation for the command and response buffer interface of
TPM devices. This commit only implements some CRB register and resets
them.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40456
At the moment, the emulation only opens a file descriptor to the TPM
device. Some subsequent commits will read and write from it.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40455
This struct will be used to implement various TPM emulations like a TPM
passthrough or a virtual TPM.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40454
The TPM version config node should always be set. If it's not set,
there's a bug in our code. An assertion is the correct way to check for
this.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40558
Don't allow access to the physical ASLS register. It contains a host
address which is meaningless for the guest. Additionally, it allows the
guest to safely rewrite this register.
This is the last commit required for GVT-d. Nevertheless, it might not
work due to missing firmware support.
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D26209
This makes the OpRegion accessible by the guest. However, the guest
doesn't know the address of the OpRegion. This will be fixed by an
upcoming commit.
The range of the OpRegion is added to the e820 table. This allows the
guest firmware to easily pick up this range and to reserve it properly.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40041
The OpRegion provides some configuration bits and ACPI methods used by
some Intel drivers. The guest needs access to it. In the first step,
we're reading it's address and size.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40040
This register contains a host physical address. This address is
meaningless for the guest. We have to emulate it and set it to a valid
guest physical address.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40060
The graphics stolen memory is only GPU accessible. So, we don't have to
copy any data to it as the guest will be unable to access it anyway. We
just have to allocate and reserve some memory. That's done by adding an
E820 entry for the graphics stolen memory. The guest firmware will pick
up the E820 and reserve this range.
Note that we try to reuse the host address as Intel states that newer
Tiger Lake platforms need this [1].
[1]
e28d6fbfdf/devicemodel/hw/pci/passthrough.c (L626-L629)
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40059
This is the first step to emulate the graphics stolen memory register.
Note that the graphics stolen memory is somehow confusing. On the one
hand the Intel Open Source HD Graphics Programmers' Reference Manual
states that it's only GPU accessible. As the CPU can't access the area,
the guest shouldn't need it. On the other hand, the Intel GOP driver
refuses to work properly, if it's not set to a proper address.
Intel itself maps it into the guest by EPT [1]. At the moment, we're not
aware of any situation where this EPT mapping is required, so we don't
do it yet.
Intel also states that the Windows driver for Tiger Lake reads the
address of the graphics stolen memory [2]. As the GVT-d code doesn't
support Tiger Lake in its first implementation, we can't check how it
behaves. We should keep an eye on it.
[1]
e28d6fbfdf/devicemodel/hw/pci/passthrough.c (L655-L657)
[2]
e28d6fbfdf/devicemodel/hw/pci/passthrough.c (L626-L629)
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40039
Don't emulate anything yet. Just check if the user would like to pass an
Intel GPU to the guest.
Reviewed by: jhb, markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40038
It doesn't seem particularly useful to have it enabled by default, and
it spits several dozen lines into the dmesg on a test system.
Reviewed by: andrew
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40499
This appears to have been reserved for some kind of debug hook, but it's
not implemented and appears never to have been used.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40555
Use unprivileged loads to access user memory. Without this, the
accesses trap and various dtrace actions such as ustack() fail.
Reviewed by: andrew
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40540
It was used in one place and was added specifically to support dtrace
stack unwinding code. Write an equivalent expression using struct
unwind_state instead. No functional change intended.
Reviewed by: andrew
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40538
At least one downstream (CheriBSD) overrides -march here. Instead of
hard-coding the target, simply append the crypto extension to whatever's
already there.
No functional change intended.
Reviewed by: imp, andrew
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40537
The Emulex OneConnect NIC driver hasn't seen any commits other than ioctl
bug fixes (some severe) and sweeping commits since 2016. There is no
indication of new parts since 2014 or earlier. As such, deprecate the
driver with the aim of removing it prior to FreeBSD 15.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D40531
Replace direct stores to userspace addresses (never safe and broken on
modern CPUs) with a copyout. Use a static assert on the size to ensure
we don't overflow the field.
Reviewed by: markj, jhb
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D40519
The mpi3mr driver is written by Broadcom for the 9600 Series 24G PCIe
4.0 Tri-Mode RAID Adapters and eHBAs boards. This is 3rd-Generation
Tri-Mode x8 and x16 NVMe/SAS/SATA (although Broadcom/Avago did muddy the
waters by having multiple 2nd generations cards and referring to them
inconsistently).
Sponsored by: Netflix
This is Broadcom's mpi3mr driver for FreeBSD version 8.6.0.2.0.
The mpi3mr driver supports Broadcom SAS4116-based cards in the 9600
series: 9670W-16i, 9670-24i, 9660-16i, 9620-16i, 9600-24i, 9600-16i,
9600W-16e, 9600-16e, 9600-8i8e.
Initially only available as a module and on amd64/arm64, since that's
how it has been tested to date. Future commits will add it to the kernel
build and may expand the architectures it is supported on.
Co-authored-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Feedback-by: ken (prior versions)
Reviewed-by: imp
RelNotes: yes
Differential-Revision: https://reviews.freebsd.org/D36771
Differential-Revision: https://reviews.freebsd.org/D36772
A char array has an implicit NUL terminating it, which sizeof will
include, so we need to subtract 1 here. Printing a NUL can cause issues
for things like CI environments that aren't expecting it, especially
with recent Jenkins being stricter about not putting NUL in XML files.
Fixes: 3d222369ac ("Add a small tool, resizewin(1), to query terminal for window size")
MFC after: 1 week
In EC2, UEFI boots faster than BIOS, but not all amd64 instance types
support UEFI. AMIs need to have their boot mode designated, which
created a dilemma: Faster boots, or wider compatibility?
The recently added "uefi-preferred" option solves this: AMIs can be
marked to use UEFI where it's available, but fall back to BIOS on
instance types which do not support UEFI.
This uses bsdec2-image-upload 1.4.6, which recently landed in the
ports tree.
PR: 265697
Reviewed by: delphij, imp
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D40470
