Page MenuHomeFreeBSD

domagoj.stolfa_gmail.com (Domagoj Stolfa)
User

Projects

User Details

User Since
Sep 8 2016, 3:21 PM (297 w, 8 h)

Recent Activity

Mar 5 2022

domagoj.stolfa_gmail.com accepted D34362: linker: Permit CTFv3 containers.
Mar 5 2022, 11:13 AM
domagoj.stolfa_gmail.com accepted D34360: ctf: Add definitions for CTFv3.

I've read through the man page changes twice and couldn't find anything wrong. LGTM but maybe a read through by someone from docs would be a good idea.

Mar 5 2022, 1:55 AM
domagoj.stolfa_gmail.com accepted D34358: ctf: Import ctf.h from OpenBSD.
Mar 5 2022, 1:43 AM

Mar 2 2022

domagoj.stolfa_gmail.com added a comment to D34363: libctf: Handle CTFv3 containers.

Both seem reasonable to me. I'll aim to run some more tests with this and look it over one more time in detail by Friday and flag if I find anything, but overall looks good to me. Thanks for working on this!

Mar 2 2022, 2:40 PM
domagoj.stolfa_gmail.com added a comment to D34363: libctf: Handle CTFv3 containers.

Overall the patch looks good to me. I've run all of this under ASAN + UBSAN (with the full patch set applied) and nothing was flagged in this code as problematic when running the DTrace test suite and the FreeBSD build. I feel like it might be a good idea to properly restructure the code around CTFv2 and CTFv3 to account for other versions in the API rather than relying on the "else" case always being v3, but aside from that LGTM. @markj: what do you think about the alignment warning/error propagation?

Mar 2 2022, 2:07 PM
domagoj.stolfa_gmail.com added inline comments to D34360: ctf: Add definitions for CTFv3.
Mar 2 2022, 1:08 PM

Feb 24 2022

domagoj.stolfa_gmail.com requested changes to D34360: ctf: Add definitions for CTFv3.

The code looks good to me, but it probably needs man page changes like @debdrup mentioned. I also wonder if adding a comment at the top of the header somewhere simply stating what CTFv2 and CTFv3 are and how they differ at a high level makes sense. Perhaps in one or two short sentences so that if someone unfamiliar with CTF wants to simply use the header knows what they're working with without needing to read through a fairly detailed man page? Do you have any thoughts on this?

Feb 24 2022, 2:23 PM
domagoj.stolfa_gmail.com added a comment to D34358: ctf: Import ctf.h from OpenBSD.

The original CTF header has a bunch of useful comments describing the format. Perhaps these things should be included in this header too? While I appreciate that this is an import, those comments have helped me quite a bit when dealing with CTF and IMO should be included.

There is a ctf.5 man page that describes the format in much more detail than the comments did. I haven't updated it yet for v3 but will do so. Do you think it is sufficient to reference the man page here?

Feb 24 2022, 2:16 PM
domagoj.stolfa_gmail.com accepted D34359: linker: Simplify CTF container handling.

This looks good to me. Thanks!

Feb 24 2022, 2:10 PM
domagoj.stolfa_gmail.com added a comment to D34358: ctf: Import ctf.h from OpenBSD.

The original CTF header has a bunch of useful comments describing the format. Perhaps these things should be included in this header too? While I appreciate that this is an import, those comments have helped me quite a bit when dealing with CTF and IMO should be included.

Feb 24 2022, 2:07 PM

Dec 10 2021

domagoj.stolfa_gmail.com requested review of D33378: dtrace: Disable getf() as it is broken on FreeBSD..
Dec 10 2021, 7:26 PM

Sep 23 2021

domagoj.stolfa_gmail.com accepted D31494: developers-handbook: update the section on Remote GDB.
In D31494#723995, @jhb wrote:

Thanks for writing this up @mhorne, much appreciated! I've left a few comments from my experience of setting it up with QEMU + KVM today and the confusion I had while reading the existing documentation, as well as the confusion that I would probably have while reading this.

I wonder if it might make sense to explicitly state that the procedure for virtualization gdb stubs may be different depending on which hypervisor/emulator is being used, and then in follow-up commits (by you or anyone else really) document the procedure for each given hypervisor?

Right, the process for remote gdb is a little different when you are using a hypervisor, mainly because the hypervisor can pause execution automatically when it detects that a client has connected to its gdb stub. For the gdb stub implemented by the kernel, we must force a trap into the debugger in order to detect that a client has detected. That is why this chapter lists extra steps that you did not need.

I didn't come up with any text to really highlight this difference, but I think it will be easier to do once we add a separate [sub]section for remote gdb using bhyve/kvm/whatever. You can suggest specific text for the intro paragraph if you like.

Yes, I think we will want to add a separate section for bare-metal debugging with a hypervisor vs using serial to talk to the in-kernel stub which is what this currently documents.

Sep 23 2021, 6:36 PM

Sep 12 2021

domagoj.stolfa_gmail.com added a comment to D31494: developers-handbook: update the section on Remote GDB.

Thanks for writing this up @mhorne, much appreciated! I've left a few comments from my experience of setting it up with QEMU + KVM today and the confusion I had while reading the existing documentation, as well as the confusion that I would probably have while reading this.

Sep 12 2021, 8:56 PM

Sep 4 2021

domagoj.stolfa_gmail.com accepted D30286: kqueue: add EV_KEEPUDATA flag.

@jhb Any chance you could push this? I've been using this for months and it's worked well for me.

Sep 4 2021, 10:51 PM

Jun 16 2021

domagoj.stolfa_gmail.com added a comment to D30778: dtrace: fix an out of bound read and a NULL pointer increment.

If there are any tags, e.g., sponsored by, please add them to the review description and I'll commit.

You can add a Signed-off-by: domagoj.stolfa@gmail.com if you'd like

I prefer not to since we don't have a policy around it, at least not yet. If you prefer to have it, then I'll keep it.

Jun 16 2021, 3:45 PM · DTrace
domagoj.stolfa_gmail.com updated the summary of D30778: dtrace: fix an out of bound read and a NULL pointer increment.
Jun 16 2021, 3:02 PM · DTrace
domagoj.stolfa_gmail.com updated the summary of D30778: dtrace: fix an out of bound read and a NULL pointer increment.
Jun 16 2021, 3:02 PM · DTrace
domagoj.stolfa_gmail.com added a comment to D30778: dtrace: fix an out of bound read and a NULL pointer increment.

If there are any tags, e.g., sponsored by, please add them to the review description and I'll commit.

Jun 16 2021, 3:01 PM · DTrace

Jun 15 2021

domagoj.stolfa_gmail.com requested review of D30778: dtrace: fix an out of bound read and a NULL pointer increment.
Jun 15 2021, 8:20 PM · DTrace

May 27 2021

domagoj.stolfa_gmail.com accepted D30255: style: Relax 80 column rule.

This seems reasonable to me.

May 27 2021, 5:58 PM

May 16 2021

domagoj.stolfa_gmail.com added a comment to D30286: kqueue: add EV_KEEPUDATA flag.

I've been using this locally and found it *extremely* useful, and frankly was quite surprised when I found out that EV_ENABLE/EV_DISABLE trashed udata originally.

May 16 2021, 12:29 PM

May 13 2021

domagoj.stolfa_gmail.com added a comment to D30255: style: Relax 80 column rule.
In D30255#679519, @sef wrote:

I still use an 80 character limit, and an 80 character-wide Terminal window.

Usually my opinion means everyone else has moved on :).

May 13 2021, 10:15 PM
domagoj.stolfa_gmail.com updated the diff for D30248: run uncrustify over vtfontcvt.c.

Remove a whole bunch of noise compared to the previous diff.

May 13 2021, 3:58 PM
domagoj.stolfa_gmail.com edited P500 uncrustify freebsd.cfg.
May 13 2021, 3:58 PM
domagoj.stolfa_gmail.com updated the summary of D30248: run uncrustify over vtfontcvt.c.
May 13 2021, 3:47 PM
domagoj.stolfa_gmail.com created P500 uncrustify freebsd.cfg.
May 13 2021, 3:46 PM
domagoj.stolfa_gmail.com updated the diff for D30248: run uncrustify over vtfontcvt.c.

Update the diff with -U999999

May 13 2021, 3:43 PM
domagoj.stolfa_gmail.com added inline comments to D30248: run uncrustify over vtfontcvt.c.
May 13 2021, 3:41 PM
domagoj.stolfa_gmail.com requested review of D30248: run uncrustify over vtfontcvt.c.
May 13 2021, 3:16 PM

Apr 1 2021

domagoj.stolfa_gmail.com updated the diff for D29541: DTrace: document the "nolibs" option.
Apr 1 2021, 10:28 PM · DTrace
domagoj.stolfa_gmail.com added inline comments to D29541: DTrace: document the "nolibs" option.
Apr 1 2021, 9:50 PM · DTrace
domagoj.stolfa_gmail.com updated the diff for D29541: DTrace: document the "nolibs" option.

@markj 's comments.

Apr 1 2021, 9:50 PM · DTrace
domagoj.stolfa_gmail.com added inline comments to D29541: DTrace: document the "nolibs" option.
Apr 1 2021, 9:22 PM · DTrace
domagoj.stolfa_gmail.com updated the diff for D29541: DTrace: document the "nolibs" option.

Added -x libdir and -x syslibdir as suggested by @markj

Apr 1 2021, 9:21 PM · DTrace
domagoj.stolfa_gmail.com requested review of D29541: DTrace: document the "nolibs" option.
Apr 1 2021, 8:50 PM · DTrace

Mar 27 2021

domagoj.stolfa_gmail.com added inline comments to D29435: CTF: Fix an out-of-bounds read.
Mar 27 2021, 6:02 PM · DTrace
domagoj.stolfa_gmail.com updated the diff for D29435: CTF: Fix an out-of-bounds read.
Mar 27 2021, 6:01 PM · DTrace
domagoj.stolfa_gmail.com added a comment to D29435: CTF: Fix an out-of-bounds read.

(Please let me know if you'd like me to commit this.)

Mar 27 2021, 3:43 PM · DTrace

Mar 26 2021

domagoj.stolfa_gmail.com requested review of D29435: CTF: Fix an out-of-bounds read.
Mar 26 2021, 7:18 PM · DTrace

Aug 27 2018

domagoj.stolfa_gmail.com added a comment to D16921: Attempt to support multiple tracepoints with the same address..

I think it would be nicer to instead keep all tracepoints for a given address on a linked list, with a single hash table entry for all of them. fbt_invop() would invoke dtrace_probe() for each probe associated with the tracepoint, which should be fine so long as there aren't many. (With ifuncs there will be 2.)

Perhaps we could even bunch them into a bounded array (or a vector-like implementation) and check it at fbt load-time in order to avoid indirection? A linked list is unlikely to be too painful given all the membars and indirection happening in dynamic variable implementation -- but nonetheless would degrade performance :-).

I think it's acceptable for the time being since, as I pointed out, there are at most 2 probes for a given tracepoint currently. The FBT hash table is itself cache-unfriendly, and I'd rather fix the performance problems there holistically. Here's the distribution of hash chain lengths on a system with a fairly stripped-down kernel:

5395 0
9755 1
8748 2
5244 3
2369 4
 876 5
 280 6
  73 7
  24 8
   3 9
   1 10
Aug 27 2018, 6:28 PM
domagoj.stolfa_gmail.com added a comment to D16921: Attempt to support multiple tracepoints with the same address..

I think it would be nicer to instead keep all tracepoints for a given address on a linked list, with a single hash table entry for all of them. fbt_invop() would invoke dtrace_probe() for each probe associated with the tracepoint, which should be fine so long as there aren't many. (With ifuncs there will be 2.)

Aug 27 2018, 5:15 PM
domagoj.stolfa_gmail.com added a comment to D16921: Attempt to support multiple tracepoints with the same address..

Why "additional"? The problem exists regardless since fbt_invop() returns after the first matching tracepoint. The problem was invisible before ifuncs since before that all tracepoints had distinct addresses. This patch just hides the problem in the common case.

Aug 27 2018, 4:38 PM
domagoj.stolfa_gmail.com added a comment to D16921: Attempt to support multiple tracepoints with the same address..

I'm a little worried that this may cause additional confusion if someone expects multiple probes to fire at that point. I wonder if a better workaround would be to just add a warning message whenever DTrace is called, or perhaps when someone calls dtrace -l, in the man page or something along the lines until we fix? Is there a reason we can't fix this in 13 and MFC the changes?

Aug 27 2018, 4:25 PM

May 8 2018

domagoj.stolfa_gmail.com updated the diff for D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

Preemptively remove a redundant check for INKERNEL(fp).

May 8 2018, 9:23 PM · arm64, DTrace
domagoj.stolfa_gmail.com added a comment to D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

Why not just exclude it in fbt_provide_module_function? I'd prefer we keep the unwinding code together, maybe with a comment that it may be called from such a context.

May 8 2018, 9:22 PM · arm64, DTrace
domagoj.stolfa_gmail.com added a comment to D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.

however, in the future a patch that enabled instrumentation of inlined functions could accidentally break DTrace on aarch64.

Was the problem found while working on such a patch? :)

May 8 2018, 8:55 PM · arm64, DTrace
domagoj.stolfa_gmail.com updated the summary of D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.
May 8 2018, 8:51 PM · arm64, DTrace
domagoj.stolfa_gmail.com created D15359: DTrace aarch64: Avoid calling unwind_frame() in the probe context.
May 8 2018, 8:37 PM · arm64, DTrace

Apr 30 2018

domagoj.stolfa_gmail.com accepted D15221: Disable connectat/bindat with AT_FDCWD parameter in capabilities mode.

Had a quick skim, but LGTM.

Apr 30 2018, 4:05 PM · capsicum

Apr 21 2018

domagoj.stolfa_gmail.com added inline comments to D15150: Split procfs_attr into multiple functions.
Apr 21 2018, 7:54 PM

Apr 12 2018

domagoj.stolfa_gmail.com added a comment to D14656: Add SDT probes to the VMX VMexit interface.

Is this good to land? Thanks!

Apr 12 2018, 4:31 PM · DTrace, bhyve

Apr 6 2018

domagoj.stolfa_gmail.com updated the diff for D14863: DTrace: Add an invariant to check for recursion in dtrace_probe().

Address the other comments by @markj and fix a misleading word in the dtrace_probe_exit() comment.

Apr 6 2018, 5:11 PM
domagoj.stolfa_gmail.com removed 1 blocking reviewer(s) for D14863: DTrace: Add an invariant to check for recursion in dtrace_probe(): gnn.
Apr 6 2018, 4:51 PM
domagoj.stolfa_gmail.com updated the diff for D14863: DTrace: Add an invariant to check for recursion in dtrace_probe().

Address comments by @markj.

Apr 6 2018, 4:50 PM

Apr 4 2018

domagoj.stolfa_gmail.com added inline comments to D9988: Add support for a copyoutmbuf() subroutine for DTrace..
Apr 4 2018, 6:02 PM
domagoj.stolfa_gmail.com added inline comments to D9988: Add support for a copyoutmbuf() subroutine for DTrace..
Apr 4 2018, 4:32 PM

Apr 3 2018

domagoj.stolfa_gmail.com added a comment to D14863: DTrace: Add an invariant to check for recursion in dtrace_probe().

Is there anything else I can do for this to land?

Apr 3 2018, 9:55 PM

Mar 28 2018

domagoj.stolfa_gmail.com added a comment to D14656: Add SDT probes to the VMX VMexit interface.

Should I make any more changes for this to land? As an aside note: I've tried to make the interface as simple as possible to use with the args[0-2] being consistent.

Mar 28 2018, 3:11 PM · DTrace, bhyve

Mar 27 2018

domagoj.stolfa_gmail.com abandoned D14862: Make INVARIANTS enable DEBUG in DTrace.
In D14862#312653, @avg wrote:

FWIW, rS253996 is what I did to translate INVARIANTS to DEBUG for ZFS.
Seems like the commit even touched some dtrace modules.

Mar 27 2018, 5:04 PM
domagoj.stolfa_gmail.com updated the diff for D14862: Make INVARIANTS enable DEBUG in DTrace.

Update the diff based on comments from @markj.

Mar 27 2018, 4:49 PM
domagoj.stolfa_gmail.com added inline comments to D14862: Make INVARIANTS enable DEBUG in DTrace.
Mar 27 2018, 4:44 PM

Mar 26 2018

domagoj.stolfa_gmail.com updated the summary of D14863: DTrace: Add an invariant to check for recursion in dtrace_probe().
Mar 26 2018, 11:25 PM
domagoj.stolfa_gmail.com created D14863: DTrace: Add an invariant to check for recursion in dtrace_probe().
Mar 26 2018, 11:23 PM
domagoj.stolfa_gmail.com created D14862: Make INVARIANTS enable DEBUG in DTrace.
Mar 26 2018, 10:33 PM

Mar 11 2018

domagoj.stolfa_gmail.com created D14656: Add SDT probes to the VMX VMexit interface.
Mar 11 2018, 6:21 PM · DTrace, bhyve

Jan 12 2018

domagoj.stolfa_gmail.com updated the diff for D13877: DTrace: Add jailname/jid builtins.

Address the comments by markj@ and add tests in safety/ for jailname and jid.

Jan 12 2018, 5:15 PM · DTrace
domagoj.stolfa_gmail.com updated the diff for D13877: DTrace: Add jailname/jid builtins.

Update the diff to add more context. No actual code was changed.

Jan 12 2018, 2:01 PM · DTrace
domagoj.stolfa_gmail.com added inline comments to D13877: DTrace: Add jailname/jid builtins.
Jan 12 2018, 1:13 PM · DTrace
domagoj.stolfa_gmail.com updated the summary of D13877: DTrace: Add jailname/jid builtins.
Jan 12 2018, 1:11 PM · DTrace
domagoj.stolfa_gmail.com added a comment to D13877: DTrace: Add jailname/jid builtins.

Tracing on a per-jail basis using a predicate was already possible (example below):

someprobe /curthread->td_proc->p_ucred->cr_prison->pr_id == $1/
{
        /* some actions */
}

That's true, however, this exposes a stable interface that people can use without following pointers in the D script and instead simply calling into a builtin variable. I'd imagine this is the same reason why you would want to have execname, errno, uid, gid and others, as they can also be accessible via other, more primitive builtins.

Don't get me wrong, I like the analog to Solaris's zonename and thus think jailname and jid are good additions.

I just wanted to point out that curthread already gives us access to far more details than the few given at the top-level.

Programs like "dwatch" (reviews.freebsd.org/D10006) make it possible to access not-only curthread details but the details of the parent, grandparent, and ancestor process(es), and thus the ability to trace a jail is neither novel nor unique.

If you're ever looking for inspiration on other top-level variables that might be nice-to-haves without having to crawl curthread->td_proc (as dwatch does), give dwatch a trial run.

Jan 12 2018, 1:07 PM · DTrace

Jan 11 2018

domagoj.stolfa_gmail.com added a comment to D13877: DTrace: Add jailname/jid builtins.

Tracing on a per-jail basis using a predicate was already possible (example below):

someprobe /curthread->td_proc->p_ucred->cr_prison->pr_id == $1/
{
        /* some actions */
}
Jan 11 2018, 11:56 PM · DTrace
domagoj.stolfa_gmail.com updated the summary of D13877: DTrace: Add jailname/jid builtins.
Jan 11 2018, 10:50 PM · DTrace
domagoj.stolfa_gmail.com created D13877: DTrace: Add jailname/jid builtins.
Jan 11 2018, 10:48 PM · DTrace

Jun 18 2017

domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

Update the diff to reflect changes in HEAD with bhyve identification. This diff no longer requires it.

Jun 18 2017, 10:05 PM

Jun 10 2017

domagoj.stolfa_gmail.com created D11138: UUID API extension to allow for comparison.
Jun 10 2017, 5:43 PM

Mar 3 2017

domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

Update the diff to address the compilation errors due to the way clang 4.0 handles -Wstrict-prototypes.

Mar 3 2017, 7:00 PM

Feb 2 2017

domagoj.stolfa_gmail.com added a member for DTrace: domagoj.stolfa_gmail.com.
Feb 2 2017, 5:58 PM

Dec 19 2016

domagoj.stolfa_gmail.com added inline comments to D8100: Bhyve hypercall implementation.
Dec 19 2016, 1:17 PM
domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

This diff changes the following:

  • Remove DTrace stuff as much as possible, create a prototype instead
  • Remove the unnecessary static NULL assignments in the hc_dispatcher
  • Reiterate the instructions on some parts of the code
Dec 19 2016, 1:14 PM

Dec 3 2016

domagoj.stolfa_gmail.com added a comment to D8100: Bhyve hypercall implementation.

Point out an issue regarding mi_startup.

Dec 3 2016, 12:50 PM
domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

Address some style(9) issues, fix a comment.

Dec 3 2016, 12:40 AM

Nov 27 2016

domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

License bhyve_hypercall.S under the FreeBSD preferred license.

Nov 27 2016, 6:17 PM
domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

Remove the unused include in bhyve_hypercall.h

Nov 27 2016, 4:52 PM
domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

Address the points discussed at MeetBSD.

Nov 27 2016, 4:12 PM

Oct 13 2016

domagoj.stolfa_gmail.com updated the test plan for D8100: Bhyve hypercall implementation.
Oct 13 2016, 11:55 PM
domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

Addresses a late noticed typo in the macro HC_CPUID_ID which in fact should be HV_CPUID_ID.

Oct 13 2016, 11:49 PM
domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

This patch addresses a couple of issues:

  • Allow global enabling and disabling of hypercalls. The hypercall exists are by default disabled
  • Add the necessary dispatchers and handlers for a hypervisor emulation layer
  • Clean up the bhyve_hypercall.h using macros and revert to the calling convention that uses the stack
  • Add a tunable which allows setting of the hypervisor mode
  • Unimplemented hypercalls now cause an #UD fault
  • CPUID_4000_0001 gives information in EAX whether hypercalls are enabled or not
Oct 13 2016, 11:41 PM

Oct 3 2016

domagoj.stolfa_gmail.com added inline comments to D8100: Bhyve hypercall implementation.
Oct 3 2016, 4:50 PM
domagoj.stolfa_gmail.com updated the diff for D8100: Bhyve hypercall implementation.

This patch should address some of the concerns brought on by Peter.

Oct 3 2016, 4:47 PM

Oct 1 2016

domagoj.stolfa_gmail.com added a comment to D8100: Bhyve hypercall implementation.

Thanks for this work - it will be very useful.

Some general high-level comments:

  • There are a number of guest users of hypercalls: KVM, Xen, Hyper-V. Since bhyve may emulate some/all of these hypercalls, it's probably worthwhile looking at the call sequences they use to try and co-exist. For example, it may even be useful at some future point to have DTrace support in those hypervisors.
  • In a similar vein, 'hypercall.h' should probably be 'bhyve_hypercall.h'
  • the hypercall exit should be disabled by default unless a tunable is set. It's an attack point that should only be enabled through hypervisor configuration. While there isn't currently a generic way to set per-guest configuration, there will be at some point, at which time this feature could be shifted over to that instead of having a global enable/disable.
  • in addition, a future work item, and not really part of this review, is to have a CPUID space carved out for bhyve that will provide a way for the guest to determine if the hypercall facility is available. See the KVM docs for an example of how this is done.
Oct 1 2016, 2:57 PM

Sep 30 2016

domagoj.stolfa_gmail.com added a comment to D8100: Bhyve hypercall implementation.

Thanks for the review Peter. I'll address these issues as soon as possible.

Sep 30 2016, 8:53 PM
domagoj.stolfa_gmail.com added inline comments to D8100: Bhyve hypercall implementation.
Sep 30 2016, 8:42 PM
domagoj.stolfa_gmail.com added a comment to D8100: Bhyve hypercall implementation.

Added some explanations.

Sep 30 2016, 7:57 PM
domagoj.stolfa_gmail.com retitled D8100: Bhyve hypercall implementation from to Bhyve hypercall implementation.
Sep 30 2016, 7:54 PM