On Fri, May 19, 2017 at 11:54 PM, Waldek Kozaczuk
wrote:
> What do you mean by "exit"? Is it because it calls a function? Would
> inlining help?
>
"VMX" (virtual machine extensions) is Intel's hardware support for
virtualization. What makes it efficient is that the guest code mostly runs
normall
I just wanted to get a sense if my code is logically correct. So what you
looked at is not "reviewable" yet. I am planning to refactor and send
proper patches next week.
The hyperv_clocksource is a new flag that I added to to features in my
branch. I gets set if cpuid logic detects if OSv is runni
Looks reasonable. I don't see all your patches so I can't make a complete
review. In particular where is hyperv_tc64_rdmsr defined? Why is it not in
the this same source file, or if it's in a different one, why is it not
declared in a header file?
I know you copied this from hpet.c, but I would us
What do you mean by "exit"? Is it because it calls a function? Would
inlining help?
On Fri, May 19, 2017 at 4:44 PM, Nadav Har'El wrote:
> Hi,
>
> On Fri, May 19, 2017 at 7:52 AM, Waldek Kozaczuk
> wrote:
>
>> I finally managed to fully boot and execute simple C hello work program
>> on Hyper/V
Hi,
On Fri, May 19, 2017 at 7:52 AM, Waldek Kozaczuk
wrote:
> I finally managed to fully boot and execute simple C hello work program on
> Hyper/V.
>
That's great!
With the patch I sent yesterday allowing a kernel of any size, you should
now be able to run any OSv image when built with fs=ramfs
The essence of my changes is this new clock class
- https://github.com/wkozaczuk/osv/blob/hyperv_vmbus/drivers/hypervclock.cc.
Let me know if this implementation is fundamentally flawed or overly naive.
On Friday, May 19, 2017 at 12:52:55 AM UTC-4, Waldek Kozaczuk wrote:
>
> I finally managed to
