Received: by 10.223.164.202 with SMTP id h10csp707419wrb; Wed, 15 Nov 2017 06:42:26 -0800 (PST) X-Google-Smtp-Source: AGs4zMaFxxqxBgjL+4jEo81g5FYJg5Yo/s8CRvf7Sr+KEeHOczSrgKfHhhsJoa/aVQcCLSt0byhB X-Received: by 10.159.250.142 with SMTP id k14mr16344691pls.282.1510756946310; Wed, 15 Nov 2017 06:42:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510756946; cv=none; d=google.com; s=arc-20160816; b=pYmrYBytgkITCRus5gZeB5KkaYesZod+7Rw9Khhni5dX43caxhDIAtt5ASDfi3SWR4 NrWjXN9pzhFeukh5GT53vjNY+xilIVUbYQkklwZC87YddKGftnEKXTHEySRYgr7XXYeo MMmLwa/sJuDFSbUOJjCweVZ9qxF5EfOjCs/DgT8pZckqNfiXDwOZBOmpEsFmt37jMTrw DbBrJ8RVYPPUJbE27yDZg1mmE4GU5p/pkDvVAJGOtY9MsfV3JRWXpyXSM8qMa1qJYVVs CsEwhuRjPXiGNIQXc/wmBr5xzhkffPF3EqzYGfUqapHFUij7rVTRvbU4gPnmKaNCc5pl Tcfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=EFyZ0/p+RhYjbo6adF92IteiMM+gIuJ5GoMMMDxm7To=; b=XtfXAKHD2J0wvNUXBljLNFmKrcO110sbyjKD/2mQgqhizS5IUdDEr1YK7TsoMrQ/sr IAsGyre52zy6SC64Wsu/D8xqYQaT1WCDKYBLy7AYJz/UV2lPiH6REPqEiP1mRzvHvDsQ XBLIIyvbIM9Pu3fCQrcBm684IGo3qub4N3KHijDavWcJEMBK4uTwFQBy3CmAfDgy646B GXkiIXeZOtCkQnEW9RIAIsBsNAJl4DxV6nDFOO0T96TwCbkOpUpccJxFnoZ9i7R2/nt4 3VY639CLg+bwXAiMVHGLIKYKOxAjj6XxecYxZIOsm+X3jNYiEGp0LU9qWrONbHWUYN+O Rqsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r3si1078337plb.494.2017.11.15.06.42.14; Wed, 15 Nov 2017 06:42:26 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757591AbdKOOk6 (ORCPT + 89 others); Wed, 15 Nov 2017 09:40:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59798 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754013AbdKOOku (ORCPT ); Wed, 15 Nov 2017 09:40:50 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0B6336CB2B; Wed, 15 Nov 2017 14:40:50 +0000 (UTC) Received: from annuminas.surriel.com (ovpn-126-55.rdu2.redhat.com [10.10.126.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id DFCC47D145; Wed, 15 Nov 2017 14:40:46 +0000 (UTC) Message-ID: <1510756846.21121.289.camel@redhat.com> Subject: Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run From: Rik van Riel To: Wanpeng Li Cc: Paolo Bonzini , kvm , "linux-kernel@vger.kernel.org" , David Hildenbrand , Christian Borntraeger , Thomas Gleixner , Radim Krcmar Date: Wed, 15 Nov 2017 09:40:46 -0500 In-Reply-To: References: <20171114215424.32214-1-riel@redhat.com> <20171114215424.32214-2-riel@redhat.com> <1510715030.21121.287.camel@redhat.com> Organization: Red Hat, Inc Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 15 Nov 2017 14:40:50 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2017-11-15 at 12:33 +0800, Wanpeng Li wrote: > 2017-11-15 11:03 GMT+08:00 Rik van Riel : > > On Wed, 2017-11-15 at 08:47 +0800, Wanpeng Li wrote: > > > 2017-11-15 5:54 GMT+08:00  : > > > > From: Rik van Riel > > > > > > > > Currently, every time a VCPU is scheduled out, the host kernel > > > > will > > > > first save the guest FPU/xstate context, then load the qemu > > > > userspace > > > > FPU context, only to then immediately save the qemu userspace > > > > FPU > > > > context back to memory. When scheduling in a VCPU, the same > > > > extraneous > > > > FPU loads and saves are done. > > > > > > > > This could be avoided by moving from a model where the guest > > > > FPU is > > > > loaded and stored with preemption disabled, to a model where > > > > the > > > > qemu userspace FPU is swapped out for the guest FPU context for > > > > the duration of the KVM_RUN ioctl. > > > > > > What will happen if CONFIG_PREEMPT is enabled? > > > > The scheduler will save the guest FPU context when a > > VCPU thread is preempted, and restore it when it is > > scheduled back in. > > I mean all the involved processes will use fpu. Before patch if > kernel > preempt occur: > > context_switch >   -> prepare_task_switch >         -> fire_sched_out_preempt_notifiers >               -> kvm_sched_out >                     -> kvm_arch_vcpu_put >                           -> kvm_put_guest_fpu >                                -> copy_fpregs_to_fpstate(&vcpu- > >arch.guest_fpu) >                                     save xsave area to guest fpu > buffer >                                -> __kernel_fpu_end >                                      -> > copy_kernel_to_fpregs(¤t->thread.fpu.state) >                                          restore prev vCPU qemu > userspace FPU to the xsave area >   -> switch_to >         -> __switch_to >             -> switch_fpu_prepare >                   -> copy_fpregs_to_fpstate => save xsave area to > prev > vCPU qemu userspace FPU >             -> switch_fpu_finish >                   -> copy_kernel_to_fpgregs => restore next task FPU > to xsave area > > > After the patch: > > context_switch >   -> prepare_task_switch >         -> fire_sched_out_preempt_notifiers >               -> kvm_sched_out > >  -> switch_to >         -> __switch_to >             -> switch_fpu_prepare >                   -> copy_fpregs_to_fpstate         => Oops >                   save xsave area to prev vCPU qemu userspace FPU, > actually the guest FPU buffer is loaded in xsave area, you transmit > guest FPU in xsave area into the prev vCPU qemu userspace FPU When entering kvm_arch_vcpu_ioctl_run we save the qemu userspace FPU context in &vcpu->arch.user_fpu, and we restore that before leaving kvm_arch_vcpu_ioctl_run. Userspace should always see the userspace FPU context, no? Am I overlooking anything? From 1584123503441072566@xxx Wed Nov 15 09:24:59 +0000 2017 X-GM-THRID: 1584017174910331026 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread