From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH][v2] Hybrid extension support in Xen Date: Wed, 3 Feb 2010 13:15:06 +0800 Message-ID: <201002031315.06684.sheng@linux.intel.com> References: <201002021616.19189.sheng@linux.intel.com> <201002030031.26179.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: Ian Campbell , "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Wednesday 03 February 2010 02:27:42 Stefano Stabellini wrote: > On Tue, 2 Feb 2010, Sheng Yang wrote: > > Well, for us, we want evtchn because we want to improve interrupt > > intensive passthru device's performance(though too big for the first > > step, we have experiment patches, but would like to consolidate with the > > solution of pv_ops dom0). The situation won't change if we still use > > emulated APIC path... > > I think you should keep this as the last step: once you have all the > other PV features working on HVM like Ian suggested, send a patch to > allow a guest kernel to switch from emulated APIC to evtchn for every > device. > If you manage to keep it simple, it could be a win for everyone. > Make event channel coexist with IOAPIC/LAPIC is quite different from what we are doing now, and Xen already have PV-on-HVM for that. Of course, I also want to have a elegant solution in the end, so I would try hard to keep things simple, and keep the code clear. -- regards Yang, Sheng