From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 0 of 5] PV on HVM Xen Date: Mon, 15 Mar 2010 16:29:12 +0800 Message-ID: <201003151629.12994.sheng@linux.intel.com> References: <201003151205.29964.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: <201003151205.29964.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: Stefano Stabellini Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Monday 15 March 2010 12:05:29 Sheng Yang wrote: > On Saturday 13 March 2010 00:00:42 Stefano Stabellini wrote: > > On Fri, 12 Mar 2010, Stefano Stabellini wrote: > > > My intentions are true so my proposal of working on a common tree is > > > still valid, just let me know when you are interested. > > > > The last versions of our patch series are quite similar, I think at this > > point we can really merge them into one. > > If you take the time to read the last version of my patch series I > > think you'll be able to see it by yourself (missing From: line aside, > > again sorry for that). > > I looked at the last version of yours and I listed the changes I would > > like to be made on top of it, if you and Jeremy agree: > > > > > > PATCH 1 > > fine as it is; > > > > PATCH 2 > > fine as it is; > > > > PATCH 3 > > I would remove it altogether because I would like to make pv drivers > > work on HVM, but considering that at the moment they wouldn't work, > > it makes sense to apply it for now; > > > > PATCH 4 > > I would remove HVMOP_enable_pv, xen_hvm_pv_clock_enabled and the > > pvclock for the moment; > > See my comments below. > > > PATCH 5 > > I would change the entry point because I think the one I use in my > > patch series is less controversial and probably easier to get accepted > > upstream: look at the first part of my second patch; > > My currently evtchn mapping implementation require disable_acpi=1, which is > the same as pv guest(and I would look into your implement to see if it's > still needed), so you can't do it after acpi related initialization. > Anyway, I don't think the position would be a issue for upstream. HV are > picking positions according to their requirement, and there are already > sparse vm enabling codes in setup_arch(). 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) -- regards Yang, Sheng