This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel][PATCH][RFC] Supporting Enlightened Windows 2008Server
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sat, 05 Apr 2008 10:21:35 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 05 Apr 2008 02:22:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47F68017.E57C.0030.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciW/nF9sBeAsQLxEd2FkwAWy6hiGQ==
Thread-topic: [Xen-devel][PATCH][RFC] Supporting Enlightened Windows 2008Server
User-agent: Microsoft-Entourage/
On 5/4/08 00:24, "Ky Srinivasan" <ksrinivasan@xxxxxxxxxx> wrote:

> Based on the feedback I got from you and Tim, I am enclosing the next version
> of the patches to support enlightened win2008 server. Here are the changes I
> have made:
> 1) I have put the shim on a low calorie diet - I have gotten rid of the
> framework infrastructure and to the extent possible integrated the shim code
> with xen.
> 2) I have tried to cleanup the code. I am sure  more work will be needed here.
> 3) I am not advertising the TLB related enlightenments. We can revisit this
> later if needed.

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?

Other more minor comments are that the coding style is still off (e.g.,
start braces should go on their own line, spaces inside () for if/for/while
headers), you have at least one big switch statement where most of the cases
could be collapsed to just one shared block of code, and indeed shouldn't
the 'default' case in the hypercall demuxing switch statement be to return
'denied', and that would get rid of most of the individual cases altogether?

 -- Keir

Xen-devel mailing list