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

[Avi Kivity <avi@qumranet.com>]

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