For debugging purposes it is helpful to dump the E820 table.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39549
This function makes it easy to allocate new E820 entries. It will be
used to allocate graphics memory for Intel integrated graphic devices.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39547
The VGA and the ROM memory ranges can't be used as system memory. For
that reason, remove them from the E820 table.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39546
There are some use cases where bhyve has to prepare some special memory
regions. E.g. GPU passthrough for Intel integrated graphic devices needs
to reserve some memory for the graphic device. So, bhyve has to inform
the guest about those memory regions. This information can be passed by
the qemu fwcfg interface. As qemu creates an E820 table, we can reuse
the existing fwcfg item "etc/e820".
This commit is the first one of a series. It only adds a basic
implementation for the creation of the E820 table. Some subsequent
commits will add more items to the E820 table and register it as fwcfg
item.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39545
The change is intended to be fully transparent to the users.
Similarly to route(8) and netstat(8), ndp can be build without
netlink by defining WITHOUT_NETLINK in make.conf.
Differential Revision: https://reviews.freebsd.org/D39720
The change is intended to be fully transparent to the users.
Similarly to route(8) and netstat(8), arp can be build without
netlink by defining WITHOUT_NETLINK in make.conf.
Differential Revision: https://reviews.freebsd.org/D39720
Add all acpi tables to qemus acpi table loader. This passes the acpi
tables by fwcfg to the guest.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38439
The hypervisor is aware of all system properties. For the guest bios
it's hard and complex to detect all system properties. For that reason,
it would be better if the hypervisor creates acpi tables instead of the
guest. Therefore, the hypervisor has to send the acpi tables to the
guest. At the moment, bhyve just copies the acpi tables into the guest
memory. This approach has some restrictions. You have to keep sure that
the guest doesn't overwrite them accidentally. Additionally, the size of
acpi tables is limited.
Providing a plain copy of all acpi tables by fwcfg isn't possible. Acpi
tables have to point to each other. So, if the guest copies the acpi
tables into memory by it's own, it has to patch the tables. Due to
different layouts for different acpi tables, there's no generic way to
do that. For that reason, qemu created a table loader interface. It
contains commands for the guest for loading specific blobs into guest
memory and patching those blobs.
This commit adds a qemu_loader class which handles the creation of qemu
loader commands. At the moment, the WRITE_POINTER command isn't
implement. It won't be required by bhyve's acpi table generation yet.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38438
Introduce undocumented option -d to dump parsed zonetab file contents
and add a "baseline" target along with instructions on updating it.
Reviewed by: philip
Differential Revision: https://reviews.freebsd.org/D39634
Rather than having a tool in the FreeBSD base system for obtaining
the FreeBSD ports tree, users are encouraged to `pkg install git`
and then `git clone https://git.FreeBSD.org/ports.git /usr/ports`.
The portsnap servers will continue operating until FreeBSD 13 reaches
its End-of-Life, and portsnap is available from the ports tree as
ports-mgmt/portsnap.
Requested by: portmgr
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D39563
X-MFC: no
Add Makefile.depend.options to libnetbsd, mkimg and makefs
to ensure libegacy is build if needed.
targets/pseudo/stage/Makefile avoid the need for mtree
the staging process creates target dirs as needed anyway.
Reviewed by: stevek
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D39757
When not doing tree walks, it is bad for sub-dirs to depend on
parents. Move the generation of opt_osname.h to distextract
and have others that need that depend on it.
In usr.sbin/bsdinstall use SUBDIR_DEPEND_ so tree walking still works.
Reviewed by: obrien
Differential Revision: https://reviews.freebsd.org/D39742
DOT and DOTDOT entries have special handling, and previously only Rock
Ridge PX (POSIX attributes) entries were attached. Add TF (timestamp)
entries as well.
PR: 203531
Reported by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39662
tzsetup now uses zone1970.tab and zoneinfo source is located in
contrib/tzdata, update the man page accordingly.
While here, drop obsolete Tn macros and insert vertical breaks (mostly
before Dl in examples) to improve readability.
Reviewed by: pauamma_gundo.com (manpages)
Differential Revision: https://reviews.freebsd.org/D39643
Also use more accurate function pointer types, and trim some duplicate
(but incomplete) function prototypes.
Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D39533
These will hopefully be fixed upstream eventually, but silence the
warnings until then.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D39518
For diff reduction against NetBSD's makefs. Based on NetBSD git mirror
commit 00991aee8248.
With this change our makefs cd9660 support should be in sync up to
NetBSD commit bdae6c9dc792 ("makefs(8): Nix trailing whitespace.").
Sponsored by: The FreeBSD Foundation
This matches NetBSD and rationalizes makefs with the kernel API.
This reverts commit 370e009188.
Reviewed by: mckusick
Sponsored by: The FreeBSD Foundation
Obtained from: NetBSD 0a62dad69f62, 0c4125e1a19f, cb6a5a3575fd
Differential Revision: https://reviews.freebsd.org/D39070
Makefs defined "follow-symlinks" and "help" options, but they did
nothing. Remove them.
Obtained from: OpenBSD a8f1645688c2
Sponsored by: The FreeBSD Foundation
Refactor daemon to use kqueue/kevent instead of signals.
This changes allows to simplify the code in several ways:
- the execution flow is now linear, no async events.
- several variables became redundant and got removed.
- all event handling is now concentrated inside of the event loop, which
makes code reading and comprehension easier.
- new kqueuex(2) call is used for CLOEXEC, but maintained closing the
kq fd prior to execve() to ease later MFC
No UX/API changes are intended.
Reviewed by: kevans
Pull Request: https://github.com/freebsd/freebsd-src/pull/701
This will be useful for writing device specific ACPI tables or DSDT
methods.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39322
Most register of the PCI header are either constant values or require
emulation anyway. The command and status register are the only exception which
require hardware access. So, we're adding an emulation handler for all
other register.
As this emulation handler will be reused by some future features like
GPU passthrough, we directly export it.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33010
GPU passthrough requires a special handling of some PCI config register.
Therefore, we need a flexible approach for implementing it. Adding an
array of handler meets this condition.
Start by using the default handler for all accesses to the PCI config
space. In upcoming commits, we can start to split the default handler
into several handler for each register that requires emulation.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39291
This feature will be used by future commits to implement a device
specific method (_DSM) for TPM devices.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39321
At the moment, this function can't fail. This behaviour will change in
the future. In preparation to that, convert the return type to int in
order to be able to check for errors.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39422
Some ACPI devices require a device specific acpi table. E.g. a TPM2
device requires a TPM2 table. Use the acpi_device_emul struct to define
such a device specific table.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39320
The host selector is only required when the user likes to use the same
LPC device IDs as the physical LPC device. This is an uncommon use case.
For that reason, it makes no sense to exit when we don't find the host
selector.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39311
Move date setting into cd9660_populate_iso_dir_record so there is no
path that leaves it unset.
PR: 203531
Reported by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39258
It was used only in constructing the host path that contains file
content, which is not related to anything CD9660-specific. PATH_MAX is
the appropriate limit. See OpenBSD commit 299d8950f319.
Obtained from: OpenBSD
Sponsored by: The FreeBSD Foundation
It'll be easier to add new properties to the ACPI device emulation if we
have a struct which holds all device specific properties. In some future
commits the acpi_device_emul struct will be expanded to include some
device specific functions to build ACPI tables.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39319
Corvin Köhne