From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 0 of 5] PV on HVM Xen Date: Wed, 17 Mar 2010 17:38:37 +0800 Message-ID: <201003171738.37830.sheng@linux.intel.com> References: <201003151629.12994.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: Jeremy Fitzhardinge , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 would try to make them similar and make the HVM part small enough, then reduce Jeremy's maintain effort. -- regards Yang, Sheng