Adding a bare constant to a uint16_t promotes to a signed int which
triggers these warnings. Changing the constant to be explicitly
unsigned instead promotes the expression to unsigned int.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D37485
Now that all ACPI tables are build by basl, basl can dynamically
calculate the offset for each table.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37002
Building the RSDP table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37001
Building the RSDT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37000
Building the XSDT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36999
Building the FADT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36998
Building the MADT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36997
Building the HPET table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36996
Building the MCFG table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36995
The common style for build an ACPI table will be:
1. basl_table_create
2. basl_table_append_header
3. setup an ACPI_TABLE_* struct
4. basl_table_append_bytes (without header)
Add a helper for the last step.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37406
The code will be more readable if we use struct definitions from ACPI-CA
to build ACPI tables. We can fill out the struct and append it to the
basl_table by using basl_table_append_bytes. After that, we have to
declare which checksums, length and pointers should be patched by basl.
That's done by the add_* functions.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37405
Building the FACS table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36994
Disable -Wcast-align for now since we have many instances of that
warning (I fixed some but not most of them) and platforms on which bhyve
runs don't particularly care about unaligned accesses.
Reviewed by: corvink
Differential Revision: https://reviews.freebsd.org/D37296
I believe the __packed annotation is there only because
pci_xhci_portregs_read() is treating the register set as an array of
uint32_t. clang warns about taking the address of portregs->portsc
because it is a packed member and thus might not have expected
alignment.
Fix the problem by simply selecting the field to read with a switch
statement. This mimics pci_xhci_portregs_write(). While here, switch
to using some symbolic constants.
There is a small semantic change here in that pci_xhci_portregs_read()
would silently truncate unaligned offsets. For consistency with
pci_xhci_portregs_write(), which does not do that, return all ones for
unaligned reads instead.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37408
- Make basl_dump() as unused.
- Avoid arithmetic on a void pointer.
- Avoid a signed/unsigned comparison with
BASL_TABLE_CHECKSUM_LEN_FULL_TABLE.
- Ignore warnings about unused parameters from stuff pulled in by
acpi.h. In particular, any prototype wrapped by
ACPI_DBG_DEPENDENT_RETURN_VOID() will raise such parameters unless
ACPI_DEBUG_OUTPUT is defined.
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37397
The compiler was warning that the "size" parameter to
smbios_generic_initializer() was unused. This parameter is apparently
used to populate the "maximum structure size" field in the SMBIOS entry
point, but we were always setting it to zero.
Implement it instead in the main loop of the smbios table builder.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37294
The warnings that arise are bogus and have to be muted with
__no_lock_analysis in most cases. As a step towards enabling the
default warning level for bhyve, just disable them.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D37295
The arguments identifying the VM and vCPU are only needed for
vm_copy_setup.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D37158
Building the DSDT table by basl will allow it to be loaded by qemu's
ACPI table loader.
Building the DSDT is complex and basl doesn't support it yet. For that
reason, it's still compiled by iasl. It's just a bit restructured.
Upcoming commits will restructure the builds of all other ACPI tables in
a similar way. So, this commit is done for consistency reasons. We're
starting with DSDT because it doesn't point to any other tables and it's
the last one in our current build list.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36993
Most ACPI tables are using the same header. Make it easy to create this
header by creating a function for it.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36992
Some ACPI tables like XSDT contain pointers to other ACPI tables. When
an ACPI table is loaded by qemu's loader, the address in the guest
memory is unknown. For that reason, the qemu loader supports patching
those pointers. Basl keeps track of all pointers and causes the qemu
loader to patch all pointers.
The qemu ACPI table loader is unsupport yet. However, in a future commit
bhyve will use dynamic ACPI table offsets based on the size and
alignment requirements of each ACPI table. Therefore, tracking ACPI
table pointer is required too.
Reviewed by: jhb
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36991
The qemu ACPI table loader patches the ACPI tables. After patching them,
checksums aren't correct any more. It has to calculate a new checksum
for the ACPI table. For that reason, basl has to keep track of checksums
and has to cause the qemu loader to create new checksums for the tables.
The qemu ACPI table loader isn't supported yet. However, the address of
all tables is unknown as long as bhyve hasn't finished ACPI table
creation. So, the checksum of tables which include pointer to other
tables are unknown too. This requires tracking of checksums too.
Reviewed by: jhb
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36990
ACPI tables have different layouts. So, there's no common position for
the length field. When tables are build by basl, the length is unknown
at the beginning. It has to be set after building the table.
Reviewed by: jhb
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36989
In upcoming commits, bhyve will build some ACPI tables by it's own.
Therefore, it should be capable of appending GENERIC_ADDRESS structs to
ACPI tables.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36988
In upcoming commits, bhyve will build some ACPI tables by it's own.
Therefore, it should be capable of appending int values to ACPI tables.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36987
Load the blobs compiled by iasl into a basl_table. The basl_table is a
temporary buffer which copies the ACPI tables into guest memory for us.
This allows us in the future to pass the blobs over the qemu fwcfg
interface to the guest.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36986
Developing an ACPI table compiler isn't quite easy. It's helpful if you
can take a look at the ACPI tables created by the compiler.
The dump functions can either dump a ACPI table which was copied into
guest memory or a ACPI table provided for qemu's ACPI table loader.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36985
Basl is the bhyve ASL compiler. At the moment, it's just a small wrapper
to call iasl, the Intel ASL compiler. As bhyve will gain support for
qemu's ACPI table loader in the future, it has to create ACPI tables on
it's own. Therefore, it makes sense to create a new file which keeps the
code for basl.
This first implementation of basl supports creating an ACPI table by
appending raw bytes to it. It's also capable of loading all tables into
guest memory.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36984
The '/' and '§' keys are missing in the german keyboard layout.
Reviewed by: markj
Approved by: manu (mentor)
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37386
Async event report is controlled by async event configuration feature
setting. When reporting a critical temperature warning, check the async
event configuration.
Approved by: manu (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D37355
Set Feature is a feature specified function. Currently only some
features have the set procedure. For features that are not handled by
the controller, we should return a FEATURE_NOT_CHANGEABLE error message.
Approved by: manu (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32802
Currently bhyve's NVMe controller cannot save feature values cross
reboot. It should return a FEATURE_NOT_SAVEABLE error when the command
specifies a save flag.
Quote from NVMe specification, page 205:
https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf
If the Feature Identifier specified in the Set Features command is not
saveable by the controller and the controller receives a Set Features
command with the Save bit set to one, then the command shall be aborted
with a status of Feature Identifier Not Saveable.
Reviewed by: chuck (older version)
Approved by: manu (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32767
We only need to call pci_xhci_xfer_complete() when handling a transfer
to the control endpoint, so move that code into the epid == 1 block and
eliminate a goto. Also remove an unneeded reinitialization of
setup_trb.
No functional change intended.
MFC after: 1 week
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37287
Silence a warning from the compiler about "const" being discarded. The
warning is correct: nvlist values are supposed to be immutable.
However, fixing this properly will require some contortions on behalf of
consumers who look up a subtree of the config and modify it. Per a
discussion on freebsd-virtualization@, the solution will probably be to
outright replace the use of nvlists for VM configuration, but until that
happens let's document the problem and silence the warning.
No functional change intended.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37293
They accomplish nothing since the qualifier is casted away in calls to
memcpy() and copyin()/copyout(). No functional change intended.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37292
The qualifiers are there presumably because these rings are mapped into
the guest, but they do not appear to be required for correctness, and
bhyve generally doesn't qualify accesses to guest memory this way.
Moreover, the qualifiers are discarded by snapshot code, causing clang
to emit warnings. Just stop using volatile here.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37291
This fixes a warning raised by the removal of the volatile qualifier
from &trb->qwTrb0 in the following snippet:
xfer_block = usb_data_xfer_append(xfer,
(void *)(trbflags & XHCI_TRB_3_IDT_BIT ?
&trb->qwTrb0 : XHCI_GADDR(sc, trb->qwTrb0)),
trb->dwTrb2 & 0x1FFFF, (void *)addr, ccs);
The use of volatile appears to be inherited from the kernel driver's
definitions of the same structures. It makes some sense, since USB TRBs
and related structures live in guest memory, but bhyve device models
generally don't volatile-qualify accesses to guest memory and I can't
see how they are required for correctness here. Moreover, XHCI_GADDR
does not return volatile pointers so we're already being inconsistent.
Just drop the qualifiers to address the warning.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37290
Use it to silence warnings about potential unaligned accesses. No
functional change intended.
MFC after: 1 week
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37289
Currently PowerCycles field of Log Page is 0 and it is an invalid value.
This patch will initial the PowerCycles data to 1.
MFC after: 1 week
Approved by: manu (mentor)
Reviewed By: grehan (older version), chuck, corvink
Differential Revision: https://reviews.freebsd.org/D32558
Linux reads MISC_FEATURES_ENABLES to manage the CPUID faulting feature
(undocumented in the Intel SDM, but documented in 323850-004 (Intel
Virtualization Technology FlexMigration Application Note). Since bhyve
doesn't emulate this feature, we always return 0. Neither does bhyve
support the MONITOR/MWAIT fault bit also in this MSR (which is
documented in the sdm), so always return 0.
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D36602
Also remove the out-parameter of pci_xhci_find_stream(), since it's
unused by all callers.
MFC after: 1 week
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D37118
clang warned that "client_ver" can be left uninitialized. This change
causes the new connection to be dropped if a version string is not
presented.
MFC after: 1 week
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D37117
- Use unsigned types for all arithmetic. Use a new signed variable for
holding the return value of pread() and pwrite().
- Handle short I/O from pwrite().
MFC after: 1 week
- Rename the global cores/sockets/threads to cpu_cores/sockets/threads.
This way, num_vcpus_allowed() doesn't shadow them.
- The global maxcpus is unused, remove it for the same reason.
MFC after: 1 week
This addresses a compiler warning arising from the fact that bhyve
needs to cast away a const qualifier in order to call free().
No functional change intended.
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D37099
In case of device reset or not configured - features_negotiated is not
set, calling calling pci_vtnet_neg_features is wrong and resume gets
"Segmentation fault".
Reviewed by: markj
Sponsored by: vStack
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36244
- Qualify unexported symbols with "static".
- Drop some unnecessary and incorrect casts.
- Avoid arithmetic on void pointers.
- Avoid signed/unsigned comparisons in loops which use nitems() as a
bound.
No functional change intended.
MFC after: 1 week
- Include headers containing prototypes for exported functions.
- Initialize all fields of the extended translation table.
- Qualify an unexported translation table as static.
- Fix error handling for a read(2).
- Fix some style bugs.
No functional change intended.
MFC after: 1 week
Add VM_EXITCODE_IPI to permit returning unhandled IPIs to userland.
INIT and STARTUP IPIs are now returned to userland. Due to backward
compatibility reasons, a new capability is added for enabling
VM_EXITCODE_IPI.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D35623
Sponsored by: Beckhoff Automation GmbH & Co. KG
The netmap-specific data stored at be->opaque is freed by the caller
on error as part of freeing be.
Reviewed by: markj
Reported by: GCC -Wfree-nonheap-object
Differential Revision: https://reviews.freebsd.org/D36828
- Add const and __unused qualifiers where appropriate.
- Localize some global variables.
- Consistently spell vmexit state as "vme" in vmexit handlers, to avoid
shadowing the global vm_exit state array.
- Similarly, avoid shadowing "optarg".
MFC after: 2 weeks
This is easier to read and addresses some compiler warnings.
One might expect these tables to be read-only but it seems that the
snapshot/restore code may modify them.
MFC after: 2 weeks
- Avoid arithmetic on void pointers.
- Avoid a signed/unsigned comparison in loops which write or fill audio
data buffers.
Convert while loops to for loops while here.
MFC after: 2 weeks
Add VM_EXITCODE_IPI to permit returning unhandled IPIs to userland.
INIT and Startup IPIs are now returned to userland. Due to backward
compatibility reasons, a new capability is added for enabling
VM_EXITCODE_IPI.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35623
Sponsored by: Beckhoff Automation GmbH & Co. KG
vcpus could be restarted by the guest by sending an INIT SIPI SIPI
sequence to a vcpu. That's not supported by bhyve yet but it will be
supported in a future commit. So, create the vcpu threads only once on
startup to make restarting a vcpu easier.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35621
Sponsored by: Beckhoff Automation GmbH & Co. KG
- Ignore I/O requests with insufficiently sized input or output
buffers (those not containing compete request headers).
- Ignore control requests with improperly sized buffers.
- While here, explicitly zero the output header of an I/O request to
avoid leaking malloc garbage from the host if the header is not
fully populated.
PR: 264521
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: mav, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36271
Use a consistent prefix ("virtio-scsi: ") similar to the e1000 device
model.
Reviewed by: mav, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36270
When preparing to transmit pending packets, ensure that the head (TDH)
and tail (TDT) indices are in bounds. Note that validating values
when they are written is not sufficient along as the transmit length
(TDLEN) could be changed turning a value that was valid when written
into an out of bounds value.
While here, add further restrictions to the head register (TDH). The
manual states that writing to this value while transmit is enabled can
cause unexpected behavior and that it should only be written after a
reset. As such, ignore attempts to write while transmit is active,
and also ignore writes of non-zero values. Later e1000 chipsets have
this register as read-only.
Also ignore any attempts to transmit packets if the transmit ring's
size is zero.
PR: 264567
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36269
Permit naming pass through devices using the syntax accepted by
pciconf (pci[<domain>:]<bus>:<slot>:<func>) as well as by device name
(e.g. "ppt0").
While here, fix an error in the manpage that had the bus and slot
arguments for the original /-delimited scheme swapped.
Reviewed by: imp, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36147
Certain operations such as checksum insertion and VLAN insertion
require the device model to rewrite the packet header. The first step
in rewriting the packet header is to copy the existing packet header
from the source packet. This copy is done by copying data from an
iovec array that corresponds to the S/G entries described by transmit
descriptors. However, if the total packet length is smaller than the
headers that need to be copied as the initial template, this copy can
overflow the iovec array and use garbage values as the source pointer
to memcpy. The PR used a single descriptor with a length of 0 in its
PoC.
To fix, track the total packet length and drop requests to transmit
packets whose payload is smaller than the required header length.
While here, fix another issue where the final descriptor could have an
invalid length (too short) that could underflow 'len' when stripping
the checksum. Skip those requests instead, too.
PR: 264372
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: grehan, markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36182
This avoids type confusion where a malicious guest could rewrite the
MaxPStreams field in an endpoint context after the endpoint was
initialized causing the device model to interpret a guest provided
address (stored in ep_ringaddr of the "software" endpoint state) as a
bhyve host process address (ep_sctx_trbs). It also prevents a malicious
guest from triggering overflows of ep_sctx_trbs[] by increasing the
number of streams after the endpoint has been initialized.
Rather than re-reading the MaxPStreams value out of the endpoint context
in guest memory on subsequent operations, cache the value in the software
endpoint state. Possibly the device model should raise errors if the
value of MaxPStreams changes while an endpoint is running. This approach
simply ignores any such changes by the guest.
PR: 264294, 264347
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36181
Controllers must support the Identify Controller list if they support
Namespace Management. But the UNH NVMe tests use this command regardless
of whether the device under test supports Namespace Management.
This implementation returns an empty Controller list (i.e., Number of
Identifiers is zero).
Fixes UNH Test 1.1.2
Reviewed by: jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36193
The NVMe specification only allows Controllers compliant with the
revision 1.3 and earlier specification to report a value of 0x0 in the
No-Deallocate Modifies Media After Sanitize (NODMMAS) field.
For our revision 1.4 Controller, report that media is not modified after
Sanitize as the implementation does not implement Sanitize.
Fixes UNH Test 1.1.2
Reviewed by: jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36192
Summary:
Code was using the mask value without the shift.
Test Plan: Within FreeBSD/Linux guest, Identify NVMe controller to check the result.
Reviewed by: chuck, imp
MFC after: 2 weeks
Signed-off-by: Wanpeng Qian <wanpengqian@gmail.com>
Differential Revision: https://reviews.freebsd.org/D32659
Summary:
Currently Active Firmware Info is not initialized.
Fix is to initialize the Active Firmware Info to Slot 1.
Test Plan: Within FreeBSD/Linux guests, show the Firmware Logpage to confirm.
Reviewed By: chuck
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32658
Summary:
Set Number of Power States Supported to indicate 1 power state. Keep the
Power State Descriptor data structures as zero to indicate "Not
reported".
Test Plan:
Within FreeBSD/Linux guests, list the number of power states and check
the Max Power value.
Reviewed By: markj, chuck
MFC after: 2 weeks
Signed-off-by: Wanpeng Qian <wanpengqian@gmail.com>
Differential Revision: https://reviews.freebsd.org/D32657
The debug print in nvme_opc_get_log_page() would print an uninitialized
local variable.
In nvme_opc_write_read(), a failed LBA bounds check would cause
pci_nvme_stats_write_read_update() to be called with an uninitialized
variable as a parameter. Although the parameter is unused when the
check fails (and so status != 0), LLVM 14 emits some bogus machine code
in this path, which happens to result in a segfault when it gets
executed.
PR: 265749
Reviewed by: chuck, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36119
Currently these are not reported because bhyve is compiled with WARNS=2.
Let's start taking small steps towards enabling more warnings.
No functional change intended.
Reviewed by: chuck, imp, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36118
The Dataset Management code could free an uninitialized pointer if the
device doesn't support the Dataset Management command.
PR: 264548
Reported by: Robert Morris <rtm@lcs.mit.edu>
Fuzzing of bhyve uncovered an assertion failure in the NVMe emulation.
Investigation uncovered several corner cases the code did not handle.
This change handles several Controller initialization errors, including
- bad AQ sizes
- bad AQ vm_map_gpa
- doorbell writes prior to RDY
- doorbell writes to uninitialized queue
- CSTS.RDY if CFS set
PR: 256317,256319,256320,256322
Reported by: Cheolwoo Myung <cwmyung@snu.ac.kr>
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D35453
Fuzzing of bhyve using hyfuzz discovered a way to cause a segmentation
fault in the NVMe emulation. If a guest specifies a physical address in
either the PRP1 or PRP2 field of a command that cannot be mapped from
guest to host, the function paddr_guest2host() returns a NULL pointer.
The NVMe emulation did not check for this error case, which allowed for
the segmentation fault to occur.
Fix is to check for a return value of NULL and indicate an error back to
the guest (Data Transfer error). While in the area, slightly refactor
the write/read blockif function to use a common error exit path.
PR: 256321
Reported by: Cheolwoo Myung <cwmyung@snu.ac.kr>
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D35452
Summary:
NVMe operations indicate the memory region(s) associated with a command
via physical region pages (PRPs). Since each PRP has a fixed size,
contiguous memory regions larger than the PRP size require multiple PRP
entries.
Instead of issuing a blockif call for each PRP, the NVMe emulation
concatenates multiple contiguous PRP entries into a single blockif
request. The test for contiguous regions has a bug such that it
mistakenly treats an initial PRP address of zero as a contiguous range
and concatenates it with the previous. But because there is no previous
IOV, the concatenation code corrupts the IO request structure and leads
to a segmentation fault when the blockif request completes.
Fix is to test for the existence of a previous range before trying to
concatenate the current range with the previous one.
While in the area, rename pci_nvme_append_iov_req()'s lba parameter to
offset to match its usage.
PR: 264177
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35328
Surrently virtio-net uses the prefix of the backing interface to
choose the backend. This patch adds an additional option "type" to
choose the backend type explicitly. This allows greater flexibility
for end users to manage bhyve specific resources (such as by naming
the tap interfaces to more descriptive names). The option "type" is
optional. When it is not presented, the backend is derived from the
name of the backend interface.
For example, the line `-s 3,virtio-net,bsdvm0,type=tap` will create a
virtio-net device for the guest using the tap interface "bsdvm0".
Adding a new "type" option preserves the current legacy format in which
the first value after virtio-net names an instance of a backend.
Note that tap interfaces not following the pattern "tap*" will not be
created on demand via devfs cloning but must be created explicitly.
Reviewed by: vmaffione, jhb
Differential Revision: https://reviews.freebsd.org/D35143
When pausing a block I/O device model as part of suspending a VM, wait
for all active block I/O requests to finish before saving snapshot
data. This avoids having to save information about in-flight requests
both in the block_if layer and in storage device models.
For the AHCI device model, the queues are now guaranteed to be idle
when taking a snapshot, so remove the code to save queue state and
rely on the initial state in a resumed VM having all queues already
idle.
This will also simplify adding NVMe snapshot support in the future.
Reviewed by: jhb
Sponsored by: vStack
Differential Revision: https://reviews.freebsd.org/D26267
Some software uses SMBIOS entries to identify the system on which it's
running. In order to make it possible to use such software inside a VM,
SMBIOS entries should be configurable. Therefore, bhyve_config can be
used. While only a few SMBIOS entries might be of interest, it makes
sense that all SMBIOS entries are configurable. This way all SMBIOS
tables are build the same way and there's no special handling for some
tables.
Reviewed by: jhb
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34465
virtio-console is currently missing .pe_legacy_config, which prevents any
portN configuration from being parsed, and therefore no sockets will be
created.
Reviewed by: khng
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35142
Now that nvlist_send()/nvlist_recv() are being used, ditch the datagram
socket.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D34863
pci_parse_legacy_config splits the options string by comma characters.
strchr returns a pointer to the first occurence of a character. In that
case, it's a comma. So, pci_parse_legacy_config will stop at the first
character and creates a new config node with a name of NULL.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D34600
At the moment, writes to BAR registers that aren't 4 byte aligned are
ignored. So, there's no overflow yet. Nevertheless, if this behaviour
changes in the future, it could unintentionally, introduce a buffer
overflow. Additionally, some compiler or tools will detect this
potential overflow and complain about it.
Reviewed by: markj
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Reported-by: Andy Fiddaman <andy@omniosce.org>
Differential Revision: https://reviews.freebsd.org/D34689
NAME_MAX is a better fit since strcat_extension() constructs the
filename of the snapshot file.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D34291
Allows callers of vm_get_name() to retrieve the vm name without having
to allocate a buffer.
While in the vicinity, do minor cleanup in vm_snapshot_basic_metadata().
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D34290
Explicitly initialize the mutex that a PCI virtio module passes back to
virtio.
It so happens that these mutexes were being initialized regardless, no
functional change intended.
Reviewed by: chuck, jhb
Differential Revision: https://reviews.freebsd.org/D34372
The Li macro is deprecated. Also, the Cm macro should be used here
instead for consistency with the rest of the manual and style.mdoc(5).
Fixes: e47fe3183e bhyve: add ROM emulation
MFC after: 1 month
For backward compatibility, the memory size will be interpreted in MB if
it's smaller than1 MB and has no suffix. Nowadays, the -m switch accepts
more than just MB. Respect it in the usage message.
Differential Revision: https://reviews.freebsd.org/D34506
Reviewed by: grehan
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 month
Some PCI devices especially GPUs require a ROM to work properly.
The ROM is executed by boot firmware to initialize the device.
To add a ROM to a device use the new ROM option for passthru device
(e.g. -s passthru,0/2/0,rom=<path>/<to>/<rom>).
It's necessary that the ROM is executed by the boot firmware.
It won't be executed by any OS.
Additionally, the boot firmware should be configured to execute the
ROM file.
For that reason, it's only possible to use a ROM when using
OVMF with enabled bus enumeration.
Differential Revision: https://reviews.freebsd.org/D33129
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 month
Export functions for reading and writing the pci config space from passthru
device to be used by other devices.
This is required for lpc devices to set their vendor/device ids to their
physical values.
Otherwise, GPU passthrough for integrated Intel GPUs won't work properly.
Differential Revision: https://reviews.freebsd.org/D33769
Reviewed by: markj
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 month
Even today it is possible to specify pinning for a vCPU higher than
the configured number of CPUs but lower than VM_MAXCPU without raising
an error.
Reviewed by: grehan
Differential Revision: https://reviews.freebsd.org/D34492
Use basl_ncpu instead of VM_MAXCPU in MADT_SIZE. Since several of the
offsets are no longer compile time constants, unroll the loop
generating ACPI tables.
Reviewed by: grehan
Differential Revision: https://reviews.freebsd.org/D34490
Use seperate nvlist entries for the romfile and the varfile.
While here, don't leak varfd in bootrom_loadrom().
Reviewed by: jhb, markj
Differential Revision: https://reviews.freebsd.org/D33433
Advertise Namespace Attribute Notices events in the Optional
Asynchronous Events Supported (OAES) field of the Identify Controller
data structure. Additionally, rename the enums and macros to clarify
these are AEN's related to Notices and not generic information.
Reported by: andy@omniosce.org
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D34331
The nvlist for a checkpoint request will now look like:
{ cmd="checkpoint", suspend="true/false", filename="afilename" }
Reviewed by: jhb
Suggested by: jhb
Differential Revision: https://reviews.freebsd.org/D34237
Switch to using an nvlist with nvlist_send()/nvlist_recv() to
communicate from bhyvectl(8) to bhyve(8).
The idea is that a bhyve process receives a command with with a set of
arguments. The nvlist here is structured to reflect that premise.
For example, to snapshot the vm, the expected nvlist looks like:
{ cmd=START_CHECKPOINT, filename="filename" }
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D33977
Section 4.1.2.1 of the virtio spec states that the transitional PCI
device id for a scsi device is 0x1004.
Fix suggested by reporter.
PR: 259961
Reported by: me@nanaya.pro
Reviewed by: imp, jhb
Fixes: f9c005a17f ("Add bhyve virtio-scsi storage backend support.")
Differential Revision: https://reviews.freebsd.org/D34103
If the NVMe Controller doesn't support Namespace Management, it should
return "Invalid Namespace or Format" when the Host request Identify
Namespace with the global NSID value.
Fixes UNH IOL 16.0 Test 9.1, Case 6
Reviewed by: imp, allanjude
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33578
NVMe Controllers which do not support Endurance Groups must return an
error when the Endurance Group Event Aggregate Log Change Notices bit is
set in Set Features, Asynchronous Event Configuration.
Fixes UNH IOL Test 3.12, Case 8
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33577
The function which checks for a valid LBA range mistakenly named an
input value as NLB ("Number of Logical Blocks") instead of "number of
blocks". The NVMe specification defines NLB as a zero-based value (i.e.
NLB=0x0 represents 1 block, 0x1 is 2 blocks, etc.), but the passed
parameter is a 1's-based value.
Fix is to rename the variable to avoid future confusion.
While in the neighborhood, also check that the starting LBA is less than
the size of the backing storage to avoid an integer overflow.
Reviewed by: imp, allanjude, jhb
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33575
Implement basic support for the SEL field of Get Features. This returns
information about Namespace Specific features.
Fixes UNH ILO 16.0 Test 1.2, Case 13
Reviewed by: imp, allanjude
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33574
Compliant v1.4 Controllers must report a Controller Type (CNTRLTYPE).
Also, do not advertise secure erase functionality in the Format NVM
Attributes field of the Identify Controller data structure as the
Controller does not implement secure erase.
Fixes UNH ILO Test 1.1, Case 2
Reviewed by: imp, allanjude
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33573
This adds the ability for a guest OS to send Set / Get Feature,
Temperature Threshold commands. The implementation assumes a constant
temperature and will generate an Asynchronous Event Notification if the
specified threshold is above/below this value. Although the
specification allows 9 temperature values, this implementation only
implements the Composite Temperature.
While in the neighborhood, move the clear of the CSTS register in the
reset function after all other cleanup. This avoids a race with the
guest thinking the reset is complete (i.e. CSTS.RDY = 0) before the NVMe
emulation is actually complete with the reset.
Fixes UNH IOL 16.0 Test 1.7, cases 1, 2, and 4.
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33572
Be more conservative and only support the Features mandatory for an I/O
Controller.
Avoids a "hang" in UNH test 1.2.10 associated with Predictable Latency
Mode Configuration and Host Behavior Support features.
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33571
The NVMe emulation checked if the Asynchronous Event Request Limit
(a.k.a AERL) would be exceeded in pci_nvme_aer_add(), but this function
is only called from nvme_opc_async_event_req() which also checks for
exceeding the AERL.
Reviewed by: imp, allanjude
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33570
Modify the Get Log Page command to parse the Log Page Offset fields to
support more recent versions of the NVMe specification.
Fixes various tests for UNH Test 1.3.*
Reviewed by: imp, allanjude
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33568
Return an error if the feature specified in Set Features is Namespace
specific but the Namespace ID uses the Global Namespace tag.
Fixes UNH Test 1.2.7
Reviewed by: imp, allanjude
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33566
The NVM Format command is unique among the Admin commands in that it
needs to finish asynchronously. For this reason, the emulation code
invented a synthetic completion status (NVME_NO_STATUS) to indicate that
the command was still in progress and the command processing loop should
not generate a completion message. The implementation used the value
0xffff for the synthetic value as this set both the Status Code and
Status Code Type fields to reserved values.
Format initialized the completion status to this value and expected
error cases to override it with a status code/type appropriate to the
situation. The macros used to set the NVMe status are careful not to
modify bit 0 (i.e. the phase bit), which with the synthetic completion
status, causes the phase bit to get out of sync. When running tests in a
guest with illegal NVM Format commands, Admin commands would eventually
hang because it appeared there were no completions due to the incorrect
phase bit value.
Fix is to only set NVME_NO_STATUS if the blockif delete command
succeeds. While in the neighborhood, add a missing break statement when
NVM Format is not supported.
Reviewed by: imp, allanjude
Tested by: jason@tubnor.net
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33565
This is needed to get mediasize of the device after a resize event.
I missed this earlier as I was building WITH_BHYVE_SNAPSHOT, which
disables capsicum.
Reviewed by: khng, markj
Fixes: ae9ea22e14 ("bhyve: get mediasize for character devices when ...")
Differential Revision: https://reviews.freebsd.org/D34013
An AHCI controller may be specified with no connected ports. Avoid
dumping core in this case for compatibility with existing VM configs.
Reviewed by: khng, jhb
Fixes: 621b509048 Refactor configuration management in bhyve.
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D33969
Part two: Append bhyve -K option for specified keyboard layout
with layout setting files every languages.
Since the cmd option '-k' was used in the meantime
it was changed to '-K'
PR: 246121
Submitted by: koinec@yahoo.co.jp
Reviewed by: grehan@
Differential Revision: https://reviews.freebsd.org/D29473
MFC after: 4 weeks
pthread_create() returns 0 on success or an error number on failure.
Reviewed by: khng, markj
Differential Revision: https://reviews.freebsd.org/D33930
If an emulation uses those functions instead of set_config_value_node
or set_config_value, it allows the config values to get
overwritten. Introducing new functions is much more readable than
if else statements in the emulation code.
Reviewed by: khng
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33770
The starting address passed to mprotect was wrong, so in the case where
the last page containing the table is not the last page of the BAR, the
wrong region would be unmapped.
Reported by: Andy Fiddaman <andy@omniosce.org>
Reviewed by: jhb
Fixes: 7fa2335347 ("bhyve: Map the MSI-X table unconditionally for passthrough")
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33739
The PBA and MSI-X table can reside in different BARs.
Reported by: Andy Fiddaman <andy@omniosce.org>
Reviewed by: jhb
Fixes: 7fa2335347 ("bhyve: Map the MSI-X table unconditionally for passthrough")
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33739
Bhyve allocates small 64 bit BARs below 4 GB and generates ACPI tables
based on this allocation. If the guest decides to relocate those BARs
above 4 GB, it could lead to mismatching ACPI tables. Especially
when using OVMF with enabled bus enumeration it could cause
issues. OVMF relocates all 64 bit BARs above 4 GB. The guest OS
may be unable to recover from this situation and disables some PCI
devices because their BARs are located outside of the MMIO space
reported by ACPI. Avoid this situation by giving the guest more
space for relocating BARs.
Let's be paranoid. The available space for BARs below 4 GB is 512 MB
large. Use a slop of 512 MB. It'll allow the guest to relocate all
BARs below 4 GB to an address above 4 GB. We could run into issues
when we exceeding the memlimit above 4 GB. However, this space has
a size of 32 GB. Even when using many PCI device with large BARs
like framebuffer or when using multiple PCI busses, it's very
unlikely that we run out of space due to the large slop.
Additionally, this situation will occur on startup and not at runtime
which is much better.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33118
At the moment, you only have one single chance to read the fwctl
signature. At boot bhyve is in the state IDENT_WAIT. It's then
possible to switch to IDENT_SEND. After bhyve sends the signature,
it switches to REQ. From now on it's impossible to switch back to
IDENT_SEND to read the signature. For that reason, only a single
driver can read the signature. A guest can't use two drivers to
identify that fwctl is present. It gets even worse when using
OVMF. OVMF uses a library to access fwctl. Therefore, every single
OVMF driver would try to read the signature. Currently, only a
single OVMF driver accesses the fwctl. So, there's no issue with
it yet. However, no OS driver would have a chance to detect fwctl when
using OVMF because it's signature was already consumed by OVMF.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D31981
E.g. Framebuffers can require large space and BARs need to be aligned
by their size. If BARs aren't allocated by size, it'll cause much
fragmentation of the MMIO space. Reduce fragmentation by ordering
the BAR allocation on their size to reduce the risk of
OUT_OF_MMIO_SPACE issues.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D28278
Some passthru devices only support MSI instead of MSI-X. For those
devices the initialization of MSI-X table will fail. Re-add the
check erroneously removed in f1442847c9.
MFC after: 3 days
X-MFC with: f1442847c9
PR: 260148
Reviewed by: manu, bz
Differential Revision: https://reviews.freebsd.org/D33728
If you look at the SMBIOS specification, we'll find something is
missing. In particular at offset 0Dh is supposed to be the OEM-defined
field. This should go between security and height. It is not legal to
actually skip this and will lead to other folks not properly
interpreting later parts of the table.
https://www.illumos.org/issues/14312
Reviewed by: jhb
Submitted by: Robert Mustacchi <rm@fingolfin.org>
Obtained from: ilumos
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D33682
The first time we start bhyve with a passthru device everything is fine
as on boot we do enable BARs. If a driver (unload) inside bhyve disables
the BAR(s) as some Linux drivers do, we need to make sure we re-enable
them on next bhyve start.
If we are trying to mmap a disabled BAR for MSI-X (PCIOCBARMMAP)
the kernel will give us an EBUSY.
While we were re-enabling the BAR(s) in the current code loop
cfginit() was writing the changes out too late to the real hardware.
Move the call to init_msix_table() after the register on the real
hardware was updated. That way the kernel will be happy and the
mmap will succeed and bhyve will start.
Also simplify the code given the last argument to init_msix_table()
is unused we do not need to do checks for each bar. [1]
MFC after: 3 days
PR: 260148
Pointed out by: markj [1]
Sponsored by: The FreeBSD Foundation
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D33628
Register a "block resize" callback to be notified of changes to the
backing storage for the Namespace. Use this to generate an Asynchronous
Event Notification, Namespace Attributes Changed when the guest OS
provides an Asynchronous Event Request.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D32953
When an EVFILT_VNODE filter event is triggered, reset it.
This fixes the issue where a virtio-blk resize event would cause the
mevent thread to consume 100% of the cpu.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D33326
OVMF creates two separate .fd files, a _CODE.fd file containing
the UEFI code, and a _VARS.fd file containing a template of an
empty UEFI variable store.
OVMF decides to write variables to the memory range just below the
boot rom code if it detects a CFI flash device. So here we add
just the barest facsimile of CFI command handling to bootrom.c
that is needed to placate OVMF.
Submitted by: D Scott Phillips <d.scott.phillips@intel.com>
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D19976
MFC After: 1 week
NVMe conformance tests for the Format command failed if the
backing-storage for the bhyve device was a file instead of a Zvol. The
tests (and the specification) expect a Format to destroy all previously
written data. The bhyve NVMe emulation implements this by trimming /
deallocating all data from the backing-storage.
The blockif_candelete() function indicated the file did not support
deallocation (i.e. fpathconf(..., _PC_DEALLOC_PRESENT) returned FALSE)
even though the kernel supported file hole punching. This occurs on
builds with Capsicum enabled because blockif did not allow the
fpathconf(2) right.
Fix is to add CAP_FPATHCONF to the cap_rights_init(3) call.
PR: 260081
Reviewed by: allanjude, markj, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D33203
Reads of the MSI-X capabilites aren't emulated by passthru devices
yet. The guest will read the host MSI-X capabilites which could
cause issues.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D32686
Sponsored by: Beckhoff Automation GmbH & Co. KG
On startup all virtual BARs are registered.
Additionally, the encoding bit in the virtual cmd register is set.
After that, the passthru emulation overwrites the virtual cmd register with
the physical one.
This could lead to a mismatch between registered BARs and the encoding
bits in the cmd register.
Instead of writing the physical to the virtual cmd register,
write the virtual to the physical cmd register to solve this issue.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D32687
Sponsored by: Beckhoff Automation GmbH & Co. KG
OVMF always uses 0xC0000000 as base address for 32 bit PCI MMIO space.
For that reason, we should use that address too.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D31051
Sponsored by: Beckhoff Automation GmbH & Co. KG
OVMF will fail, if large 64 bit BARs are used. GCD-Map doesn't cover
64 bit addresses of BARs.
OVMF assumes that 64 bit addresses of BARS are located on next 32 GB
boundary behind Top of High RAM.
This patch moves 64 bit BARs on next 32 GB boundary behind Top of High
RAM to match OVMF assumptions.
Differential Revision: https://reviews.freebsd.org/D27970
Sponsored by: Beckhoff Automation GmbH & Co. KG
Allocating a BAR will call baraddr which maps the framebuffer. No need
to allocate it explicitly on init.
Reviewed by: grehan
Sponsored by: Beckhoff Autmation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D32596
Tell the guest whether a BAR uses prefetched memory or not for
passthru devices by using the same lobits as the physical device.
Reviewed by: grehan
Sponsored by: Beckhoff Autmation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D32685
Bump the firmware version to 14.0 and set the firmware release date
to today.
Reviewed by: jhb, bz, imp
Differential Revision: https://reviews.freebsd.org/D32534
Note, this breaks compatibility with snapshots generated by older builds
of bhyve(8).
Fixes: 7fa2335347 ("bhyve: Map the MSI-X table unconditionally for passthrough")
Reported by: Greg V <greg@unrelenting.technology>
Reviewed by: grehan, bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32523
Bhyve could emulate wrong PCI registers.
In the best case, the guest reads wrong registers and the device driver would
report some errors.
In the worst case, the guest writes to wrong PCI registers and could brick
hardware when using PCI passthrough.
According to Intels specification, low bits of CFGADR should be
ignored. Some OS like linux may rely on it. Otherwise, bhyve could
emulate a wrong PCI register.
E.g.
If linux would like to read 2 bytes from offset 0x02, following would
happen.
linux:
outl 0x80000002 at CFGADR
inw at CFGDAT + 2
bhyve:
cfgoff = 0x80000002 & 0xFF = 0x02
coff = cfgoff + (port - CFGDAT) = 0x02 + 0x02 = 0x04
Bhyve would emulate the register at offset 0x04 not 0x02.
Reviewed By: #bhyve, grehan
Differential Revision: https://reviews.freebsd.org/D31819
Sponsored by: Beckhoff Automation GmbH & Co. KG
Let's make it clear to users that -k is for configuration files.
Also, point to bhyve_config(5) in the paragraph describing the flag.
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32467
It is possible for the PBA to reside in the same page as the MSI-X
table. And, while devices are not supposed to do this, at least some
Intel wifi devices place registers in a page shared with the MSI-X
table. To handle the first case we currently map the PBA page using
/dev/mem, and the second case is not handled.
Kill two birds with one stone: map the MSI-X table BAR using the
PCIOCBARMMAP ioctl instead of /dev/mem, and map the entire table so that
accesses beyond the bounds of the table can be emulated. Regions of the
BAR not containing the table are left unmapped.
Reviewed by: bz, grehan, jhb
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32359
