Re: [kvm-devel] [PATCH][RFC] kvm-scheduler integration

[Avi Kivity]

Rusty Russell wrote:
> On Tue, 2007-07-10 at 10:19 +0300, Avi Kivity wrote:
>   
> > Rusty Russell wrote:
> >     
> > > Exactly, if we have two at the same time, they need to know about each
> > > other.  Providing infrastructure which lets them avoid thinking about it
> > > is the wrong direction.
> > >   
> > >       
> > With a kvm-specific hook, they can't stop on each other (there can only 
> > be one).
> > With a list, they don't stomp on each other.
> > With a struct preempt_ops but no list, as you propose, they can and will 
> > stomp on each other.
> >     
>
> I'm not talking about the actual overwriting of someone else's hook.
> I'm talking about semantic conflicts involving the actual CPU state.
>
> If I'm lazily restoring some CPU state because I know I don't use it,
> and you're lazily restoring some CPU state because you don't use it, we
> need to make sure that state doesn't intersect: ie. we need to be aware
> of each other.  Only providing a single hook per task forces the second
> user to think about it (maybe that lazy state saving needs to be
> extracted into common code).
>   

Well, if there's another user of VT instructions, then we certainly need 
to have something central to coordinate it.  No API can prevent this, at 
some point we'll forced to use common sense.

> > I guess I can put it in arch specific code, but that means both i386 and 
> > x86_64.
> >
> > Once we have another user we can try to generalize it.
> >     
>
> The problem is that the arch hooks are in the wrong place: 
>
>   

Yes.

> > > Which brings us to the question: why do you want interrupts enabled?
> > >       
> > The sched in hook (vcpu_load) sometimes needs to issue an IPI in order 
> > to flush the VT registers from another cpu into memory.
> >     
>
> OK, I'll have to go away and read the code for this.
>
> BTW, I have no problem with #ifdef KVM-style code in arch-specifics.
> It's kernel/sched.c which is jarring...
>   

We don't want you jarred, do we? I'll prepare a non-kvm-specific patch 
for review later on.  But I can't bring myself to do a single generic 
hook (it's impossible to use correctly); it will be an hlist-based thing.

--
error compiling committee.c: too many arguments to function

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/