From: Dario Faggioli <dario.faggioli@citrix.com>
To: "Wu, Feng" <feng.wu@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"Wang, Yong Y" <yong.y.wang@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"Jan Beulich (JBeulich@suse.com)" <JBeulich@suse.com>,
"Zhang, Yang Z" <yang.z.zhang@intel.com>
Subject: Re: Requesting for freeze exception for VT-d posted-interrupts
Date: Mon, 13 Jul 2015 17:38:24 +0200 [thread overview]
Message-ID: <1436801904.13522.54.camel@citrix.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F002608531@SHSMSX104.ccr.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 3203 bytes --]
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 has
> some problems with my proposals. It would be great if Jan can give a clear
> proposal so that we can discuss and keep making progress.
> 2. Scheduler issue: there are conflicts among maintainers Jan/George/Dario.
> I would agree with Jan's suggestion below:
>
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."
>
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 keep
> making progress
>
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
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2015-07-13 15:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 6:55 Requesting for freeze exception for VT-d posted-interrupts Wu, Feng
2015-07-13 9:05 ` Jan Beulich
2015-07-13 11:00 ` Wei Liu
2015-07-14 5:51 ` Wu, Feng
2015-07-14 9:21 ` Wei Liu
2015-07-14 10:09 ` Jan Beulich
2015-07-14 14:17 ` Wei Liu
2015-07-14 14:46 ` Jan Beulich
2015-07-14 15:02 ` Wei Liu
2015-07-14 16:01 ` Jan Beulich
2015-07-15 15:46 ` Wei Liu
2015-07-15 22:48 ` Wu, Feng
2015-07-17 9:28 ` Wei Liu
2015-07-13 15:38 ` Dario Faggioli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1436801904.13522.54.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=feng.wu@intel.com \
--cc=george.dunlap@eu.citrix.com \
--cc=kevin.tian@intel.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
--cc=yong.y.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.