Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1567610

Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active
Date 2017-01-26 18:10 +0100
Message-ID <t3VIE-1CL-63@gated-at.bofh.it> (permalink)
References (1 earlier) <t3QpA-6Hl-19@gated-at.bofh.it> <t3Tx8-9b-13@gated-at.bofh.it> <t3U0a-xW-19@gated-at.bofh.it> <t3V5U-1ao-9@gated-at.bofh.it> <t3V5V-1ao-29@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Jan 26, 2017 at 7:53 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Rik van Riel <riel@redhat.com> wrote:
>
>> Let me go totally reimplement this whole project in a different way...
>
> Note that I can still be convinced about complicating the FPU state machine as
> well if that ends up being the best approach for KVM - but it appears to me (from
> a very superficial look) that turning vCPU threads into no-FPU kthreads or
> representing the guest FPU state directly with the host FPU context would be even
> more beneficial, from the simplicity and KVM performance POV?

I may be misunderstanding you, but I don't see how this would work
without getting either messy or slow.

But I think that your series may still be a good base for Rik's work.
With your series applied, there are three possible FPU states: regs
active (regs are in the CPU), regs inactive (in memory), and regs
cached (in memory *and* regs).  What Rik's series does doesn't really
complicate the state machine -- there are still just these three
states.  The difference is that it's possible for the regs to be
inactive or cached even for the current task so long as we're not in
user mode.  The point being that the user vCPU thread can enter the
kernel, get its FPU state inactivated, enter the guest, and reenter
the kernel without reactivating its regs.

Rik, if you think about it that way, does your work map cleanly onto
Ingo's patches?

Ingo, as far as I know, the only serious conceptual complication is
that this change has the potential to interact poorly with PKRU, but
that should be manageable.

--Andy

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active Ingo Molnar <mingo@kernel.org> - 2017-01-26 12:30 +0100
  Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to  fpu->fpstate_active Rik van Riel <riel@redhat.com> - 2017-01-26 15:50 +0100
    Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to  fpu->fpstate_active Ingo Molnar <mingo@kernel.org> - 2017-01-26 16:20 +0100
      Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to  fpu->fpstate_active Rik van Riel <riel@redhat.com> - 2017-01-26 17:30 +0100
        Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to  fpu->fpstate_active Ingo Molnar <mingo@kernel.org> - 2017-01-26 17:30 +0100
          Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active Andy Lutomirski <luto@amacapital.net> - 2017-01-26 18:10 +0100
            Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to  fpu->fpstate_active Rik van Riel <riel@redhat.com> - 2017-01-26 19:10 +0100

csiph-web