History log of /freebsd/sys/amd64/vmm/vmm.c (Results 201 – 225 of 290)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 1709ccf9 29-Mar-2014 Martin Matuska <mm@FreeBSD.org>

Merge head up to r263906.


# b15a09c0 27-Mar-2014 Neel Natu <neel@FreeBSD.org>

Add an ioctl to suspend a virtual machine (VM_SUSPEND). The ioctl can be called
from any context i.e., it is not required to be called from a vcpu thread. The
ioctl simply sets a state variable 'vm->

Add an ioctl to suspend a virtual machine (VM_SUSPEND). The ioctl can be called
from any context i.e., it is not required to be called from a vcpu thread. The
ioctl simply sets a state variable 'vm->suspend' to '1' and returns.

The vcpus inspect 'vm->suspend' in the run loop and if it is set to '1' the
vcpu breaks out of the loop with a reason of 'VM_EXITCODE_SUSPENDED'. The
suspend handler waits until all 'vm->active_cpus' have transitioned to
'vm->suspended_cpus' before returning to userspace.

Discussed with: grehan

show more ...


# e883c9bb 25-Mar-2014 Tycho Nightingale <tychon@FreeBSD.org>

Move the atpit device model from userspace into vmm.ko for better
precision and lower latency.

Approved by: grehan (co-mentor)


# 22d822c6 18-Mar-2014 Neel Natu <neel@FreeBSD.org>

When a vcpu is deactivated it must also unblock any rendezvous that may be
blocked on it.

This is done by issuing a wakeup after clearing the 'vcpuid' from 'active_cpus'.
Also, use CPU_CLR_ATOMIC()

When a vcpu is deactivated it must also unblock any rendezvous that may be
blocked on it.

This is done by issuing a wakeup after clearing the 'vcpuid' from 'active_cpus'.
Also, use CPU_CLR_ATOMIC() to guarantee visibility of the updated 'active_cpus'
across all host cpus.

show more ...


# 970955e4 18-Mar-2014 Neel Natu <neel@FreeBSD.org>

Notify vcpus participating in the rendezvous of the pending event to ensure
that they execute the rendezvous function as soon as possible.


# 0775fbb4 16-Mar-2014 Tycho Nightingale <tychon@FreeBSD.org>

Fix a race wherein the source of an interrupt vector is wrongly
attributed if an ExtINT arrives during interrupt injection.

Also, fix a spurious interrupt if the PIC tries to raise an interrupt
befo

Fix a race wherein the source of an interrupt vector is wrongly
attributed if an ExtINT arrives during interrupt injection.

Also, fix a spurious interrupt if the PIC tries to raise an interrupt
before the outstanding one is accepted.

Finally, improve the PIC interrupt latency when another interrupt is
raised immediately after the outstanding one is accepted by creating a
vmexit rather than waiting for one to occur by happenstance.

Approved by: neel (co-mentor)

show more ...


# 762fd208 11-Mar-2014 Tycho Nightingale <tychon@FreeBSD.org>

Replace the userspace atpic stub with a more functional vmm.ko model.

New ioctls VM_ISA_ASSERT_IRQ, VM_ISA_DEASSERT_IRQ and VM_ISA_PULSE_IRQ
can be used to manipulate the pic, and optionally the ioa

Replace the userspace atpic stub with a more functional vmm.ko model.

New ioctls VM_ISA_ASSERT_IRQ, VM_ISA_DEASSERT_IRQ and VM_ISA_PULSE_IRQ
can be used to manipulate the pic, and optionally the ioapic, pin state.

Reviewed by: jhb, neel
Approved by: neel (co-mentor)

show more ...


# ef39d7e9 01-Mar-2014 Neel Natu <neel@FreeBSD.org>

Fix a race between VMRUN() and vcpu_notify_event() due to 'vcpu->hostcpu'
being updated outside of the vcpu_lock(). The race is benign and could
potentially result in a missed notification about a pe

Fix a race between VMRUN() and vcpu_notify_event() due to 'vcpu->hostcpu'
being updated outside of the vcpu_lock(). The race is benign and could
potentially result in a missed notification about a pending interrupt to
a vcpu. The interrupt would not be lost but rather delayed until the next
VM exit.

The vcpu's hostcpu is now updated concurrently with the vcpu state change.
When the vcpu transitions to the RUNNING state the hostcpu is set to 'curcpu'.
It is set to 'NOCPU' in all other cases.

Reviewed by: grehan

show more ...


# bdc74e2b 26-Feb-2014 Dimitry Andric <dim@FreeBSD.org>

Merge from head up to r262536.


# dc506506 26-Feb-2014 Neel Natu <neel@FreeBSD.org>

Queue pending exceptions in the 'struct vcpu' instead of directly updating the
processor-specific VMCS or VMCB. The pending exception will be delivered right
before entering the guest.

The order of

Queue pending exceptions in the 'struct vcpu' instead of directly updating the
processor-specific VMCS or VMCB. The pending exception will be delivered right
before entering the guest.

The order of event injection into the guest is:
- hardware exception
- NMI
- maskable interrupt

In the Intel VT-x case, a pending NMI or interrupt will enable the interrupt
window-exiting and inject it as soon as possible after the hardware exception
is injected. Also since interrupts are inherently asynchronous, injecting
them after the hardware exception should not affect correctness from the
guest perspective.

Rename the unused ioctl VM_INJECT_EVENT to VM_INJECT_EXCEPTION and restrict
it to only deliver x86 hardware exceptions. This new ioctl is now used to
inject a protection fault when the guest accesses an unimplemented MSR.

Discussed with: grehan, jhb
Reviewed by: jhb

show more ...


# c98bb15d 21-Feb-2014 Glen Barber <gjb@FreeBSD.org>

MFH: tracking commit

Sponsored by: The FreeBSD Foundation


# 52e5c8a2 20-Feb-2014 Neel Natu <neel@FreeBSD.org>

Simplify APIC mode switching from MMIO to x2APIC. In part this is done to
simplify the implementation of the x2APIC virtualization assist in VT-x.

Prior to this change the vlapic allowed the guest t

Simplify APIC mode switching from MMIO to x2APIC. In part this is done to
simplify the implementation of the x2APIC virtualization assist in VT-x.

Prior to this change the vlapic allowed the guest to change its mode from
xAPIC to x2APIC. We don't allow that any more and the vlapic mode is locked
when the virtual machine is created. This is not very constraining because
operating systems already have to deal with BIOS setting up the APIC in
x2APIC mode at boot.

Fix a bug in the CPUID emulation where the x2APIC capability was leaking
from the host to the guest.

Ignore MMIO reads and writes to the vlapic in x2APIC mode. Similarly, ignore
MSR accesses to the vlapic when it is in xAPIC mode.

The default configuration of the vlapic is xAPIC. The "-x" option to bhyve(8)
can be used to change the mode to x2APIC instead.

Discussed with: grehan@

show more ...


# 5748b897 19-Feb-2014 Martin Matuska <mm@FreeBSD.org>

Merge head up to r262222 (last merge was incomplete).


# abb023fb 08-Feb-2014 John Baldwin <jhb@FreeBSD.org>

Add virtualized XSAVE support to bhyve which permits guests to use XSAVE and
XSAVE-enabled features like AVX.
- Store a per-cpu guest xcr0 register. When switching to the guest FPU
state, switch t

Add virtualized XSAVE support to bhyve which permits guests to use XSAVE and
XSAVE-enabled features like AVX.
- Store a per-cpu guest xcr0 register. When switching to the guest FPU
state, switch to the guest xcr0 value. Note that the guest FPU state is
saved and restored using the host's xcr0 value and xcr0 is saved/restored
"inside" of saving/restoring the guest FPU state.
- Handle VM exits for the xsetbv instruction by updating the guest xcr0.
- Expose the XSAVE feature to the guest only if the host has enabled XSAVE,
and only advertise XSAVE features enabled by the host to the guest.
This ensures that the guest will only adjust FPU state that is a subset
of the guest FPU state saved and restored by the host.

Reviewed by: grehan

show more ...


# 00f3efe1 05-Feb-2014 John Baldwin <jhb@FreeBSD.org>

Add support for FreeBSD/i386 guests under bhyve.
- Similar to the hack for bootinfo32.c in userboot, define
_MACHINE_ELF_WANT_32BIT in the load_elf32 file handlers in userboot.
This allows userbo

Add support for FreeBSD/i386 guests under bhyve.
- Similar to the hack for bootinfo32.c in userboot, define
_MACHINE_ELF_WANT_32BIT in the load_elf32 file handlers in userboot.
This allows userboot to load 32-bit kernels and modules.
- Copy the SMAP generation code out of bootinfo64.c and into its own
file so it can be shared with bootinfo32.c to pass an SMAP to the i386
kernel.
- Use uint32_t instead of u_long when aligning module metadata in
bootinfo32.c in userboot, as otherwise the metadata used 64-bit
alignment which corrupted the layout.
- Populate the basemem and extmem members of the bootinfo struct passed
to 32-bit kernels.
- Fix the 32-bit stack in userboot to start at the top of the stack
instead of the bottom so that there is room to grow before the
kernel switches to its own stack.
- Push a fake return address onto the 32-bit stack in addition to the
arguments normally passed to exec() in the loader. This return
address is needed to convince recover_bootinfo() in the 32-bit
locore code that it is being invoked from a "new" boot block.
- Add a routine to libvmmapi to setup a 32-bit flat mode register state
including a GDT and TSS that is able to start the i386 kernel and
update bhyveload to use it when booting an i386 kernel.
- Use the guest register state to determine the CPU's current instruction
mode (32-bit vs 64-bit) and paging mode (flat, 32-bit, PAE, or long
mode) in the instruction emulation code. Update the gla2gpa() routine
used when fetching instructions to handle flat mode, 32-bit paging, and
PAE paging in addition to long mode paging. Don't look for a REX
prefix when the CPU is in 32-bit mode, and use the detected mode to
enable the existing 32-bit mode code when decoding the mod r/m byte.

Reviewed by: grehan, neel
MFC after: 1 month

show more ...


# 485ac45a 04-Feb-2014 Peter Grehan <grehan@FreeBSD.org>

MFC @ r259205 in preparation for some SVM updates. (for real this time)


# e9ed7bc4 04-Feb-2014 Peter Grehan <grehan@FreeBSD.org>

Roll back botched partial MFC :(


# b4bf798a 04-Feb-2014 Peter Grehan <grehan@FreeBSD.org>

MFC @ r259205 in preparation for some SVM updates.


# ca82a53f 28-Jan-2014 Kai Wang <kaiw@FreeBSD.org>

MFH@261240.


# 30b94db8 25-Jan-2014 Neel Natu <neel@FreeBSD.org>

Support level triggered interrupts with VT-x virtual interrupt delivery.

The VMCS field EOI_bitmap[] is an array of 256 bits - one for each vector.
If a bit is set to '1' in the EOI_bitmap[] then th

Support level triggered interrupts with VT-x virtual interrupt delivery.

The VMCS field EOI_bitmap[] is an array of 256 bits - one for each vector.
If a bit is set to '1' in the EOI_bitmap[] then the processor will trigger
an EOI-induced VM-exit when it is doing EOI virtualization.

The EOI-induced VM-exit results in the EOI being forwarded to the vioapic
so that level triggered interrupts can be properly handled.

Tested by: Anish Gupta (akgupt3@gmail.com)

show more ...


# 2612af8d 21-Jan-2014 Kai Wang <kaiw@FreeBSD.org>

MFH@260988.


# 51f45d01 21-Jan-2014 Neel Natu <neel@FreeBSD.org>

There is no need to initialize the IOMMU if no passthru devices have been
configured for bhyve to use.

Suggested by: grehan@


# 4f18ae67 19-Jan-2014 Glen Barber <gjb@FreeBSD.org>

MFH: Tracking commit (r260891)

Sponsored by: The FreeBSD Foundation


Revision tags: release/10.0.0
# 5b8a8cd1 14-Jan-2014 Neel Natu <neel@FreeBSD.org>

Add an API to rendezvous all active vcpus in a virtual machine. The rendezvous
can be initiated in the context of a vcpu thread or from the bhyve(8) control
process.

The first use of this functional

Add an API to rendezvous all active vcpus in a virtual machine. The rendezvous
can be initiated in the context of a vcpu thread or from the bhyve(8) control
process.

The first use of this functionality is to update the vlapic trigger-mode
register when the IOAPIC pin configuration is changed.

Prior to this change we would update the TMR in the virtual-APIC page at
the time of interrupt delivery. But this doesn't work with Posted Interrupts
because there is no way to program the EOI_exit_bitmap[] in the VMCS of
the target at the time of interrupt delivery.

Discussed with: grehan@

show more ...


# e01ff621 09-Jan-2014 Glen Barber <gjb@FreeBSD.org>

MFH: tracking commit (head@r260486)

Sponsored by: The FreeBSD Foundation


12345678910>>...12