WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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: Fri, 07 Mar 2008 13:30:35 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 07 Mar 2008 05:31:51 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47D04F2F.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: AciAV2xyqsSP6OxKEdyI9wAX8io7RQ==
Thread-topic: [Xen-devel][PATCH][RFC] Supporting Enlightened Windows 2008Server
User-agent: Microsoft-Entourage/11.4.0.080122
On 7/3/08 01:10, "Ky Srinivasan" <ksrinivasan@xxxxxxxxxx> wrote:

> I agree that there is no need to isolate the shim's dependence on the base Xen
> code (xen_call_vector_t). I implemented this shim a year ago and at that point
> it was not clear what Microsoft might do with the Veridian specification.  So,
> clearly some of the design choices that I made a year ago may not be the right
> choice today. However, I still think that having an intercept framework where
> one can implement Veridian specific functionality without cluttering up the
> base Xen code is still the right approach.

Clearly putting the Viridian hypercall shims in a different file/directory
makes sense. But I think the shims would need to go on a diet. The TLB
flushing implementation is a good example -- the useful extra features of
the Viridian flush hypercall (if there are any, when partnered with Xen's
shadow code) should be pushed into core Xen HVM TLB-flush handling code.
Otherwise it sits out on the periphery with a correspndingly greater
tendency to rot, and for no benefit (certainly I would strongly argue it is
not cleaner!).

 -- Keir



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