Some SAS JBODs support zoning. This feature allows individual SAS
targets to be accessible by only some initiator ports. One application
would be connecting two servers to the same JBOD, but they wouldn't be
able to see each other's disks.
A zoned JBOD should also prohibit initiators from accessing SES elements
corresponding to inaccessible SAS targets. It reports that by setting
the element's status code to 0x8 (No Access Allowed).
The bug is that when doing "sesutil (fault|locate) all ...", sesutil
will attempt a ENCIOC_SETELMSTAT ioctl for every single element, even
the inaccessible ones. The enclosure will reject the command, the
kernel will return EINVAL, and sesutil will exit.
The solution is to check the element's status, and skip trying to set it
if the status is 0x8. But if the user actually supplied a ses ID, then
assume that he knows what he's doing and try to set it anyway.
PR: 270093
MFC after: 1 week
Sponsored by: Axcient
Reviewed by: mav, trasz
Differential Revision: https://reviews.freebsd.org/D39017
The Intel GOP driver checks the LPC IDs to detect the platform it's
running on. The GOP driver only works on the platforms it's written for.
Maybe other Intel driver have the same behaviour. For that reason, we
should use the LPC IDs of the FreeBSD host for GPU passthrough to work
properly.
We don't know if setting different LPC IDs have any side effect.
Therefore, don't use the host LPC IDs by default on Intel system. Give
the user the opportunity to modify the LPC IDs.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D28280
For compatibilty reasons, the old config values are still supported.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38403
Changing the PCI IDs is valuable in some situations. The Intel GOP
driver requires that some PCI IDs of the LPC bridge are aligned with the
physical values of the host LPC bridge. Another use case are oracles
virtio driver. They require different subvendor ID than the default one.
For that reason, create a helper which makes it easy to read PCI IDs
from bhyve config. Additionally, this helper ensures that all emulation
devices are using the same config keys.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38402
We previously attempted to emit Rock Ridge NM records only when the name
represented by the Rock Ridge extensions would actually differ. We would
omit the record for an all-upper-case directory name, however Linux (and
perhaps other operating systems) map names with no NM record to
lowercase.
This affected only directories, as file names have an implicit ";1"
version number appended and thus always differ. To solve, just emit NM
records for all entries other than DOT and DOTDOT .
We could continue to omit the NM record for directories that would avoid
mapping (for example, one named 1234.567) but this does not seem worth
the complexity.
PR: 203531
Reported by: Thomas Schmitt <scdbackup@gmx.net
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39258
This is a userland-only pointer that isn't relevant to the kernel and
doesn't belong in the ioctl structure shared between userland and the
kernel. For the kernel, the old structure for the ioctl is still
supported under COMPAT_FREEBSD13.
This changes vm_snapshot_req() in libvmmapi to accept an explicit
vmctx argument.
It also changes vm_snapshot_guest2host_addr to take an explicit vmctx
argument. As part of this change, move the declaration for this
function and its wrapper macro from vmm_snapshot.h to snapshot.h as it
is a userland-only API.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D38125
This replaces the 'struct vm, int vcpuid' tuple passed to most API
calls and is similar to the changes recently made in vmm(4) in the
kernel.
struct vcpu is an opaque type managed by libvmmapi. For now it stores
a pointer to the VM context and an integer id.
As an immediate effect this removes the divergence between the kernel
and userland for the instruction emulation code introduced by the
recent vmm(4) changes.
Since this is a major change to the vmmapi API, bump VMMAPI_VERSION to
0x200 (2.0) and the shared library major version.
While here (and since the major version is bumped), remove unused
vcpu argument from vm_setup_pptdev_msi*().
Add new functions vm_suspend_all_cpus() and vm_resume_all_cpus() for
use by the debug server. The underyling ioctl (which uses a vcpuid of
-1) remains unchanged, but the userlevel API now uses separate
functions for global CPU suspend/resume.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D38124
The formats for pmcstat(8)'s human-readable output are not part of its
user interface definition, and may change in the future. Highlight
this in its manual page.
Approved by: gnn (mentor)
Differential Revision: https://reviews.freebsd.org/D39249
The boot catalog pointer is a DWord, but we previously populated it via
cd9660_bothendian_dword which overwrote four unused bytes following it.
See El Torito 1.0 (1995) Figure 7 for details.
PR: 203531
Reported by: Coverity Scan
Reported by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed by: kevans
CID: 977470
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39231
These are not actually used by makefs (yet), but ought to match the
spec.
See RRIP 4.1.4 Description of the "NM" System Use Entry for details.
PR: 203531
Sponsored by: The FreeBSD Foundation
The bit definitions for the TF_* timestamp bits (TF_MODIFY, etc.) were
incorrect, and timestamps were written in the wrong order.
See RRIP 4.1.6 Description of the "TF" System Use Entry for details.
PR: 203531
Reported by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed by: jrtc27, kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39221
main() func contained both initialization and main loop logic.
This made certain operations like restarting problematic and
required dirty hacks in form of goto jumps.
This commit moves the main loop logic into daemon_eventloop(),
cleans up main, and makes restart logic clear: daemon_mainloop()
is run in a loop with a restart condition checked at the end.
Reviewed by: kevans
Pull Request: https://github.com/freebsd/freebsd-src/pull/699
It is illegal (UB?) to pass a shorter array to a function argument
that takes a fixed-length array. Do a runtime check for names that
are too long via strlen() instead.
Reviewed by: markj
Reported by: GCC -Wstringop-overread
Differential Revision: https://reviews.freebsd.org/D39211
As of commit 0bda8d3e9f ("vmm: permit some IPIs to be handled by
userspace") and commit 9cc9abf409 ("bhyve: create all vcpus on
startup"), we have a misbehaviour where AP vCPU threads spin until they
receive a SIPI. In particular, since they are "suspended", they simply
call the VMEXIT_DEBUG handler in a loop, but the handler is a no-op by
default.
This is tricky to fix since the gdb stub isn't aware of whether a given
vCPU is supposed to be running. For 13.2's sake, introduce a simple
workaround wherein the VMEXIT_DEBUG handler sleeps for a short period.
This ensures that host CPU usage remains sane when VMs are starting
without penalizing users of VMEXIT_DEBUG too much.
Reviewed by: corvink, jhb
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39174
Mountd can now be run in an appropriately
configured vnet jail.
This man page update adds some information
for this case.
This is a content change.
Reviewed by: markj
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D39168
Start breaking down big main()
Remove goto exit label and replace it with a function that does cleanup.
Comment re-worded by kevans@.
Pull Request: https://github.com/freebsd/freebsd-src/pull/694
Let the user decide if he wants to use bhyve's fwctl or qemu's fwcfg. He
can set the interface by adding a fwcfg option to bootrom:
-l bootrom,<path/to/rom>,fwcfg=bhyve
-l bootrom,<path/to/rom>,fwcfg=qemu
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38337
Fwcfg items without a fixed index are reported by the file_dir. They
have an index of 0x20 and above. This helper simplifies the addition of
such fwcfg items. It selects a new free index, assigns it to the fwcfg
items and creates an proper entry in the file_dir.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38336
This patch updates the information for "allow.nfsd"
and adds configuration information.
This is a content change.
Reviewed by: karels, markj, pauamma (manpages)
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D39033
If bread returns an error there is no bp to brelse. One of these
changes was taken from NetBSD commit 0a62dad69f62 ("This works well
enough to populate..."), the rest were found by looking for the same
pattern.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39069
Add missing brelse(bp). Without it the cache grows and we have a n^2
lookup. I'm not entirely sure why we read the block before we write it
back out, since the only side effect of that is to allocate memory,
clear the memory, read it in from disk, throw it away with the contents
of the file being written out. We likely should just do a getblk() here
instead, but even with all that, this takes the time it takes to create
a 150MB msdos fs image down from 5 minutes to 30 seconds.
Old: 317.663u 0.685s 5:18.34 100.0% 198+360k 0+19io 1009pf+0w
New: 7.330u 23.841s 0:31.17 100.0% 198+360k 0+250522io 4pf+0w
See code review for how we got this. tl;dr: netbsd move brelse
into bwrite and we picked up msdos code after that, but not the
move. That change should be picked up later.
Sponsored by: Netflix
Reviewed by: emaste
MFC After: 1 day (13.2 is coming fast)
Differential Revision: https://reviews.freebsd.org/D39025
The fact that most of the daemon's state is stored on the stack
of the main() makes it hard to split the logic smaller chunks.
Which in turn leads to huge main func that does a a lot of things.
struct log_params existed because some variables need to be passed
into other functions together.
This change renames struct log_params into daemon_state
and moves the rest of the variables into it. This is a necessary
preparation step for further refactroing.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/687
Use SHA256_Fd and SHA256_Data instead of home made equivalent.
wrap those functions into hash.c to avoid header collition between
openssl and libmd
Suggested by: kevans
OpenSSL 3.0 has deprecated the sha256 api, let's use libmd which has the
same API instead.
In order to avoid the collision in definitions (sha256.h cannot be
included in the same file as a file where openssl headers has been
included) let's move the sha256 related code in its own file
PR: 270023
Reported by: ngie
libcasper(3) is not used in bhyve. So move dependency to the appropriate
place.
Reviewed by: markj
MFC after: 1 week
Sponsored by: vStack
Differential Revision: https://reviews.freebsd.org/D38905
When using the --suspend and --checkpoint parameter, bhyvectl will
produce two checkpoint images and the exits. This is slightly ambiguous.
So, permit only one of theses parameters at the same time.
Reviewed by: corvink, markj
MFC after: 1 week
Sponsored by: vStack
Differential Revision: https://reviews.freebsd.org/D38887
init_checkpoint_thread binds to a socket. Bhyve isn't allowed to do that
after caph_enter.
Reviewed by: corvink, markj
MFC after: 1 week
Sponsored by: vStack
Differential Revision: https://reviews.freebsd.org/D38857
Mostly sprinkle __unused. Also duplicate strings passed to addenv() so
that constant string literals can be passed. No functional change
intended.
Reviewed by: corvink, rew, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38840
