Rusty Russell wrote:
On Tue, 2007-07-10 at 08:53 +0300, Avi Kivity wrote:
Rusty Russell wrote:
No; this is a "I'm doing something magic and need to know before someone
else takes the CPU". Almost by definition, you cannot have two of them
at the same time. Let someone else try that if and when...
Why can't you have two of them? Say I'm writing a module to utilize
branch recording to be able to debug a process in reverse (of course
that doesn't really need sched hooks; let's pretend it does). Why can't
I debug a process that uses kvm?
More importantly, now the two subsystems have to know about each other
so they don't step on each other's toes.
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.
But KVM-specific code in the scheduler is just wrong, and I think we all
know that.
Even if I eradicate all mention of kvm from the patch, it's still kvm
specific. kvm at least is sensitive to the exact point where we switch
in (it wants interrupts enabled) and it expects certain parameters to
the callbacks. If $new_abuser needs other conditions or parameters,
which is quite likely IMO as it will most likely have to do with
hardware, then we will need to update the hooks anyway.
If it's not general, then this whole approach is wrong: put it in
arch/*/kernel/process.c:__switch_to and finish_arch_switch.
I imagine other kvm ports will also need this. It's not arch specific,
just kvm specific (but that's not really fair: other archs might want
the switch in another place, or they might not need it after all).
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
congruent case which comes to mind is lazy FPU handling.
That one has preempt_ops in hardware: cr0.ts and #NM.
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.
--
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
