Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3137503imj; Mon, 18 Feb 2019 20:55:50 -0800 (PST) X-Google-Smtp-Source: AHgI3IYSZAo2KdBmkpLS8E01wXYpaeedHmx4wLGfmpFrX1HZx7GG2qjCA7v/uK2SST6en4oKKVRw X-Received: by 2002:a62:994e:: with SMTP id d75mr27457103pfe.236.1550552150285; Mon, 18 Feb 2019 20:55:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550552150; cv=none; d=google.com; s=arc-20160816; b=hPF1rG/uMBUf3GaOf9l8VQHLLEtULRGlo7g64OG7qVAs/Zo+JmhR/EccMG9gtpmeWb rL/JMo1KpS1MJFPhJKL+Wh0fV4c2CAVoG2hU99P4xkkpQGALbX7kqDRTZMZvzStNZawo 2KMSQIp1TcJwHyCBTdjNHTVJw7ZL9Q/aXX4yBZE0Pp/1dgjdlWWDcNgfUlc7D+mwFAsd YwxxtwcWyu5ndUfx4f8yp96hqj8oFcwwRQRXPqbhFz05rpNLSWxLHRTmVvAiYYeDXkyh zTPgV0d+6dPLXj/Tzqb4APHAPuugV23DGOs7w8K4qldYV4kPpkXUXgGkNIIoI5Cxm21s 7goA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:to:from; bh=Seb9Jo+ImD0Lwls3Xb4Ej4YuU+CkhcdEZqngyIE4KJw=; b=QHYIY0cjXdJALw18xVyYzzDLzmngTendrcxJwkcId6SI/e+Kg5Q9+GlHGZ+EB0EIBw FyuXrgKYlFMmGl+RhkSTH31EOD5/p1hXZaJ18u97c/JgPrqC9OtEZR9SyNjfcjsgvoTQ H9i+t53UaqLQQXdcN6zg/jp/HtANfVrMOPtzuAYza8Xkp94/+BsdUY1Eix5ci674ifXM qyWC0A2YUXEfSRE3hq/A9NaXQKqQgxDjsWL5Z1JuWju9TCfnvrZwmodLobKN4QUYHho+ Pvd2hZ0ll/Wsevde+IZgWDDYU0psahAkiBzDeU9rIF/On8vystEfS11l0Q+E4jNHpWJM G3Ig== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f131si5213907pfc.92.2019.02.18.20.55.34; Mon, 18 Feb 2019 20:55:50 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725885AbfBSEzO (ORCPT + 99 others); Mon, 18 Feb 2019 23:55:14 -0500 Received: from ozlabs.org ([203.11.71.1]:48253 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725730AbfBSEzO (ORCPT ); Mon, 18 Feb 2019 23:55:14 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 443T1q1kZ0z9s1l; Tue, 19 Feb 2019 15:55:11 +1100 (AEDT) From: Michael Ellerman To: Mark Cave-Ayland , Benjamin Herrenschmidt , Christophe Leroy , paulus@samba.org, npiggin@gmail.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org Subject: Re: [PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest In-Reply-To: <46205b6a-7671-5d90-9507-b5b20045b99d@ilande.co.uk> References: <20190208143319.11980-1-mark.cave-ayland@ilande.co.uk> <41b02fb0-cdc6-6de0-d8fc-44d3d0a8ad70@c-s.fr> <2ed8efb9-5cd4-31bf-6c7b-501b9d1925e6@ilande.co.uk> <46205b6a-7671-5d90-9507-b5b20045b99d@ilande.co.uk> Date: Tue, 19 Feb 2019 15:55:10 +1100 Message-ID: <87mumsbcnl.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mark Cave-Ayland writes: > On 11/02/2019 00:30, Benjamin Herrenschmidt wrote: > >> On Fri, 2019-02-08 at 14:51 +0000, Mark Cave-Ayland wrote: >>> >>> Indeed, but there are still some questions to be asked here: >>> >>> 1) Why were these bits removed from the original bitmask in the first place without >>> it being documented in the commit message? >>> >>> 2) Is this the right fix? I'm told that MacOS guests already run without this patch >>> on a G5 under 64-bit KVM-PR which may suggest that this is a workaround for another >>> bug elsewhere in the 32-bit powerpc code. >>> >>> >>> If you think that these points don't matter, then I'm happy to resubmit the patch >>> as-is based upon your comments above. >> >> We should write a test case to verify that FE0/FE1 are properly >> preserved/context-switched etc... I bet if we accidentally wiped them, >> we wouldn't notice 99.9% of the time. > > Right I guess it's more likely to cause in issue in the KVM PR case because the guest > can alter the flags in a way that doesn't go through the normal process switch mechanism. > > The original patchset at > https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg98326.html does include > some tests in the first few patches, but AFAICT they are concerned with the contents > of the FP registers rather than the related MSRs. fpu_preempt.c should be able to be adapted to also check the MSR bits. > Who is the right person to ask about fixing issues related to context switching with > KVM PR? KVM PR doesn't really have a maintainer TBH. Feel like volunteering? :) > I did add the original author's email address to my first few emails but have > had no response back :/ Cyril who wrote the original FPU patch has moved on to other things. cheers