From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40470)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1Yx7xL-0002Jg-RZ
	for qemu-devel@nongnu.org; Tue, 26 May 2015 02:03:16 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1Yx7xK-0006K2-Sx
	for qemu-devel@nongnu.org; Tue, 26 May 2015 02:03:15 -0400
Received: from hall.aurel32.net ([2001:bc8:30d7:101::1]:46936)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1Yx7xK-0006Jw-Nn
	for qemu-devel@nongnu.org; Tue, 26 May 2015 02:03:14 -0400
Date: Tue, 26 May 2015 08:03:13 +0200
From: Aurelien Jarno <aurelien@aurel32.net>
Message-ID: <20150526060313.GC29207@aurel32.net>
References: <1432511251-22515-1-git-send-email-aurelien@aurel32.net>
	<1432511251-22515-9-git-send-email-aurelien@aurel32.net>
	<5563AB72.3070601@twiddle.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5563AB72.3070601@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 08/10] target-s390x: implement STFLE
 instruction
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>

On 2015-05-25 16:08, Richard Henderson wrote:
> On 05/24/2015 04:47 PM, Aurelien Jarno wrote:
> >Cc: Alexander Graf <agraf@suse.de>
> >Cc: Richard Henderson <rth@twiddle.net>
> >Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> 
> Sadly, implementing this breaks current kernels.
> I did this about two years ago and havn't figured
> out what to do about it.
> 
> The silly code in head.S doesn't check for just the
> facilities that it needs, it checks for all facilities
> that specific processors provide.
> 
> If we don't e.g. pretend that we have HFP, despite the
> fact that no one uses it, the kernel won't boot.

How does it breaks? This patch only enable bits corresponding to 
facility that we fully implement (that's a reason why the patchset
doesn't enable LD facility for example). So it should not be a problem,
at least I have been able to boot kernels successfully.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net