linux-kernel - Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Nov 2017 16:20:37 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Rik van Riel <riel@...hat.com>, Paolo Bonzini <pbonzini@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, rkrcmar@...hat.com, borntraeger@...ibm.com
Subject: Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On 15.11.2017 15:50, Rik van Riel wrote:
> On Wed, 2017-11-15 at 09:34 +0100, Paolo Bonzini wrote:
>> On 14/11/2017 20:40, David Hildenbrand wrote:
>>> I think we should check all get/put_fpu callers if they need
>>> preempt_disable().
>>>
>>> E.g. em_fxrstor() needs disabled preemption as we temporarily
>>> save + restore some host register (via fxsave + fxrstor) under some
>>> circumstances that are not saved/restored when switching to/back
>>> from
>>> another process. We should double check.
>>
>> Rik may correct me, but I believe that you don't need
>> preempt_disable/enable because preempt notifiers do this for you.
> 
> We no longer even need the preempt notifiers to save and
> restore the guest FPU state.
> 
> The context switch code itself will save the FPU state
> from the registers, into current->thread.fpu.state, when
> the VCPU thread gets scheduled out.
> 
> When the VCPU thread gets scheduled in, the scheduler
> will restore the guest FPU state from current->thread.fpu.state.
> 
> At this point, vcpu->arch.guest_fpu may be OUT OF DATE.
> 
> However, this is just fine, because we will save the guest
> FPU state into vcpu->arch.guest_fpu in kvm_put_guest_fpu,
> before we leave the KVM_RUN ioctl, and before we release
> the vcpu->mutex.
> 
> In other words, by the time anybody else can examine the
> VCPU FPU state (after they obtain the vcpu->mutex), the
> vcpu->arch.guest_fpu area will contain the correct FPU
> state.
> 

Okay, that answers my question, thanks!

-- 

Thanks,

David / dhildenb