Fix non-deterministic delays when accessing a vcpu in "running" or "s…

machyve / xhyve

xhyve, a lightweight OS X virtualization solution

Other

6.44k stars 353 forks source link

Fix non-deterministic delays when accessing a vcpu in "running" or "s… #81

Open c4milo opened 8 years ago

c4milo commented 8 years ago

…leeping" state.

This is done by forcing the vcpu to transition to "idle" by returning to userspace with an exit code of VM_EXITCODE_REQIDLE.

Ported from bhyve. Authored by @neelnatu Original changetset can be reviewed at:

https://github.com/freebsd/freebsd/commit/3f2b4fc770fb5b735b286cf251b967cfa4afdf12#diff-33af18ae22bfca3128518e240f06893f

Additionally, I added carriage return to the VMM tracing macros to make it easier to visually follow.

c4milo commented 8 years ago

@xez this one doesn't have conflicts.

xez commented 8 years ago

Unlike bhyve, operations on vcpus in xhyve are synchronous with execution. If you are modifying vcpu state it is implied that it is not currently running. Ideally we could get rid of most the associated state tracking and locking. Not sure how applicable this patch would be then. Have to think about this some more.

c4milo commented 8 years ago

@xez, agreed. The single thread restriction is forced by Hypervisor.framework, right? I wondered if it would ever be lifted by Apple. Any comments on this @jeremyhu?

xez commented 8 years ago

KVM has the same 1:1 model of thread:vcpu and task:vm. Modifying vcpu state asynchronously is not necessarily a desirable feature. bhyve has this requirement because they are modifying vcpus out of processes for bootloader and control purposes.