Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp2050055imj; Sun, 10 Feb 2019 17:20:33 -0800 (PST) X-Google-Smtp-Source: AHgI3IYVF0HBmSrTu0/BexmB9Zn7pFXfRB/XYiwlxzvXZcZx5TriiSnf+EdI1xA4zmsXMCzzjghE X-Received: by 2002:a63:1cd:: with SMTP id 196mr7189559pgb.58.1549848033011; Sun, 10 Feb 2019 17:20:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549848033; cv=none; d=google.com; s=arc-20160816; b=tx9g4kipVcJ+s70z1Ri2WjaFG7GVHgeCz8sTyXpqS3NrJmAwGCx+yuH9DAxbfK1og0 0annCeDcXJwLitida2mkumGWpqhT4HdhyhlLz32grCCbs6c2Limd6t6nddSG4dCduP1i L9pG5IGmrPKEePgELsoQ62xoRoWq8uGRtLFrhocJqG/ascMGgYpdRPeRpTHAWpgOGW0y n4+kQ0Mf0oUQkdD6hdh9r8Yi/bB/l4fIiIVopvLWV5rFvVs1rl9YwLSklMZlqdqe+GSt ou2JxMJi5P1zohQCYF+FqvZQ/3WN229EE2IYMW80MaWf7Ckt53e1l4tM4k4DOWbWqHFj UyRA== 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 :user-agent:references:in-reply-to:date:to:from:subject:message-id; bh=pASVNZ4LwmjbneD0RivWXfUHnG85bljFL28ssjQ0bHo=; b=ghJcPpIV/SwH2jhWUpXKLfelMaJZUrpFmJrEBmHiIHzuRn7okoFc06tjkc46BRhANG 28LLVb7cE7E/OU+BIqUAQQRK0xNRzvsAtuUJ7JHamVHfz5qd0CSB9sUhP2I1uNOEgnQ9 53nmleo5GYVy5YMU1gihfQUuqwG3f78FnTxX7mi1sBq/OzpT+nyLwO3ODJescKxKNzuS 0Kf8TQtt3ZQla4TQ+JaK6Fam2RVnFRVzdmTqzRKPesWTYaEYQTGUwqSICvqL2Hpu6cnT H5L90aSZBI+c+ExVVxJaU/ak5sOeeXzGTRfGvD7W0yflLtWy/0r/fyjNJHN+TBcgdads iy3w== 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 e23si7850910pgv.500.2019.02.10.17.20.16; Sun, 10 Feb 2019 17:20:32 -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 S1726565AbfBKBUC (ORCPT + 99 others); Sun, 10 Feb 2019 20:20:02 -0500 Received: from gate.crashing.org ([63.228.1.57]:40797 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726130AbfBKBUC (ORCPT ); Sun, 10 Feb 2019 20:20:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x1B0UtG5017871; Sun, 10 Feb 2019 18:30:56 -0600 Message-ID: Subject: Re: [PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest From: Benjamin Herrenschmidt To: Mark Cave-Ayland , Christophe Leroy , paulus@samba.org, mpe@ellerman.id.au, npiggin@gmail.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org Date: Mon, 11 Feb 2019 11:30:54 +1100 In-Reply-To: <2ed8efb9-5cd4-31bf-6c7b-501b9d1925e6@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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4 (3.30.4-1.fc29) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Cheers, Ben.