Given I am almost done porting the FreeBSD drivers code for Hyper/V (at least the VMBus part) I have decided to proceed with the implementation of the clock using Hyper/V time synchronization service. This will obviously require putting enough "glue" between the original BSD drivers code and OSv core in form of new classes in drivers/ folder like hyperv::vmbus (modelled after xen::xenbus) and possibly other ones. I will still try to minimize it so I can get the hello work program to fully execute.
I also wanted to ask your advice about approach I should take regarding the organization of patches that I would be eventually sending at some point. I was thinking that my work should be divided in the series of patches. The first one would be a patch with original FreeBSD drivers code and second one would be a patch with all the changes related to porting the code to C++ and when necessary adapting it to OSv APIs. That way I hoped it would make it easy to review to see how I changed the original FreeBSD code. Following patches would focus on building the "glue". In general how incremental these patches should be in your opinion? Regards, Waldek On Wednesday, May 10, 2017 at 3:54:30 AM UTC-4, Nadav Har'El wrote: > > > On Wed, May 10, 2017 at 8:14 AM, Nadav Har'El <n...@scylladb.com > <javascript:>> wrote: > >> >> >> On one hand, tha't nice progress - you can see actual OSv code getting >> printed on hyper-v :-) >> On the other hand, sad that HPET is not supported as a fallback. I looked >> at what Linux did when hyperv first came out, and it seems it used the "PM >> timer" on hyper-V where HPET is not available, which is an ACPI-based >> timer, and seems very simple (see drivers/clocksource/acpi_pm.c). >> I am guessing it should be fairly simple to use the same technique also >> in OSv - copy hpet.cc, hopefully (?) the CMOS stuff will still work but the >> HPET stuff should be replaced by ACPI timer reading stuff which is fairly >> straightforward (you can learn from, but please not copy code from, the >> Linux driver). >> > > One nasty thing about ACPI PM is that the clock wraps around every 2^24 / > 3.58e6 = 4.68 seconds, so we need to somehow keep track of the number of > such wraparounds, or better, set up a timer (e.g., every 4 seconds) to > re-set the current epoch to the current time (and hold this epoch in a 64 > bit variable). I think this is what Linux is doing in > kernel/time/sched_clock.c, but I'm not really sure. Glauber (CCed) would > probably know. > > >> >> >> At this point I'm not sure what would be a more efficient use of your >> time - to implement this pmtimer clock implementation just to get a "hello >> world" application working - or start implementing the hyperv paravirtual >> clock, which eventually you'll want to implement anyway. >> >> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
