Most of these already treat it as a proper bool, i.e. using true/false.
Also fix-up callers of OF_install().
No functional change intended.
Reviewed by: andrew, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45733
Drop a private implementation of roundup_pow_of_two and use the global
one instead.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D45739
The idea here is to avoid a memory access and conditional branch per
probe site. Instead, the probe is represented by an "unreachable"
unconditional function call. asm goto is used to store the address of
the probe site (represented by a no-op sled) and the address of the
function call into a tracepoint record. Each SDT probe carries a list
of tracepoints.
When the probe is enabled, the no-op sled corresponding to each
tracepoint is overwritten with a jmp to the corresponding label. The
implementation uses smp_rendezvous() to park all other CPUs while the
instruction is being overwritten, as this can't be done atomically in
general. The compiler moves argument marshalling code and the
sdt_probe() function call out-of-line, i.e., to the end of the function.
Per gallatin@ in D43504, this approach has less overhead when probes are
disabled. To make the implementation a bit simpler, I removed support
for probes with 7 arguments; nothing makes use of this except a
regression test case. It could be re-added later if need be.
The approach taken in this patch enables some more improvements:
1. We can now automatically fill out the "function" field of SDT probe
names. The SDT macros let the programmer specify the function and
module names, but this is really a bug and shouldn't have been
allowed. The intent was to be able to have the same probe in
multiple functions and to let the user restrict which probes actually
get enabled by specifying a function name or glob.
2. We can avoid branching on SDT_PROBES_ENABLED() by adding the ability
to include blocks of code in the out-of-line path. For example:
if (SDT_PROBES_ENABLED()) {
int reason = CLD_EXITED;
if (WCOREDUMP(signo))
reason = CLD_DUMPED;
else if (WIFSIGNALED(signo))
reason = CLD_KILLED;
SDT_PROBE1(proc, , , exit, reason);
}
could be written
SDT_PROBE1_EXT(proc, , , exit, reason,
int reason;
reason = CLD_EXITED;
if (WCOREDUMP(signo))
reason = CLD_DUMPED;
else if (WIFSIGNALED(signo))
reason = CLD_KILLED;
);
In the future I would like to use this mechanism more generally, e.g.,
to remove branches and marshalling code used by hwpmc, and generally to
make it easier to add new tracepoint consumers without having to add
more conditional branches to hot code paths.
Reviewed by: Domagoj Stolfa, avg
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D44483
A function called mask_width in one place and log2 in the other
calculates its value in a more complex way than necessary. A simpler
implementation offered here saves a few bytes in the functions that
call it.
Reviewed by: alc, avg
Differential Revision: https://reviews.freebsd.org/D45483
It duplicates iommu.dev, and was forgotten when struct iommu was split
out from dmar.
Sponsored by: The FreeBSD Foundation
Sponsored by: AMD dvanced Micro Devices (AMD)
MFC after: 1 week
related to the page tables page allocation and mapping.
Sponsored by: The FreeBSD Foundation
Sponsored by: Advanced Micro Devices (AMD)
MFC after: 1 week
A test system provided by AMD panicked with "madt_parse_apics:
I/O APIC ID 255 too high". I/O APIC ID 255 is acceptable, so increase
the limit.
Reviewed by: jhb, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45157
Instead of printing something like "MADT: Found CPU APIC ID 4294967295
ACPI ID 512: disabled" print the APIC ID as a singed int for a more
user-friendly -1.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45158
Several x86 interrupt core functions were already operating on intsrc
structures. Now switch the remaining 3 to intsrc for consistency.
Swap the order of intr_add_handler()'s first two arguments. This
matches INTRNG and is more consistent with other functions in this
interface.
Differential Revision: https://reviews.freebsd.org/D35386
Reviewed by: imp, markj (previous version)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1126
Typically, when a DMA transaction requires bouncing, we will break up
the request into segments that are, at maximum, page-sized.
However, in the atypical case of a driver whose maximum segment size is
smaller than PAGE_SIZE, we end up inefficiently assigning each segment
its own bounce page. For example, the dwmmc driver has a maximum segment
size of 2048 (PAGE_SIZE / 2); a 4-page transfer ends up requiring 8
bounce pages in the current scheme.
We should attempt to batch segments into bounce pages more efficiently.
This is achieved by pushing all considerations of the maximum segment
size into the new _bus_dmamap_addsegs() function, which wraps
_bus_dmamap_addseg(). Thus we allocate the minimal number of bounce
pages required to complete the entire transfer, while still performing
the transfer with smaller-sized transactions.
For most drivers with a segment size >= PAGE_SIZE, this will have no
impact. For drivers like dwmmc mentioned above, this improves the memory
and performance efficiency when bouncing a large transfer.
Co-authored-by: jhb
Reviewed by: jhb
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45048
It is functionally identical in all implementations, so move the
function to subr_busdma_bounce.c. The KASSERT present in the x86 version
is now enabled for all architectures. It should be universally
applicable.
Reviewed by: jhb
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45047
Convert existing FreeBSD vmware_hvcall function to take a channel
and parameter arguments.
Added vmware_guestrpc_cmd() to send GuestRPC commands to the VMware
hypervisor. The sbuf argument is used for both the command to send
and to store the data to return to the caller.
The following KPIs can be used to get and set FreeBSD-specific guest
information in key/value pairs:
* vmware_guestrpc_set_guestinfo
- set a value into the guestinfo.fbsd.<keyword> key
* vmware_guestrpc_get_guestinfo
- get the value stored in the guestinfo.fbsd.<keyword> key
Add VMware devices to x86 NOTES
Reviewed by: jhb
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D44528
While here, reorder some of the entries using headers more aligned
with sys/conf/NOTES. Also add a pointer from the amd64/i386 NOTES
files to x86 NOTES.
The "extra" ACPI device drivers were only present in i386 NOTES
previously.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44787
The public bus_release_resource() API still accepts both forms, but
the internal kobj method no longer passes the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44131
The public bus_activate/deactivate_resource() API still accepts both
forms, but the internal kobj methods no longer pass the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44130
The public bus_map/unmap_resource() API still accepts both forms, but
the internal kobj methods no longer pass the argument.
Implementations which need the type now use rman_get_type() to fetch
the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44129
The public bus_adjust_resource() API still accepts both forms, but the
internal kobj method no longer passes the argument. Implementations
which need the type now use rman_get_type() to fetch the value from
the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44128
Use %p instead of wrongly casting to uintptr_t and printing with %lx.
Reported by: bapt
Fixes: 9a687d1fe3 ('x86/xen: introduce a Xen early init function')
Sponsored by: Cloud Software Group
Unify the HVM and PVH early setup, byt making both rely on the hypervisor
initialization hook part of identify_hypervisor().
The current initialization takes care of the hypercall page, the sahred info
page and does any fixup necessary to metadata video console information if
FreeBSD is booted as the initial domain (so the video console is handed from
Xen into FreeBSD).
Note this has the nice side effect of also allowing to use the Xen console on
HVM guests, which allows to get rid of the QEMU emulated uart and still get
a nice text console.
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43764
Hypervisor detection is done very early on x86, and so can be used to also do
some very early hypervisor related initialization. Such initialization is
required when running as a Xen PVH guest, as for example the PIT needs to be
replaced with an hypervisor based timecounter.
Introduce an optional hook that gets called as part of the early hypervisor
detection.
No functional change intended.
Sponsored by: Cloud Software Group
Reviewed by: markj kib
Differential revision: https://reviews.freebsd.org/D43763
Where possible, replace the usage of xen_cpuid_base for hv_base in preparation
for removing xen_cpuid_base.
No functional change intended.
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43935
When FreeBSD is running as dom0 the video console metadata provided by the
bootloader might not be accurate, as Xen has very likely taken over the console
and possibly changed the mode.
Adjust the video console information in the kernel metadata as part of early
Xen initialization.
Sponsored by: Cloud Software Group
Reviewed by: imp
Differential revision: https://reviews.freebsd.org/D43934
As done with the hypercall page, move the setup fo the shared info page into
the newly introduced helper, which the aim of having a single helper and call
site used by both HVM and PV in order to setup the basic Xen environment.
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43933
Start by moving the hyeprcall setup to such function.
The aim is to have a function that does all the required Xen early
initialization for both HVM and PVH, instead of having it scattered across
different paths.
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43932
And instead fetch the metadata inside of the function.
This is done in preparation for changing the call site of fixup_console(),
which will no longer have the kernel metedata pointer in context.
No functional change intended.
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43931
Some hypervisors can expose multiple signatures, for example Xen will expose
both the Xen and the HyperV signatures if Viridian extensions are enabled for
the guest. Presence of multiple signatures is currently not handled by
FreeBSD, that will exit once a known signature is found in cpuid output.
Exposing the HyperV signature on hypervisors different than HyperV is not
uncommon, this is done so that such hypervisor can expose a (subset) of the
Viridian extensions to Windows guests for performance reasons. Likely for
compatibility purposes the HyperV signature is always exposed on the first
leaf, and the Xen signature is exposed in the secondary leaf.
Fix the specific case of HyperV by not exiting from the scan if the HyperV
signature is found, and prefer a second signature if one is found.
Note that long term we might wish to convert vm_guest into a bitmap, so that it
can signal detection of multiple hypervisor interfaces.
Fixes: b0165dc453 ('x86/xen: fix HVM guest hypercall page setup')
PR: 276421
Sponsored by: Cloud Software Group
Reviewed by: markj kib
Differential revision: https://reviews.freebsd.org/D43508
The current xc_printf() function uses an hypercall in order to send character
buffers to the hypervisor for it to print on the hypervisor console (if the
hypervisor is configured to print such messages).
This requires the hypercall page to be initialized, which is extra work and can
go wrong.
On x86 instead of using the console IO hypercall use the debug console IO port,
also called "port E9 hack". This allows sending characters to Xen using an
outb instruction, without any initialization required.
Keep the previous hypervisor based implementation by using the weak attribute,
which allows each architecture to provide an alternate (arch-specific)
implementation.
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43929
For small segments (< PAGE_SIZE) there is a mismatch between how
required bounce pages are counted in _bus_dmamap_count_pages() and
bounce_bus_dmamap_load_buffer().
This problem has been observed on the RISC-V VisionFive v2 SoC (and
earlier revisions of the hardware) which has memory physically addressed
above 4GB. This requires some bouncing for the dwmmc driver, which has
has a maximum segment size of 2048 bytes. When attempting to load a
page-aligned 4-page buffer that requires bouncing, we can end up
counting 4 bounce pages for an 8-segment transfer. These pages will be
incorrectly configured to cover only the first half of the transfer (4 x
2048 bytes).
Fix the immediate issue by adding the maxsegsz check to
_bus_dmamap_count_pages(); this is what _bus_dmamap_count_phys() does
already. The result is that we will inefficiently allocate a separate
bounce page for each segment (8 pages for the example above), but the
transfer will proceed in its entirety.
The more complete fix is to address the shortcomings in how small
segments are assigned to bounce pages, so that we opportunistically
batch multiple segments to a page whenever they fit (e.g. two 2048 bytes
segments per 4096 page). This will be addressed more holistically in the
future. For now this change will prevent the (silent) incomplete
transfers that have been observed.
PR: 273694
Reported by: Jari Sihvola <jsihv@gmx.com>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34118
Xen PVH guests expose a very minimal set of ACPI tables, and due to the lack of
SCI interrupt FreeBSD doesn't allocate the suspend stacks for saving CPU and
FPU contexts.
Lack of allocated stacks would lead to a page-fault in cpususpend_handler() when
CPUs attempted to use the save context area as a result of a Xen suspend
request. However there's no need to save the CPU or the FPU registers in the
Xen case, as that's all handled by the hypervisor. Hence avoid saving all this
state if the suspend stacks are not allocated.
Note that this will currently only apply to PVH guests, HVM ones will still get
the stack allocated and the context saved even when not strictly required. I
find it easier rather that having to provide cpususpend_handler() with extra
information whether the context needs to be saved or not.
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43765
c7368ccb68 didn't take into account that vm_guest will also get setup by
generic identify CPU code, and hence by the time xen_hvm_init() gets called
vm_guest will always be set if running as a Xen guest, either by the PVH entry
point code, or by generic CPU identification.
xen_hvm_init() and xen_hvm_init_hypercall_stubs() were relying on xen_domain()
returning false when running as an HVM guest, and used that into order to
figure out whether hypercall page needed to be populated.
Get rid of such assumptions and simplify the code since legacy PVH is no
longer supported.
This fixes booting FreeBSD as a Xen HVM guest.
Fixes: c7368ccb68 ('xen: remove xen_domain_type enum/variable')
Sponsored by: Cloud Software Group
The apm(8) program documents certain states, but doesn't document the
'unknown' state. It reports things correctly for systems with a battery,
but incorrectly for systems without one. Emulate the old interface a
little better by saying ac power is online if we have no status (instead
of unknown), the battery has a high charge of 255% if there's no battery
(instead of -1). Programs, like emacs, expect to see only the documented
values and misbehave when they see something else.
This is closer to what would happen on old-school APM machines. Sadly
(or not) I have no access to old-school APM machines to 100% confirm
this, but reading the spec, old code and testing with emacs' mode line
with battery suggests these values are more correct. emacs has never
been converted to acpi_conf due to permissions issues with acpi devices.
Fixing the kernel is preferable to hacking apm(8) for these special
cases because other programs that use these interfaces will also be more
correct. The kernel also has more data with which to decide what to
return.
Sponsored by: Netflix
MFC After: 1 week
On some platforms this static information can be derived directly from
the CPU, and there doesn't seem much use in restricting it.
Reviewed by: emaste, imp, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43281
i386 kernels without 'options PAE' will still use PAE page tables if
the CPU supports PAE both to support larger amounts of RAM and for
PG_NX permissions. However, to avoid changing the API, bus_addr_t and
related constants (e.g. BUS_SPACE_MAXADDR) are still limited to
32 bits.
To cope with this, the x86 bus_dma code included an extra check to
bounce requests for addresses above BUS_SPACE_MAXADDR. This check was
elided (probably because it looks always-true on its face and had no
comment explaining its purpose) in recent refactoring. To fix,
restore a custom address-validation function for i386 kernels without
options PAE that includes this check.
Reported by: ci.freebsd.org
Reviewed by: markj
Fixes: 3933ff56f9 busdma: tidy bus_dma_run_filter() functions
Differential Revision: https://reviews.freebsd.org/D43277
Alas, ARM declared xen_ulong_t to be 64-bits long, unlike i386 where
it matches the word size. As a result, compatibility wrappers are
needed for Xen atomic operations.
Reviewed by: royger
