From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 0 of 5] PV on HVM Xen Date: Wed, 17 Mar 2010 10:18:54 -0400 Message-ID: <20100317141854.GA5802@phenom.dumpdata.com> References: <201003151629.12994.sheng@linux.intel.com> <201003171738.37830.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <201003171738.37830.sheng@linux.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Sheng Yang Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, Mar 17, 2010 at 05:38:37PM +0800, Sheng Yang wrote: > On Monday 15 March 2010 20:22:23 Stefano Stabellini wrote: > > On Mon, 15 Mar 2010, Sheng Yang wrote: > > > Hi Stefano > > > > > > I've checked your patches. And one point puzzled me(I am looking into > > > pv_ops dom0 code): seems if it depends on PIRQ, it would still require to > > > do EOI(then result in vmexit) for edge triggered interrupt? (through > > > xen_pirq_chip->end). And unmask is still a heavy work required > > > vmexit?(seems it need twice vmexit, even heavier than current HVM > > > solution) > > > > Only when pirq_needs_eoi(irq) returns true, and this happens when > > PIRQ_NEEDS_EOI is set. > > In my patch series I am making sure PIRQ_NEEDS_EOI is never set for any > > pirq on HVM. > > > OK. > > I would like to work on the PIRQ porting upstream Linux(I would try ACPI but > not sure if it would make code much more complex, e.g. cpu hotplug, PCI > hotplug... A simple version would be just using PIRQ instead of VIRQ in my > patches, but PIRQ is flexible, I would see if I can do more with it). And we > may not get a version exactly the same as pv_ops dom0 code in the end... I That is OK. There is no problems in ripping out the dom0 code and building on top of your code.