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: Thu, 9 Jul 2015 10:18:24 +0200 Message-ID: <1436429904.22672.269.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0107406092528639219==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Wu, Feng" Cc: "Tian, Kevin" , "keir@xen.org" , "george.dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , xen-devel , "jbeulich@suse.com" , "Zhang, Yang Z" List-Id: xen-devel@lists.xenproject.org --===============0107406092528639219== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/WOrjgLvqNR6WvbXBkj5" --=-/WOrjgLvqNR6WvbXBkj5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-07-09 at 03:09 +0000, Wu, Feng wrote: > > -----Original Message----- > > From: Dario Faggioli [mailto:dario.faggioli@citrix.com] > > In fact, looking at how, where and what for, runstetes are used, that > > really does not feel right, at least to me. What you seem to be > > interested is whether a vCPU blocks and/or unblocks >=20 > Not just blocks, unblocks, we need to track the state transition, and > update posted-interrupt descriptor accordingly. >=20 And why is that so? What is it that runstates gives you, that you don't find where I'm suggesting to look? What's so in specific need of knowing the runstate? > Runstates are an > > abstraction, build up on top of (mostly) pause_flags, like _VPF_blocked > > (look at how runstate is updated). > >=20 > > I think you should not build on top of such abstraction, but on top of > > pause_flags directly. >=20 > I don't think building on top of vCPU state is not suitable for my case, > the abstraction is there, why cannot people use it? >=20 Because, IMO, your stuff is a low level feature, and it does not feel right to me to build low level feature on top or (quite) high level abstraction, such as runstates. The fact that your feature is arch specific is quite a clear sign of that. Runstates aren't. Actually, very few of what is in schedule.c is. A notable exception is the low level context switching logic... and, in fact, that's exactly where I think your stuff should leave, if possible (and it looks possible to me (I take counterexamples, of course). And it's not an aesthetic and/or some kind of 'layering violation' issue (although, it certainly is one, and it makes the code harder to understand and follow, both wrt your own feature, and in general), it really looks like calling for problems and potential maintenance issues. Anyway, I guess this is George's call. Let's see if/when he finds some time to give us an opinion. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-/WOrjgLvqNR6WvbXBkj5 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 iEYEABECAAYFAlWeLlkACgkQk4XaBE3IOsRMDQCfWBnG2NB/lF0mkPVp8d4G9fnN S1EAn3niYNnFE1tGj9EGw38v8XSXTU7j =UFrP -----END PGP SIGNATURE----- --=-/WOrjgLvqNR6WvbXBkj5-- --===============0107406092528639219== 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 --===============0107406092528639219==--