From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling Date: Fri, 10 Jul 2015 13:05:48 +0200 Message-ID: <1436526348.22672.387.camel@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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6472728246913258098==" Return-path: In-Reply-To: <559F80C6020000780008F348@mail.emea.novell.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: Jan Beulich Cc: Kevin Tian , Feng Wu , George Dunlap , "andrew.cooper3@citrix.com" , xen-devel , Yang Z Zhang , "keir@xen.org" List-Id: xen-devel@lists.xenproject.org --===============6472728246913258098== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TB1eQjVhClJFYMKVNFsl" --=-TB1eQjVhClJFYMKVNFsl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-07-10 at 07:22 +0100, Jan Beulich wrote: > >>> On 10.07.15 at 07:59, wrote: > > If you agree with doing all this in a central place, maybe we can creat= e > > an arch hook for 'struct scheduler' to do this and call it in all the p= laces > > vcpu_runstate_change() gets called. What is your opinion about this? >=20 > Doing this in a central place is certainly the right approach, but > adding an arch hook that needs to be called everywhere > vcpu_runstate_change() wouldn't serve that purpose.=20 > Indeed. > Instead > we'd need to replace all current vcpu_runstate_change() calls > with calls to a new function calling both this and the to be added > arch hook. >=20 Well, I also see the value of having this done in one place, but not to the point of adding something like this. > But please wait for George's / Dario's feedback, because they > seem to be even less convinced than me about your model of > tying the updates to runstate changes. >=20 Indeed. George stated very well the reason why vcpu_runstate_change() should not be used, and suggested arch hooks to be added in the relevant places. I particularly like this idea as, not only it would leave vcpu_runstate_change() alone, but it would also help disentangling this from runstates, which, IMO, is also important. So, can we identify the state (runstate? :-/) transitions that needs intercepting, and find a suitable place where to place hooks? I mean, something like this: - running-->blocked: can be handled in the arch specific part of context switch (similarly to CMT/CAT, which already hooks into there). So, in this case, no need to add any hook, as arch specific code is called already; - running-->runnable: same as above; - running-->offline: not sure if you need to take action on this. If yes, context switch should be fine as well; - blocked-->runnable: I think we need this, don't we? If yes, we probably want an arch hook in vcpu_wake(); - blocked-->offline: do you need it? Well, the hook in wake should work for this as well, if yes; - runnable/running-->offline: if necessary, we want an hook in=20 vcpu_sleep_nosync(). Another way to look at this, less biased toward runstates (i.e., what I've been asking for since a while), would be: - do you need to perform an action upon context switch (on prev and/or next vcpu)? If yes, there's an arch specific path in there already; - do you need to perform an action when a vcpu wakes-up? If yes, we need an arch hook in vcpu_wake(); - do you need to perform an action when a vcpu goes to sleep? If yes, we need an arch hook in vcpu_sleep_nosync(); I think this makes a more than fair solution. I happen to like it even better than the centralized approach, actually! That is for personal taste, but also because I think it may be useful for others too, in future, to be able to execute arch specific code, e.g., upon wakes-up, in which case we will be able to use the hook that we're introducing here for PI. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-TB1eQjVhClJFYMKVNFsl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlWfpxQACgkQk4XaBE3IOsQg7gCgmm8/YdPh7UlOQyFXfPEp1CvJ rFQAnRRscwqWp7V44Y4MUsG1oiZkmn2v =TFPF -----END PGP SIGNATURE----- --=-TB1eQjVhClJFYMKVNFsl-- --===============6472728246913258098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6472728246913258098==--