Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Thu, 2015-07-09 at 03:09 +0000, Wu, Feng wrote:

> > -----Original Message-----
> > From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]

> > 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
> 
> Not just blocks, unblocks, we need to track the state transition, and
> update posted-interrupt descriptor accordingly.
> 
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).
> > 
> > I think you should not build on top of such abstraction, but on top of
> > pause_flags directly.
> 
> 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?
> 
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
-- 
<<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