Re: [Xen-devel][PATCH][RFC] Supporting Enlightened Windows 2008Server

["Ky Srinivasan" <ksrinivasan@xxxxxxxxxx>]

>>> On Thu, Mar 6, 2008 at  2:28 AM, in message
<C3F54D9B.14C64%keir.fraser@xxxxxxxxxxxxx>, Keir Fraser
<keir.fraser@xxxxxxxxxxxxx> wrote: 
> Personally I think the approach is ugly, and also you have not yet presented
> evidence that supporting the Viridian paravirtualisations improves
> performance.

When I first implemented this (about a year ago), it was not clear if Microsoft 
would be open sourcing the Veridian specification. Given that, I wanted to have 
a narrow set of interfaces both to the adapter as well as from the adapter. I 
take it that you don't care much for this exercise in attempting to isolate the 
adapter. Now that Veridian specification has been open sourced, I agree there 
is no need to isolate the adapter from the base hypervisor the way it is 
currently done. However, given that:
(a) Veridian specification is evolving and Microsoft may define additional 
functionality to improve guest performance
(b) CPUID namespace, MSR namespace and hypercall namespace collisions between 
Xen and Veridian. This is the case today and it can only get worse over time.

I feel having a framework that allows you to implement these kinds of mapping 
layers in complete isolation from the base hypervisor  may in fact be cleaner 
than trying to implement the mapping code inline in the base Xen code.

With regards to performance, we have only run NetBench and on NetBench we have 
seen a 10% improvement (on a uniprocessor system). We have had some issues with 
SMP PV drivers and that is the reason I don't have SMP numbers (the adapter has 
been tested on SMP machines though). We are currently in the process of running 
a range of benchmarks and I will keep you posted on what we see. Our goal here 
is clearly to be competitive (as far as performance goes) with Veridian hosting 
an enlightened windows guest.  
 
> If it doesn't then it's a waste of time; if it does then it
> raises the question of which hypercalls provide the benefit, and do we get a
> smaller neater patch by supporting just those?

I think the only assumption we can make here is  that the enlightenments will 
improve the  guest performance. This has been confirmed with the minimal 
performance testing we have already done.  I am also going to assume that 
Microsoft will continue to evolve Veridian and the set of enlightenments 
visible to their guests to improve performance. The question that we need to 
answer, I think is how are we going to support these enlightenments and not if 
we are going to support Microsoft specific enlightenments. I will be the first 
one to admit the patches I submitted need to be cleaned up:

1) Fix coding style
2) Get rid of code that is not being exercised. Based on the Veridian 
specification I identified a set of functionality that I thought an enlightened 
guest may depend on. It looks like the current shipping windows server 2008 
does not use all the functionality that is currently supported. I am somewhat 
hesitant to get rid of   unused functionality since I don't know what the next 
release of windows will use. In fact, the current shipping windows server 2008 
(32 bit version)  is already using an undocumented hypercall! 

I do think however that having an environment in which we can implement and 
evolve the support for windows enlightenments without constantly churning the 
base Xen code  is the right approach.

Regards,

K. Y  




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel