From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling Date: Tue, 14 Jul 2015 17:41:29 +0100 Message-ID: <55A53BB9.2090302@eu.citrix.com> References: <1435123109-10481-15-git-send-email-feng.wu@intel.com> <55918214.4030102@citrix.com> <1435633087.25170.274.camel@citrix.com> <1435825253.25170.406.camel@citrix.com> <559E6EB7.3050609@eu.citrix.com> <559E96E0020000780008ED84@mail.emea.novell.com> <1436451512.22672.333.camel@citrix.com> <559E84EF.7060507@eu.citrix.com> <559F80C6020000780008F348@mail.emea.novell.com> <1436526348.22672.387.camel@citrix.com> <55A53EC60200007800090D3E@mail.emea.novell.com> <1436887210.13522.158.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1436887210.13522.158.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , Jan Beulich Cc: Kevin Tian , "keir@xen.org" , "andrew.cooper3@citrix.com" , xen-devel , Yang Z Zhang , Feng Wu List-Id: xen-devel@lists.xenproject.org On 07/14/2015 04:20 PM, Dario Faggioli wrote: > On Tue, 2015-07-14 at 15:54 +0100, Jan Beulich wrote: >>>>> On 14.07.15 at 16:08, wrote: >>> Thanks for the suggestion! I made a draft patch for this idea, It may have >>> some issues since It is just a draft version, kind of like prototype, I post >>> it here just like to know whether it is meet your expectation, if it is I >>> can continue with this direction and this may speed up the upstreaming >>> process. Thanks a lot! >> >> FWIW this looks okay to me as a draft (i.e. minus mechanical issues). >> If it meets your requirements, I think this would nicely eliminate all the >> objections against the earlier model. But let's see what Dario and >> George think... >> > I'll reply to the Feng's email in more detail (even considering that > it's a draft), but yes, indeed, this looks *a lot* nicer, a way better > way of interacting with the scheduler! > > The approach is exactly the one I had in mind and was asking Feng to > investigate, and I like the result much better than the old > runstate-based hack-ish model. :-) Yes, I prefer this approach -- thank you. -George