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][VT] partial PIC to HV patch

To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCh][VT] partial PIC to HV patch
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 22 Sep 2005 11:26:38 +0100
Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>
Delivery-date: Thu, 22 Sep 2005 10:19:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <37FBBA5F3A361C41AB7CE44558C3448E0588473E@pdsmsx403>
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>
References: <37FBBA5F3A361C41AB7CE44558C3448E0588473E@pdsmsx403>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 22 Sep 2005, at 10:33, Dong, Eddie wrote:

Keir:
        This is patch to move PIC mask/EOI access to HV for performance
and we saw about 5% performance increasement with this patch.

I'm not sure about this. I don't much like splitting the implementation of a device across both Xen and qemu -- I'd rather implement entirely within one or the other. Our eventual aim should be to move all non-Xen device models into the context of the vmx domain (running as a paravirt 'mini domain' in rings 1 to 3 of the root vmcs). This might reduce latency enough for most devices to avoid distasteful 'split' device-model implementations.

In the case of local APICs, I/O APICs and the legacy PIC I can accept that, even in the above model there will probably be a measurable performance improvement to implementing these devices within Xen. But I think this should be done by moving their complete implementation into Xen and defining a clean interface to device models running in domain0 and/or rings 1-3. In the case of the PIC, this could be done by having a virtualised 'interrupt wire' for each device (e.g., represent an 'interrupt edge' by a special call into Xen that runs the PIC device model).

The other argument for putting the PIC and IO-APIC in Xen is that the PIT is already there, and having it call out into a non-Xen device model to send interrupts is rather gross.

 -- Keir


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

<Prev in Thread] Current Thread [Next in Thread>