I also hoped it would be possible to boot simple "hello world" image on Hyper/V without adding anything to OSv to support Hyper/V drivers. But based on the experiments I conducted yesterday it looks like I will have to add some minimal Hyper/V functionality.
Yesterday I managed to deploy OSv ram disk "hello world" native image to both Azure VM and Hyper/V on my Windows 10 laptop. It look me actually a while to capture some meaningful diagnostics beyond blank screen with blinking cursor (I hope to be able to create some Wiki page about deploying OSv to Azure and Hyper/V soon). On Windows I finally managed to figure out a way to map serial port of OSv vim and capture its output (same on Azure). Here is the output: *OSv v0.24-360-g18a2e45 * *Neither paravirtual clock nor HPET is available. * *Halting.* The good part is that OSv is able to initiate the booting process and recognize serial console. The bad things is hpet does not seem to be supported on Hyper/V at least based on my research. I saw some traces of tsc related code and then there is Hyper-V time synchronization service (https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/integration-services#hyper-v-time-synchronization-service) which would require at least adding VMBus support to OSv as all communication between Hyper/V and VM happens through VMbus channels. So I guess I will also need to port another device driver from BSD and create all other software artifacts needed to recognize Hyper/V and bootstrap VMbus and time service. I will obviously postpone any storage or network device work for later to minimize that work. BTW the BSD time service driver seems to be calling kern_clock_settime (simply update system time). I looked at xenclock.cc for comparison and it seems that it implements system_time() call which seems to read from some shared xen global structure ( xen::xen_shared_info.vcpu_info[cpu_id].time) which I think is updated by xen interrupt handler. Am i mistaken? Waldek PS. Thanks for all the code suggestions. They are definitely helpful. On Sunday, May 7, 2017 at 4:41:13 AM UTC-4, Nadav Har'El wrote: > > > On Sun, May 7, 2017 at 9:09 AM, Waldek Kozaczuk <jwkoz...@gmail.com > <javascript:>> wrote: > >> Hyper/V VMBUS seems be using inter processor interrupts delivered by >> *Synthetic >> Interrupt Controller (SynIC). * >> >> The BSD drivers use lapic_ipi_alloc() which per this patch description ( >> https://reviews.freebsd.org/D2042) dynamically allocates interrupt line. >> I wonder if we could simply use some predefined high enough line. >> > > We have an IPI to allocate an interrupt and assign a handler. > One example from sched.cc: > > inter_processor_interrupt wakeup_ipi{IPI_WAKEUP, [] {}}; > > Here the handler does nothing (the interrupt causes a reschedule, we don't > need anything else to happen). > and from mmu.cc: > > inter_processor_interrupt tlb_flush_ipi{IPI_TLB_FLUSH, [] { > mmu::flush_tlb_local(); > if (tlb_flush_pendingconfirms.fetch_add(-1) == 1) { > tlb_flush_waiter.wake(); > } > }}; > > This allocates an interrupt for this "tlb flush" IPI, and also sets its > handler. > > You also have a method get_vector() on this object to get its vector (if > you need to tell hyperv about it). > > Also, I'm not sure you really need this "ipi" interface - are you planning > to send these IPIs in your own OSv code? If you're not planning to send > them from OSv, only to receive them, you may not need this ipi interface at > all, and can use code like in arch/x64/xen.cc - > > auto vector = idt.register_interrupt_handler( > [] { return true;}, // pre_eoi > [] { xen_ack_irq(); }, // eoi > [] { xen_handle_irq(); }// handler > ); > > xhp.value = vector | (2ULL << 56); > > if (hvm_hypercall(HVMOP_set_param, &xhp)) > assert(0); > > This code allocates an interrupt vector, and then tells Xen about it. > (there are few more variants of this in xen.cc). > > P.S. I'm not at all familiar with HyperV's architecture. If you don't want > a disk or network (e.g., to just print "hello world"), is it necessary to > do anything HyperV-specific? Doesn't it emulate a normal x86 system like > KVM? Or are you already thinking ahead, beyond "hello world" and about disk > and network drivers? > > Nadav. > -- 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.
