[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46934232.2070509@qumranet.com>
Date: Tue, 10 Jul 2007 11:24:18 +0300
From: Avi Kivity <avi@...ranet.com>
To: Rusty Russell <rusty@...tcorp.com.au>
CC: Ingo Molnar <mingo@...e.hu>, kvm-devel@...ts.sourceforge.net,
linux-kernel@...r.kernel.org
Subject: Re: [kvm-devel] [PATCH][RFC] kvm-scheduler integration
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists