1. is the (for virtio already implemented) tscclock an option here?
2. no clue whether there are usable cross-compilation toolchains to build MacOSX binaries on Linux (in a docker container) -- my usual approach is to build on the platform I target (if sufficient resources are available on the target). MirageOS (and OCaml) should also compile seamlessly on MacOSX (and then you won't need Docker, instead let opam drive the compilation) using homebrew (AFAIK, and I don't have a Mac)

1. We don't have the means to calibrate the tscclock in the same way, as the ukvm interface does not emulate a i8254 hardware timer. It also does not emulate the RTC.

   That said, I think all the relevant info can be passed in via ukvm hypercall and then used in the implementation of a couple of functions similar to tscclock_monotonic() and tscclock_epochoffset(), which would be a bit more consistent with the tscclock implementation, although not much code would be shared.

2. Apparently there are cross-compilation toolchains like https://github.com/tpoechtrager/osxcross (as pointed out by @justincormack on slack). Solo5 does not yet compile on MacOSX (though it's close thanks to your work getting it to compile on FreeBSD). I still like the idea of trying to keep everything for building in its own container, but this may not make sense here...

Starting with the two main points in @djwillia's first comment:

1. Regarding PVCLOCK. The proposed change to ukvmclock where the monitor provides a new UKVM_PORT_TIME_INIT which hands the tsc_freq and rtc_boot values to the guest seems reasonable at first glance. However: It's unclear if tsc_freq can be reliably determined on Linux (and you acknowledge that in the function that uses /proc/cpuinfo). There may be something we can do using either MSRs or performance counters, however that may require root which would be bad.

   A bigger issue with the timekeeping implementation on the Hvf side is that it relies on trapping every RDTSC instruction. Keep in mind that timekeeping is extremely performance-sensitive, having every RDTSC cause a VMEXIT is going to be painfully slow.

2. Regarding build tools, the situation thanks to Apple is just bad. While OSX-on-foo cross compilers exist, they rely on users manually downloading the Apple SDK, which is not redistributable (https://www.apple.com/legal/sla/docs/xcode.pdf) and requires an Apple ID to download. In practice I think this means building the OSX parts outside of OSX is not realistic (sorry Dan, your containers won't be redistributable). For a pure native OSX build, I would investigate doing things the other way round, i.e. when building uhvf build/install/otherwise get an ELF toolchain as part of the Solo5 build.

   This does not resolve the question of how the "specialised" uhvf should be built as part of e.g. a MirageOS build process in a container -- I don't have a good idea for this at the moment :-( I see that you've changed ukvm-configure to always try and build ukvm-bin and uhvf-bin, this won't work without an OSX toolchain...

General comments on the code (copied from paper notes, the diff is too big for me to comment on it directly on Github):

• Could you please reformat the changes to use "4 spaces and not tabs"? At the moment there's an indentation mess which makes the diff hard to read.
• You're not using an IDT and uhvf explicitly sets IDTR.base and IDTR.limit to zero. I'm surprised this works at all, I'd expect it to triple-fault and shutdown the VCPU on an exception. Have you verified that you can trap exceptions in uhvf?
• pread_in_full() has an unnecessary change to lseek() / read(). AFAICT OSX has a pread() call, verified on a spare Mac I have.
• ukvm-elf.h is CDDL, I think that needs to be replaced with a suitably licensed copy from one of the BSDs.
• UKVM_PORT_POLL is changed to use pselect(), presumably due to the absence of ppoll() on OSX. This is fine, but we may want platform-dependent implementations of this in the future.
• platform_vcpu_t should be int for KVM, not uint64_t.

Apart from these comments, nice work! The struct platform abstraction makes sense to me, but we need to think about how multi-arch will fit in, hence #151.

Also, I think the changes should be split up somehow. Need to print out(!) the diff and stare at it for a while, will follow up.

This has been superseded by #171, so I think we can close it?

No one's complained and #171 is long since merged, so I'm closing this.