>>> On Mon, Apr 7, 2008 at 11:15 AM, in message
<C41FF920.1EDFD%keir.fraser@xxxxxxxxxxxxx>, Keir Fraser
> On 7/4/08 15:28, "Ky Srinivasan" <ksrinivasan@xxxxxxxxxx> wrote:
>>> It's certainly quite a bit shorter which is good. For the remaining stuff,
>>> do you have empirical evidence that performance is improved by it?
>> I do. On the NetBench runs we did, we were seeing close to 10% improvement.
>> will keep you posted on other benchmark results as they become available.
>> Furthermore, as MSFT defines new enlightenments, we can implement those
>> cleanly within this body of code. Additionally, there is value in claiming
>> that we support all the enlightenments needed for hosting enlightened win
> Do you know which hypercalls that benefit comes from? HV_GET_VP_REGISTERS see
> no reason to
> support more hypercalls than necessary (I certainly don't see the value in
> that as an end in itself).
Agreed. Based on the latest hyperv V spec, I think only the following
hypercalls make sense for an enlightened guest:
This is implemented in the patches I have submitted. This hypercall, currently
is not used by the currently shipping windows 2008 server.
2) HV_GET_VP_REGISTERS/ HV_SET_VP_REGISTERS
I only have stub for these hypercalls (not implemented). Current windows 2008
server does not use these hypercalls.
3) HV_SWITCH_VA: I have implemented this hypercall.
I had implemented these hypercalls originally. In the current patch set, I have
stubbed out these hypercalls.
In addition to the hypercalls, Hyper V also surfaces functionality via
synthetic MSRs and CPUID leaves.
I have implemented all the relevant MSRs and CPUID leaves.
>From a performance point of view, I think the MSR access to APIC registers are
>the most important. As far as hypercalls go, the only one currently
>implemented is the hypercall to change the page table base. Some of the other
>synthetic MSRs support features that the current windows 2008 server currently
>is not using (timeouts for example).
> -- Keir
Xen-devel mailing list