On 02/28/2012 08:34 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 10:09 AM, Avi Kivity <a...@redhat.com> wrote:
> >
> > This is done by preempt notifiers. Whenever a task switch happens we
> > push the guest fpu state into memory (if loaded) and let the normal
> > stuff happen. So the if we had a task switch during instruction
> > emulation, for example, then we'd get the "glacial and stupid path" to fire.
>
> Oh christ.
>
> This is exactly what the scheduler has ALWAYS ALREADY DONE FOR YOU.
No, the scheduler saves the state into task_struct. I need it saved
into the vcpu structure. We have two fpu states, the user state, and
the guest state. APIs that take a task_struct as a parameter, or
reference current implicitly, aren't going to work.
> That's what the i387 save-and-restore code is all about. What's the
> advantage of just re-implementing it in non-obvious ways?
>
> Stop doing it. You get *zero* advantages from just doing what the
> scheduler natively does for you, and the scheduler does it *better*.
The scheduler does something different.
What I'd ideally want is
struct fpu {
int cpu; /* -1 = not loaded */
union thread_xstate *state;
};
Perhaps with a struct fpu_ops *ops if needed. We could then let various
users' fpus float around freely and only save/load them at the last moment.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
