Re: [Xen-devel] Requesting for freeze exception for VT-d posted-interrupts

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

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: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel