Also update to use strsep(3) instead of strtok(3).
Most of this commit inadvertently ended up in r349914.
Coverity CID: 1357337
Approved by: markj
PR: 233038
Differential Revision: https://reviews.freebsd.org/D20918
In 2011, r218961 removed local code for rotating logs in favor of using the
rotate_log command in etc/rc.d/accounting. If the accounting service is
activated then subsequently de-activated in rc.conf but still remains active
in periodic.conf, then you get an error message every day in the periodic
jobs about being unable to rotate the logs.
With this change to use "onerotate_log", the log rotation will happen the
first time periodic daily runs after accounting was disabled but periodic
accounting was left enabled. After that happens once, the /var/account/acct
will no longer exist, which results in a different path through the periodic
code and no more error messages will appear (unless daily_show_badconfig is
set, in which case the admin will be told that periodic security processing
is enabled but the accounting file is not present).
This is only a partial fix for the problems reported in PR 202203.
PR: 202203
Bhyve can currently emulate two virtual NICs, namely virtio-net and e1000,
and connect to the host network through two backends, namely tap and netmap.
However, there is no interface between virtual NIC functionalities and
backend functionalities. As a result, the backend code is duplicated between
the two virtual NIC implementations and also within the same virtual NIC.
Also, e1000 cannot currently use netmap as a backend.
This patch introduces a network backend API between virtio-net/e1000 and
tap/netmap, to improve code reuse and add missing functionalities.
Virtual NICs and backends can negotiate virtio-net features, such as checksum
offload and TSO. If the backend supports the features, it will propagate this
information to the guest, so that the latter can make use of them. Currently,
only netmap VALE ports support the features, but support should be added to
tap in the future.
Reviewed by: jhb, bryanv
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20659
Use the proper size_t type to match strlen's return type. This is not
exploitable in practice as this parses command line arguments, which
are limited to well below 2^31 bytes.
This is a minimal change to address the reported issue; hda_parse_config
and the rest of this file will benefit from further review.
Reported by: Fakhri Zulkifli
Reviewed by: jhb, markj
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
For strings without quotes and escapes dstptr and srcptr are equal, so
zeroing *dstptr before checking *srcptr is not a good idea. In practice
it means that in -maproot=65534:65533 everything after the colon is lost.
The problem was there since r293305, but before r346976 it was covered by
improper strsep_quote() usage.
PR: 238725
MFC after: 3 days
Sponsored by: iXsystems, Inc.
Add the PCI HDAudio device model from the 2016 GSoC. Detailed information
can be found at
https://wiki.freebsd.org/SummerOfCode2016/HDAudioEmulationForBhyve
This commit has evolved from the original work to include Capsicum
integration. As part of that, it only opens the host audio devices once
and leaves them open, instead of opening and closing them on each guest
access. Thanks to Peter Grehan and Marcelo Araujo for their help in
bringing the work forward and providing some of the final techncial push.
Submitted by: Alex Teaca <iateaca@freebsd.org>
Differential Revision: D7840, D12419
NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance and just for ancient arm
hardware. NAND parts have evolved significantly from this early work
and little to none of it would be relevant should someone need to
update to support raw nand. This code has been off by default for
years and has violated the vnode protocol leading to panics since it
was committed.
Numerous posts to arch@ and other locations have found no actual users
for this software.
Relnotes: Yes
No Objection From: arch@
Differential Revision: https://reviews.freebsd.org/D20745
can be found at
https://wiki.freebsd.org/SummerOfCode2016/HDAudioEmulationForBhyve
This commit has evolved from the original work to include Capsicum
integration. As part of that, it only opens the host audio devices once
and leaves them open, instead of opening and closing them on each guest
access. Thanks to Peter Grehan and Marcelo Araujo for their help in
bringing the work forward and providing some of the final techncial push.
Submitted by: Alex Teaca <iateaca@freebsd.org>
Differential Revision: D7840, D12419
The seg_max value reported to the guest should be two less than the
host's maximum, in order to leave room for the request and the
response. This is analogous to r347033 for virtio_block.
We hit the "too many segments to enqueue" assertion on OneFS because
we increase MAXPHYS to 256 KB.
Reviewed by: bryanv
Discussed with: cem jhb rgrimes
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D20529
bsnmpd(1) main does that early on init and the connection is available
to all loaded modules
Event: Vienna Hackathon 2019
PR: 233431 , 221487
MFC after: 2 weeks
Otherwise duplicate messages can trigger a reinitialization of the
compression stream while the update thread is running. Also ensure
that the stream is initialized before the update thread may attempt
to use it.
PR: 238333
Reviewed by: cem, rgrimes
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20673
The vsc_rx_ready and the RX virtqueue is protected by the rx_mtx lock.
However, pci_vtnet_ping_rxq() (currently called only once after each
device reset) accesses those without acquiring the lock.
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20609
can be combined with configuring the period and duty cycle (the same ioctl
sets all 3 values at once, so there's no reason to require the user to run
the program twice to get all 3 things set).
The driver now names its cdev nodes pwmcX.Y where X is unit number and
Y is the channel within that unit. Change the default device name from
pwmc0 to pwmc0.0. The driver now puts cdev files and label aliases in
the /dev/pwm directory, so allow the user to provide unqualified names
with -f and automatically prepend the /dev/pwm part for them.
Update the examples in the manpage to show the new device name format
and location within /dev/pwm.
ioctl definitions and related datatypes that allow userland control of pwm
hardware via the pwmc device. The new name and location better reflects its
assocation with a single device driver.
Both virtio_net and e82545 network frontends have code to validate and
generate MAC addresses. These functionalities are replicated in the two
files, so we move them in a separate compilation unit.
Reviewed by: rgrimes, bryanv, imp, kevans
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20626
The VirtIO standard supports two schemes for notification suppression:
a notification enable bit and a more sophisticated one (event_idx) that
also supports delayed notifications. Currently bhyve fully supports
only the first scheme. This patch hides the notification suppression
internals by means of two inline routines, vq_kick_enable() and
vq_kick_disable(), and makes the code more readable.
Moreover, further improve readability by replacing the call to mb()
with a call to atomic_thread_fence_seq_cst(), which is already used
in virtio.c
Reviewed by: pmooney_pfmooney.com, bryanv
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20581
On vtnet device reset it is necessary to wait for threads to stop TX and
RX processing. However, the rx_in_progress variable (used for to wait for
RX processing to stop) is actually useless, and can be removed. Acquiring
and releasing the RX lock is enough to synchronize correctly. Moreover,
it is possible to reset the device while holding both TX and RX locks, so
that the "resetting" variable becomes unnecessary for the RX thread, and
can be protected by the TX lock (instead of being volatile).
Reviewed by: jhb, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20543
The NVMe CAM driver reports the PCIe Link Capability and Status for
devices. For emulated bhyve NVMe devices, this looks like:
nda0: nvme version 1.3 x63 (max x63) lanes PCIe Gen15 (max Gen15) link
The driver outputs this because the emulated device doesn't include the
PCIe Capability structure. The NVMe specification requires these
registers, so the fix is to add this set of capability registers to the
emulated device.
Note that PCI Express devices that are integrated into the Root Complex
(i.e. Bus 0x0) do not have to support the Link Capability or Status
registers. Windows will fail to start (i.e. Code 10) devices that appear
to be part of the Root Complex but report being a PCI Express Endpoint.
So also add a check to pci_emul_add_pciecap() to check if the device is
integrated and change the device type.
Reviewed by: imp, ken, araujo, jhb, rgrimes
Approved by: imp (mentor), ken (mentor), jhb (maintainer)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19904
This ensures that bhyve properly recognizes when decoding is disabled
for BARs on passthru devices. To properly handle writes to the
register, export a pci_emul_cmd_changed function from pci_emul.c that
the pass through device model invokes for config writes that change
PCIR_COMMAND.
Reviewed by: rgrimes
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20531
Rather than uncoditionally setting the MEMEN and PORTEN bits in
PCIR_COMMAND for PCI devices, set the respective bit when the first
BAR of a given type is added to the device. This more closely matches
what firmware does on bare metal.
BUSMASTEREN is still set unconditionally. Eventually this bit should
move into the device models as not all device models need this set.
Reviewed by: rgrimes
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20530
Coverity warned about gdb_write_mem sign extending the result of
parse_byte shifted left by 24 bits when generating a 32-bit memory
write value for MMIO. Simplify the code by using parse_integer
instead of unrolled parse_byte calls.
CID: 1401600
Reviewed by: cem
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D20508
bhyve has to virtualize the MSI-X table to trap reads and writes to
that table and map those to virtual interrupts that it maps real host
interrupts on to. For the pending-bit-array (PBA), bhyve passes
accesses from the guest directly to the hardware.
bhyve's virtualization of the MSI-X table is done by intercepting all
reads and writes to the BAR holding the MSI-X table. However, if the
PBA is stored in the same BAR as the MSI-X table, accesses to the PBA
portion of this BAR have to be forwarded to the real BAR.
However, in the case that the PBA was stored in a separate BAR and
it's offset in that separate BAR overlapped with the portion of the
MSI-X table BAR that the table used, the handlers for the table BAR
would incorrectly think that some accesses were PBA reads and writes.
This caused a crash in bhyve when it indirected a NULL pointer. Fix
this case by never trying to handle PBA access if the PBA lives in a
separate BAR.
Reported by: gallatin
Tested by: gallatin
Reviewed by: markj, Patrick Mooney
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D20523
I believe this was introduced in the original '-r' commit, r231911 (2012).
At the time, the scope was limited to a 1 second sleep. r332518 (2018)
added '-R', which increased the potential duration of the affected interval
(from 1 to N seconds) by permitting arbitrary restart intervals.
Instead, handle SIGTERM normally during restart-sleep, when the monitored
process is not running, and shut down promptly.
(I noticed this behavior when debugging a child process that exited quickly
under the 'daemon -r -R 30' environment. 'kill <daemonpid>' had no
immediate effect and the monitor process slept until the next restart
attempt. This was annoying.)
Reviewed by: allanjude, imp, markj
Differential Revision: https://reviews.freebsd.org/D20509
