Avi Kivity wrote:
The
congruent case which comes to mind is lazy FPU handling.
That one has preempt_ops in hardware: cr0.ts and #NM.
However, that doesn't handle in-kernel use of the fpu.
kernel_fpu_begin()/kernel_fpu_end() could easily be modified to take
advantage of a generic preem
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> How do you feel about some variant of this going into 2.6.23-rc1? I
> initially thought of this as a 2.6.24 thing, but as it now looks
> solid, maybe we can hurry things along.
yeah, fine by me. You were working on a more generic patch, right? I
thin
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
Won't that increase task_struct (16 bytes on 64-bit) unnecessarily?
The function pointers are common to all virtual machines.
well, this function pointer could then be reused by other virtual
machines as well, couldnt it?
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-spe
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
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
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...
>
> W
Rusty Russell wrote:
> On Mon, 2007-07-09 at 09:39 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> I think a "struct preempt_ops *" and a "void *preempt_ops_data" inside
>>> every task struct is a better idea. Call the config option
>>> PREEMPT_SCHED_HOOKS and now there's nothing
On Mon, 2007-07-09 at 09:39 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > I think a "struct preempt_ops *" and a "void *preempt_ops_data" inside
> > every task struct is a better idea. Call the config option
> > PREEMPT_SCHED_HOOKS and now there's nothing kvm-specific about it...
> >
>
>
Avi Kivity wrote:
Shaohua Li wrote:
On Sun, 2007-07-08 at 20:58 +0800, Avi Kivity wrote:
The only fly in the ointment is that it crashes quite soon. Haven't
figured
out why yet, but comments on the general direction would be welcome.
Attached patch seems help in my test. prepare_task_s
Shaohua Li wrote:
On Sun, 2007-07-08 at 20:58 +0800, Avi Kivity wrote:
The only fly in the ointment is that it crashes quite soon. Haven't
figured
out why yet, but comments on the general direction would be welcome.
Attached patch seems help in my test. prepare_task_switch is called wi
On Sun, 2007-07-08 at 20:58 +0800, Avi Kivity wrote:
> The only fly in the ointment is that it crashes quite soon. Haven't
> figured
> out why yet, but comments on the general direction would be welcome.
Attached patch seems help in my test. prepare_task_switch is called with
irq disabled.
> -st
[cc list restored]
Andi Kleen wrote:
> Avi Kivity writes:
>
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index 693f0e6..b705876 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -875,6 +875,10 @@ struct task_struct {
>> pid_t pid;
>> pid_t
Rusty Russell wrote:
> On Sun, 2007-07-08 at 15:48 +0200, Ingo Molnar wrote:
>
>> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>>
>>
> +#ifdef CONFIG_SCHED_KVM
> +static __read_mostly struct sched_kvm_hooks kvm_hooks;
> +#endif
>
please just add a current->put_vcp
On Sun, 2007-07-08 at 15:48 +0200, Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
> > >>+#ifdef CONFIG_SCHED_KVM
> > >>+static __read_mostly struct sched_kvm_hooks kvm_hooks;
> > >>+#endif
> > >
> > >please just add a current->put_vcpu() function pointer instead of
> > >this hooks
Avi Kivity writes:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 693f0e6..b705876 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -875,6 +875,10 @@ struct task_struct {
> pid_t pid;
> pid_t tgid;
>
> +#ifdef CONFIG_SCHED_KVM
> + stru
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
Won't that increase task_struct (16 bytes on 64-bit) unnecessarily?
The function pointers are common to all virtual machines.
well, this function pointer could then be reused by other virtual
machines as well, couldnt it?
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >> Won't that increase task_struct (16 bytes on 64-bit) unnecessarily?
> >> The function pointers are common to all virtual machines.
> >
> > well, this function pointer could then be reused by other virtual
> > machines as well, couldnt it?
>
> I don
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
+#ifdef CONFIG_SCHED_KVM
+static __read_mostly struct sched_kvm_hooks kvm_hooks;
+#endif
please just add a current->put_vcpu() function pointer instead of
this hooks thing.
Won't that increase task_struct (16 bytes o
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >>+#ifdef CONFIG_SCHED_KVM
> >>+static __read_mostly struct sched_kvm_hooks kvm_hooks;
> >>+#endif
> >
> >please just add a current->put_vcpu() function pointer instead of
> >this hooks thing.
>
> Won't that increase task_struct (16 bytes on 64-bit) unn
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
+#ifdef CONFIG_SCHED_KVM
+static __read_mostly struct sched_kvm_hooks kvm_hooks;
+#endif
please just add a current->put_vcpu() function pointer instead of this
hooks thing.
Won't that increase task_struct (16 bytes on
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > hm, why not do what i have in -rt? See the patch below. Seems to
> > work fine for me, although i might be missing something.
>
> How can this work with >1 VM? We need to execute vmptrld with the new
> VM's vmcs before touching any VT registers.
ye
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_SCHED_KVM
> +static __read_mostly struct sched_kvm_hooks kvm_hooks;
> +#endif
please just add a current->put_vcpu() function pointer instead of this
hooks thing.
> static inline void prepare_task_switch(struct rq *rq, struct task_struct
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
Intel VT essentially introduces a new set of registers into the
processor; this means we cannot preempt kvm in kernel mode lest a new
VM run with and old VM's registers. In addition, kvm lazy switches
some host registers as well.
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Intel VT essentially introduces a new set of registers into the
> processor; this means we cannot preempt kvm in kernel mode lest a new
> VM run with and old VM's registers. In addition, kvm lazy switches
> some host registers as well. (AMD does not i
Intel VT essentially introduces a new set of registers into the processor;
this means we cannot preempt kvm in kernel mode lest a new VM run with
and old VM's registers. In addition, kvm lazy switches some host registers
as well. (AMD does not introduce new registers, but we still want lazy
msr sw
26 matches
Mail list logo
