Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6585679ybi; Sun, 21 Jul 2019 21:31:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxgEC698Bc9+VjHayMwLxMbkkg3B8uV7uaBB1mxn5+OqJiex47mboaoG9Hx5DcM6oaYs9XG X-Received: by 2002:a63:e44b:: with SMTP id i11mr22303705pgk.297.1563769870978; Sun, 21 Jul 2019 21:31:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563769870; cv=none; d=google.com; s=arc-20160816; b=QICHpD+j8qBtgdAlpJ+swGZtKX0VQj84I+TyCgPPlK4BNVtPWxy0gOwEtneyqZ+8Ml qq7WFFXzY9JcP9PIYleuu/udXjQt2KORBH+qWC4ESwY9298HD6oSYRpgY2Q7ThFR+3Qx lrDn3q+oSC3c7iFt+7W8L4du9oTAD4Fbj+Sr30CB5tprX2hDgEyDCV+kDaCiP8MEkPsl +m5xP9aF7vT8nVyBwabrk2QWTDwWwKyTYfnwEqYK8ajXZqV9Lju31CGttrwDQeTqRFmC uIjkZnAVlME1BXZ6rHEsJoders8+5TUo2Xd5HL3GL1ljH0KAajgxuBMmXJeijSXcZtED Tsyg== 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 :in-reply-to:references:mime-version:dkim-signature; bh=u9bIll45IkEv61GnSgi6Wk39bsONFi+netx8AhCfi7w=; b=WwBANhxHo57HB5ae3rlRLFRQ1Hul1lAu7RRun3yYSCLXaRyrn+kidcQX+vN/8NLdJ/ hVWGd+fjYG/aSCSiUi+d4E2OBepDAmkvkEQhI04Jm/hGDAA5WtpjevkM9IfsDJLPr7j3 i7DAVPK1VrO8SiI8I1IlxlQp3LEW2QQWfVEF3vSzJjo/PSTtWIemgFBAFhMb39DH6BQe cRxg0B0M58B6CyZzKgy5xhkbWdHGdeCnRVkI52NDrpkD2AvvJRxQZXbKR7yh10dUOlC1 BFA91OGy7/10JWzoq3hOY58GL2I7nOeXV8FgZnJR4apo9NZVg0l4DYtt/9WhgV06l7Y0 Tqmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="NHUxNR/F"; 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=QUARANTINE 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 x1si8097952pgt.258.2019.07.21.21.30.55; Sun, 21 Jul 2019 21:31:10 -0700 (PDT) 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="NHUxNR/F"; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727629AbfGVE2v (ORCPT + 99 others); Mon, 22 Jul 2019 00:28:51 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:39685 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726024AbfGVE2v (ORCPT ); Mon, 22 Jul 2019 00:28:51 -0400 Received: by mail-ot1-f66.google.com with SMTP id r21so32777000otq.6; Sun, 21 Jul 2019 21:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u9bIll45IkEv61GnSgi6Wk39bsONFi+netx8AhCfi7w=; b=NHUxNR/FbcDIls4wN/7K5xWw6t8TG9WA5uwgNKY3twE8BQCdSpTorc48b0xlAnS14F qUf7KXocl2+7NbhgxJd/93i5J81zHxQH/vSasc6+aKGXME0g61VTCydf1sfZTyGkQi41 du3UKdzrgvosoE3hO50QGf/6dVGjB9BfHLL7OMjoR7tnnZRRhZux2fYTAmF49Sz0VtSv Ykp6WapqR6L55lEqWd7lzmc9YCMJvZrVEQbiF+Q02NuT2HeOcmfY1NGXjIr0DGNHUkMN a3Im6biTl3Z/+kKKoSj64+QOG4Ah4XLhBUdUA36xDzxETxN4PPw3bzzQNbYRs7VCB4vh 2urA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u9bIll45IkEv61GnSgi6Wk39bsONFi+netx8AhCfi7w=; b=Ykx0QjP1k4xxvpVsgucWns1cTR52mRGPcFAWT/8T1V15DmtA6ojMFRhlzGq6k4eB6n Gkv0b1l3be/okOErOeUVosgju0Di+yPeh2QDymkzXgMzcTk0djCleLMOe8cihUc64z3p /k/LEmD6PVynFjDHjOkEJgI7nvwYCvf614+zD4o8/PBvy4LO0z5Pzxq3o4bogOACSW2I NQbzLj0BXThL5WTGr8p3tgSkn7ow9pNJpS4U/t7l5boWD+5ZVwawc3lnSieyizhIvxqp lu1kIZZWvxtzs+Avi0Tvn7vAoQPoyBGfH0X2keFmc2QiuQMOgMO5mZG12mHQFj4qfi5v /Eww== X-Gm-Message-State: APjAAAWccNWQWDWlTy4jQHDw44YrQciNUBj1zdiNKfokyHniuotFzBxx G9mqbgWSB/PhUx8cGZgXrj29Hgpripg4M8/Aa24= X-Received: by 2002:a9d:2c47:: with SMTP id f65mr50830747otb.185.1563769730249; Sun, 21 Jul 2019 21:28:50 -0700 (PDT) MIME-Version: 1.0 References: <217248af-e980-9cb0-ff0d-9773413b9d38@thomaslambertz.de> <3ae96202-a121-70a9-fe00-4b5bb4970242@redhat.com> In-Reply-To: <3ae96202-a121-70a9-fe00-4b5bb4970242@redhat.com> From: Wanpeng Li Date: Mon, 22 Jul 2019 12:28:42 +0800 Message-ID: Subject: Re: [5.2 regression] x86/fpu changes cause crashes in KVM guest To: Paolo Bonzini Cc: Thomas Lambertz , Sebastian Andrzej Siewior , Rik van Riel , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , LKML , Radim Krcmar , kvm , Peter Zijlstra , Marc Orr 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 On Fri, 19 Jul 2019 at 19:09, Paolo Bonzini wrote: > > On 19/07/19 10:59, Wanpeng Li wrote: > > https://lkml.org/lkml/2017/11/14/891, "The scheduler will save the > > guest fpu context when a vCPU thread is preempted, and restore it when > > it is scheduled back in." But I can't find any scheduler codes do > > this. > > That's because applying commit 240c35a37 was completely wrong. The idea > before commit 240c35a37 was that you have the following FPU states: > > userspace (QEMU) guest > --------------------------------------------------------------------------- > processor vcpu->arch.guest_fpu > >>> KVM_RUN: kvm_load_guest_fpu > vcpu->arch.user_fpu processor > >>> preempt out > vcpu->arch.user_fpu current->thread.fpu > >>> preempt in > vcpu->arch.user_fpu processor > >>> back to userspace > >>> kvm_put_guest_fpu > processor vcpu->arch.guest_fpu > --------------------------------------------------------------------------- > > After removing user_fpu, QEMU's FPU state is destroyed when KVM_RUN is > preempted. So that's already messed up (I'll send a revert), and given > the diagram above your patch makes total sense. > > With the new lazy model we want to hook into kvm_vcpu_arch_load and get > the state back to the processor from current->thread.fpu, and indeed > switch_fpu_return is essentially copy_kernel_to_fpregs(¤t->thread. > fpu->state). > > However I would keep the fpregs_assert_state_consistent in > kvm_arch_vcpu_load, and also > WARN_ON_ONCE(test_thread_flag(TIF_NEED_FPU_LOAD)) in vcpu_enter_guest. Looks good to me, just send out two patches rebase on the revert. Regards, Wanpeng Li