Received: by 10.223.164.202 with SMTP id h10csp1539701wrb; Wed, 15 Nov 2017 23:16:52 -0800 (PST) X-Google-Smtp-Source: AGs4zMZ7tINwXAISABjO/XpXmQQ04VSGOnEVFi7DfzbKj7eppnth81iTnLKtuQVJkXuG63y8OwUI X-Received: by 10.99.127.88 with SMTP id p24mr729558pgn.377.1510816612106; Wed, 15 Nov 2017 23:16:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510816612; cv=none; d=google.com; s=arc-20160816; b=ABjs+OCOQsMX19zlZDVTMCTlaVRwBR6CS4xuBGSYfNTqjdO1wJYoL7zQCQZDFY/GkK QC0aNI1DnAB5BEWFgko1tK3og+3721RJ/rdkYeiCfLts+TjG0ywu3I8kRqg/7boex0t3 D+V9INLzusQ5OAtpi0pWTqIALBiJNvm4h2PG0ij4WFDt5sW9nHEp8zBi1b2E+oqEv3jH bxUAQQa22df3mqLq2yEfCG17hmomuFsg1T31ZgHuL0xhFcEo3L/dUbu7CPjBtgkY21oR y7UQBuXZcN3s/pAvjQhBlLsH+igmINq/2HDI7733W/frDKfEpnTj7WQkCwpyHV+T8/XT zFKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=TFBKPYsbXZluZlZZ+J8nGeRsOCnUczCDkUYr60Pg7qQ=; b=B9cszT82HcGj7QT/Oc6vsSHRaQaImS4arMu3ayPl+U+zyl2wXVw8bo7aXbLtkQb4Ow 1/25aS2rfqX50Mp53K7BlCdFRjIDOEMF1zY+oDMTjRdwaA4JlzIRjd1OBI2nFCeFFpEm futZtgZYDDDorXUl89hEiLfNi70hv1QBwYj88MPciVopo+Yd8opZir3nzugmjzhO62cM Dr01fixy8IZ0x3ijEy3X8gF06HFOYsWkoSrtXFXu/JKQwUQMYv63FHKrFfKm/6GruGS0 v43tBPL2bhAJXO66h0OugRMn15AhtAdE91GkndLsZj0aTTjSuxK1DnLqbyrgRYXqT6Xc naaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PEK17AEM; 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=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s7si391016pgq.419.2017.11.15.23.16.39; Wed, 15 Nov 2017 23:16:52 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PEK17AEM; 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=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758693AbdKPFyW (ORCPT + 91 others); Thu, 16 Nov 2017 00:54:22 -0500 Received: from mail-ot0-f194.google.com ([74.125.82.194]:51841 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751067AbdKPFyO (ORCPT ); Thu, 16 Nov 2017 00:54:14 -0500 Received: by mail-ot0-f194.google.com with SMTP id b54so9504644otd.8; Wed, 15 Nov 2017 21:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TFBKPYsbXZluZlZZ+J8nGeRsOCnUczCDkUYr60Pg7qQ=; b=PEK17AEMm6hKGP+0XhbthHtW11h3RBtFrRAQUc5r8l0xDFZTrsA7IqI4tVcWUt26tt bu/q6f2q6uOq/xk949LAc9tKN+OT864LFvDVBrxfd1hIB+8y+oZloUTEY4q5yIs4Qxki DKd8MgLCxGhDspNHpoYOiGhLR8S/Mk55U1RynpYpKXzIHQHXYIAx3F2HBWYUjlMog9A7 wzf+0/VG1u2gjDbKtLusnnN6YeMtWbWM/Zb5a/qg8Y2bfo9D5heobVQQ7dAD02fAVU3O why3xFjKB/Pmfnp2pUxFE4IaoPpmrbNYAnyyVtd62ZUtA0XkQj8jfvtP7N4mUKAQURTe wJyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TFBKPYsbXZluZlZZ+J8nGeRsOCnUczCDkUYr60Pg7qQ=; b=M9GWJsoo1Vg9UQojA3luiudNnvSdKSGBqRWISBkzCM6szej2mBphVnC0XfW4CwLNJC ZCJ1zMFDmR5kEShWd4zfEeNHelT8jQH7eltC5k0pHjjmfJnA79kR60zl+NQt3SfzbIUt SKlY35OmmrYreD+0+iudqMbnvz2ggcRPhii/yEiFrTNKcUeFYmC31/ZBlXQ5C/H4NDiB Bb+SdReBN0aloLTyUObkVwReuZTug1S1ND55mwf7NQF0ULzhMIMbAftrQwgARmt+uO4c Flb49Iu9tX3PDEx5SCBye+KZqUKlVQV7pJ4DZ9sQKhedmLjMAh6ngP9SVhT5kAMafV5Z BQoQ== X-Gm-Message-State: AJaThX4VPoILgURLkaAT4cnMCJ0Oe/9W0yg7htdfkM5K1ItA3BsMbIyT XWaBstHfMEJyw2nXgswNaaSrK2zUFY3+Njp4gC4= X-Received: by 10.157.85.150 with SMTP id m22mr339022oth.218.1510811653609; Wed, 15 Nov 2017 21:54:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.53.27 with HTTP; Wed, 15 Nov 2017 21:54:12 -0800 (PST) In-Reply-To: <1510756846.21121.289.camel@redhat.com> References: <20171114215424.32214-1-riel@redhat.com> <20171114215424.32214-2-riel@redhat.com> <1510715030.21121.287.camel@redhat.com> <1510756846.21121.289.camel@redhat.com> From: Wanpeng Li Date: Thu, 16 Nov 2017 13:54:12 +0800 Message-ID: Subject: Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run To: Rik van Riel Cc: Paolo Bonzini , kvm , "linux-kernel@vger.kernel.org" , David Hildenbrand , Christian Borntraeger , Thomas Gleixner , Radim Krcmar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-11-15 22:40 GMT+08:00 Rik van Riel : > 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? You are right. Regards, Wanpeng Li From 1584201365818332907@xxx Thu Nov 16 06:02:34 +0000 2017 X-GM-THRID: 1584017174910331026 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread