BSD Commit Log Search

Due to time constraints remove myself as a vmm(4) maintainer.

If uart interrupts are not functioning then schedule the callout to do the
polling at device attach time [1].

Add tunables 'debug.uart_force_poll' and 'debug.uart_poll_freq' to control
uart polling.

Submitted by:   Aleksey Kuleshov (rndfax at yandex.ru) [1]

Move the 'devmem' device nodes from /dev/vmm to /dev/vmm.io

Some external tools just do a 'ls /dev/vmm' to figure out the bhyve virtual
machines on the host. These tools break if the devmem device nodes also
appear in /dev/vmm.

Requested by:   grehan

Always assert DCD and DSR in bhyve's uart emulation.

The /etc/ttys entry for a serial console in FreeBSD/x86 is as follows:
ttyu0   "/usr/libexec/getty 3wire"      vt100   onifconsole secure

The initial terminal type passed to getty(8) is "3wire" which sets the
CLOCAL flag. However reset(1) clears this flag and any programs that try
to open the terminal will hang waiting for DCD to be asserted.

Fix this by always asserting DCD and DSR in the emulated uart.

The following discussion on virtualization@ has more details:
https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-June/003666.html

Reported by: jmg
Discussed with: grehan

MFC r284712:
Restore the host's GS.base before returning from 'svm_launch()' so the Dtrace
FBT provider works with vmm.ko on AMD.

MFC r282209:
Emulate the 'bit test' instruction.

MFC r282259:
Re-implement RTC current time calculation to eliminate the possibility of
losing time.

MFC r282281:
Advertise the MTRR feature via CPUID and emulate the minimal set of MTRR MSRs.

MFC r282284:
When an instruction cannot be decoded just return to userspace so bhyve(8)
can dump the instruction bytes.

MFC r282287:
Don't require <sys/cpuset.h> to be always included before <machine/vmm.h>.

MFC r282296:
Emulate MSR_SYSCFG which is accessed by Linux on AMD cpus when MTRRs are

    [90 lines not shown]

MFC r279444:
Allow passthrough devices to be hinted.

MFC r279683:
When ICW1 is issued the edge sense circuit is reset which means that
following an initialization a low-to-high transistion is necesary to
generate an interrupt.

MFC r279925:
Add -p parameter to list PCI device to pass through to the guest.

MFC r281559:
Fix handling of BUS_PROBE_NOWILDCARD in 'device_probe_child()'.

MFC r280447:
When fetching an instruction in non-64bit mode, consider the value of the
code segment base address.

MFC r280725:

    [44 lines not shown]

MFC r276428:
Replace bhyve's minimal RTC emulation with a fully featured one in vmm.ko.

MFC r276432:
Initialize all fields of 'struct vm_exception exception' before passing it
to vm_inject_exception().

MFC r276763:
Clear blocking due to STI or MOV SS in the hypervisor when an instruction is
emulated or when the vcpu incurs an exception.

MFC r277149:
Clean up usage of 'struct vm_exception' to only to communicate information
from userspace to vmm.ko when injecting an exception.

MFC r277168:
Fix typo (missing comma).

MFC r277309:

    [33 lines not shown]

Fix issues detected by 'mandoc -Tlint bhyveload.8'

Pointed out by:         wblock
Differential Revision:  https://reviews.freebsd.org/D2762

Restore the host's GS.base before returning from 'svm_launch()'.

Previously this was done by the caller of 'svm_launch()' after it returned.
This works fine as long as no code is executed in the interim that depends
on pcpu data.

The dtrace probe 'fbt:vmm:svm_launch:return' broke this assumption because
it calls 'dtrace_probe()' which in turn relies on pcpu data.

Reported by:    avg
MFC after:      1 week

Fix a regression in "movs" emulation after r284539. The regression was caused
due to a change in behavior of the 'vm_map_gpa()'.

Prior to r284539 if 'vm_map_gpa()' was called to map an address range in the
guest MMIO region then it would return NULL. This was used by the "movs"
emulation to detect if the 'src' or 'dst' operand was in MMIO space.

Post r284539 'vm_map_gpa()' started returning a non-NULL pointer even when
mapping the guest MMIO region.

Fix this by returning non-NULL only if [gaddr, gaddr+len) is entirely
within the 'lowmem' or 'highmem' regions and NULL otherwise.

Pointy hat to:  neel
Reviewed by:    grehan
Reported by:    tychon, Ben Perrault (ben.perrault at gmail.com)
MFC after:      1 week

Restructure memory allocation in bhyve to support "devmem".

devmem is used to represent MMIO devices like the boot ROM or a VESA framebuffer
where doing a trap-and-emulate for every access is impractical. devmem is a
hybrid of system memory (sysmem) and emulated device models.

devmem is mapped in the guest address space via nested page tables similar
to sysmem. However the address range where devmem is mapped may be changed
by the guest at runtime (e.g. by reprogramming a PCI BAR). Also devmem is
usually mapped RO or RW as compared to RWX mappings for sysmem.

Each devmem segment is named (e.g. "bootrom") and this name is used to
create a device node for the devmem segment (e.g. /dev/vmm/testvm.bootrom).
The device node supports mmap(2) and this decouples the host mapping of
devmem from its mapping in the guest address space (which can change).

Reviewed by:    tychon
Discussed with: grehan
Differential Revision:  https://reviews.freebsd.org/D2762
MFC after:      4 weeks

The 'verify_gla()' function is used to ensure that the effective address
after decoding the instruction matches the one provided by hardware.

Prior to r283293 'vie->num_valid' used to contain the actual length of
the instruction whereas now it contains the maximum instruction length
possible. This introduced a bug when calculating a RIP-relative base address.

Fix this by using 'vie->num_processed' rather than 'vie->num_valid' as the
length of the emulated instruction.

Reported and tested by: tychon
MFC after:      1 week

Use tunable 'hw.vmm.svm.features' to disable specific SVM features even
though they might be available in hardware.

Use tunable 'hw.vmm.svm.num_asids' to limit the number of ASIDs used by
the hypervisor.

MFC after:      1 week

Fix non-deterministic delays when accessing a vcpu that was in "running" or
"sleeping" state. This is done by forcing the vcpu to transition to "idle"
by returning to userspace with an exit code of VM_EXITCODE_REQIDLE.

MFC after:      2 weeks

Exceptions don't deliver an error code in real mode.

MFC after:      1 week

Remove the verification of instruction length after instruction decode. The
check has been bogus since r273375.

MFC after:      1 week

Don't rely on the 'VM-exit instruction length' field in the VMCS to always
have an accurate length on an EPT violation. This is not needed by the
instruction decoding code because it also has to work with AMD/SVM that
does not provide a valid instruction length on a Nested Page Fault.

In collaboration with:  Leon Dang (ldang at nahannisys.com)
Discussed with:         grehan
MFC after:              1 week

Add an option "--get-vmcs-exit-inst-length" to display the instruction length
of the instruction that caused the VM-exit.

MFC after:      1 week

Emulate the "CMP r/m, reg" instruction (opcode 39H).

Reported and tested by: Leon Dang (ldang at nahannisys.com)
MFC after:      1 week

Allow configuration of the sector size advertised to the guest.

The default behavior is to infer the logical and physical sector sizes from
the block device backend. However older versions of Windows only work with
specific logical/physical combinations:
- Vista and Windows 7:  512/512
- Windows 7 SP1:        512/512 or 512/4096

For this reason allow the sector size to be specified using the following
block device option: sectorsize=logical[/physical]

Reported by:    Leon Dang (ldang at nahannisys.com)
Reviewed by:    grehan
MFC after:      2 weeks

Allow byte reads of AHCI registers.

This is needed to support Windows guests that use byte reads to access certain
AHCI registers (e.g. PxTFD.Status and PxTFD.Error).

Reviewed by:    grehan, mav
Reported by:    Leon Dang (ldang at nahannisys.com)
Differential Revision:  https://reviews.freebsd.org/D2469
MFC after:      2 weeks

Check 'td_owepreempt' and yield the vcpu thread if it is set.

This is done explicitly because a vcpu thread can be in a critical section
for the entire time slice alloted to it. This in turn can delay the handling
of the 'td_owepreempt'.

Reviewed by:    jhb
MFC after:      1 week
Differential Revision:  https://reviews.freebsd.org/D2430

Deprecate the 3-way return values from vm_gla2gpa() and vm_copy_setup().

Prior to this change both functions returned 0 for success, -1 for failure
and +1 to indicate that an exception was injected into the guest.

The numerical value of ERESTART also happens to be -1 so when these functions
returned -1 it had to be translated to a positive errno value to prevent the
VM_RUN ioctl from being inadvertently restarted. This made it easy to introduce
bugs when writing emulation code.

Fix this by adding an 'int *guest_fault' parameter and setting it to '1' if
an exception was delivered to the guest. The return value is 0 or EFAULT so
no additional translation is needed.

Reviewed by:    tychon
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D2428

Do a proper emulation of guest writes to MSR_EFER.
- Must-Be-Zero bits cannot be set.
- EFER_LME and EFER_LMA should respect the long mode consistency checks.
- EFER_NXE, EFER_FFXSR, EFER_TCE can be set if allowed by CPUID capabilities.
- Flag an error if guest tries to set EFER_LMSLE since bhyve doesn't enforce
  segment limits in 64-bit mode.

MFC after:      2 weeks

Add macros for AMD-specific bits in MSR_EFER: LMSLE, FFXSR and TCE.

AMDID_FFXSR is at bit 25 so correct its value to 0x02000000.

MFC after:      1 week

Emulate the 'CMP r/m8, imm8' instruction encountered when booting a Windows
Vista guest.

Reported by:    Leon Dang (ldang at nahannisys.com)
MFC after:      1 week

Don't advertise the Intel SMX capability to the guest.

Reported by:    Leon Dang (ldang at nahannisys.com)
MFC after:      1 week

Emulate machine check related MSRs to allow guest OSes like Windows to boot.

Reported by:    Leon Dang (ldang at nahannisys.com)
MFC after:      2 weeks

Advertise an additional memory BAR in the "dummy" device emulation.

This is useful for testing the MOVS emulation when both the source and
destination addresses are in the MMIO space.

MFC after:      1 week