From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Requesting for freeze exception for VT-d posted-interrupts Date: Mon, 13 Jul 2015 17:38:24 +0200 Message-ID: <1436801904.13522.54.camel@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1570134343933740478==" 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" , "wei.liu2@citrix.com" , George Dunlap , "andrew.cooper3@citrix.com" , "Wang, Yong Y" , "xen-devel@lists.xen.org" , "Jan Beulich (JBeulich@suse.com)" , "Zhang, Yang Z" List-Id: xen-devel@lists.xenproject.org --===============1570134343933740478== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uiwBd2jKPnyg3IeHBlVy" --=-uiwBd2jKPnyg3IeHBlVy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-07-13 at 06:55 +0000, Wu, Feng wrote: > There are two main outstanding issues so far: > 1. Jan's security concern. I have proposed some solutions but Jan still h= as > some problems with my proposals. It would be great if Jan can give a clea= r > proposal so that we can discuss and keep making progress. > 2. Scheduler issue: there are conflicts among maintainers Jan/George/Dari= o. > I would agree with Jan's suggestion below: >=20 Oh, so there are conflicts, eh? Let's have a look. I said, basically, that you should change things so that you update your data structure in the actual places where the events calling for such an update happen. I'm not maintaining any code you touch, though. I'm a quite active developer in scheduling, and plan to continue to be, but let's look at maintainers. Jan is one of the maintainer of almost all the code you touch (one of the few exceptions being scheduling), and he said this that you're quoting: > " 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. 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 but also this, that you may have "forgot": "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" Let's look at George, then, which is the formal and official authority here: "The right thing to do in this situation is either to change vcpu_runstate_change() so that it is the central place to make all (or most) hooks happen; or to add a set of architectural hooks (similar to the SCHED_OP() hooks) in the various places you need them. I'm inclined to think that the second is the better option; if for no other reason that it makes it more clear which states are handled." For Wei's --and everyone which was not involved in the discussion-- benfit George's "second option" is one (the best I can think of, actually) way to implement my own suggestion. So, basically, I and George agree, and Jan says to look at out feedback... I don't think I see much disagreement, not to mention 'conflicts'! :-O > However, if different maintainers still hold different opinions, I would = appreciate > it if maintainers can reach consensus among themselves so that we can kee= p > making progress >=20 IMO, go implement the 'architectural hooks' George suggested, and progress is ensured. Back to the 'freeze exception' matter, for what my opinion is worth, I'm rather skeptical for the above, and all the changes to the series that doing it would require, to be ready and fully acked by the time horizon we're looking at... but it's Wei that is on call, of course. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-uiwBd2jKPnyg3IeHBlVy 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 iEYEABECAAYFAlWj27IACgkQk4XaBE3IOsRJQgCffJmp9Fz7VBVdpHuyFKkwBHGM Rq4An0PqECdmvLpz7RSMzUYY0rptSEQg =qoM9 -----END PGP SIGNATURE----- --=-uiwBd2jKPnyg3IeHBlVy-- --===============1570134343933740478== 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 --===============1570134343933740478==--