Re: [PATCH][RFC] Supporting EnlightenedWindows2008Server

Re: [PATCH][RFC] Supporting EnlightenedWindows2008Server

[Keir Fraser]

On 8/4/08 18:03, "Ky Srinivasan" <ksrinivasan@novell.com> wrote:

> 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).

That's a bit surprising since w2k8 probably accesses the TPR via %cr8, for
which we implement vmexit mitigation. The only other APIC register that is
often accessed is EOI. We can't avoid the vmexit for that, and the extra
cost of not having an explicit MSR for it is a run through the mmio
emulator. I'd be surprised if avoiding the run through the emulator per
interrupt was that much of a win.

Anyhow, you should be able to switch off HyperV features selectively, as
advertised to the domU HVM guest, and see which ones make a difference to
performance.

 -- Keir

Re: [PATCH][RFC] SupportingEnlightenedWindows2008Server

[Ky Srinivasan]

>>> On Tue, Apr 8, 2008 at  1:15 PM, in message
<C42166D1.16177%keir.fraser@eu.citrix.com>, Keir Fraser
<keir.fraser@eu.citrix.com> wrote: 
> On 8/4/08 18:03, "Ky Srinivasan" <ksrinivasan@novell.com> wrote:
> 
>> 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).
> 
> That's a bit surprising since w2k8 probably accesses the TPR via %cr8, for
> which we implement vmexit mitigation. The only other APIC register that is
> often accessed is EOI. We can't avoid the vmexit for that, and the extra
> cost of not having an explicit MSR for it is a run through the mmio
> emulator. I'd be surprised if avoiding the run through the emulator per
> interrupt was that much of a win.
> 
> Anyhow, you should be able to switch off HyperV features selectively, as
> advertised to the domU HVM guest, and see which ones make a difference to
> performance.

The benchmark was run a while ago on some very early sles10 sp2 bits (late last fall/winter). It is by selectively enabling HyperV functionality that I concluded that APIC MSR access was the most important enlightenment based on NetBench results. We are in the process of running a range of benchmarks. I will keep you posted.

Regards,

K. Y
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH][RFC] SupportingEnlightenedWindows2008Server

[Ky Srinivasan]

>>> On Tue, Apr 8, 2008 at  1:15 PM, in message
<C42166D1.16177%keir.fraser@eu.citrix.com>, Keir Fraser
<keir.fraser@eu.citrix.com> wrote: 
> On 8/4/08 18:03, "Ky Srinivasan" <ksrinivasan@novell.com> wrote:
> 
>> 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).
> 
> That's a bit surprising since w2k8 probably accesses the TPR via %cr8, for
> which we implement vmexit mitigation. The only other APIC register that is
> often accessed is EOI. We can't avoid the vmexit for that, and the extra
> cost of not having an explicit MSR for it is a run through the mmio
> emulator. I'd be surprised if avoiding the run through the emulator per
> interrupt was that much of a win.
> 
> Anyhow, you should be able to switch off HyperV features selectively, as
> advertised to the domU HVM guest, and see which ones make a difference to
> performance.

The benchmark was run a while ago on some very early sles10 sp2 bits (late last fall/winter). It is by selectively enabling HyperV functionality that I concluded that APIC MSR access was the most important enlightenment based on NetBench results. We are in the process of running a range of benchmarks. I will keep you posted.

Regards,

K. Y
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH][RFC] SupportingEnlightenedWindows2008Server

[Ky Srinivasan]

>>> On Tue, Apr 8, 2008 at  1:15 PM, in message
<C42166D1.16177%keir.fraser@eu.citrix.com>, Keir Fraser
<keir.fraser@eu.citrix.com> wrote: 
> On 8/4/08 18:03, "Ky Srinivasan" <ksrinivasan@novell.com> wrote:
> 
>> 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).
> 
> That's a bit surprising since w2k8 probably accesses the TPR via %cr8, for
> which we implement vmexit mitigation. The only other APIC register that is
> often accessed is EOI. We can't avoid the vmexit for that, and the extra
> cost of not having an explicit MSR for it is a run through the mmio
> emulator. I'd be surprised if avoiding the run through the emulator per
> interrupt was that much of a win.
> 
> Anyhow, you should be able to switch off HyperV features selectively, as
> advertised to the domU HVM guest, and see which ones make a difference to
> performance.

The benchmark was run a while ago on some very early sles10 sp2 bits (late last fall/winter). It is by selectively enabling HyperV functionality that I concluded that APIC MSR access was the most important enlightenment based on NetBench results. We are in the process of running a range of benchmarks. I will keep you posted.

Regards,

K. Y
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel