From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752817AbeAQMFw (ORCPT + 1 other); Wed, 17 Jan 2018 07:05:52 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58364 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752412AbeAQMFu (ORCPT ); Wed, 17 Jan 2018 07:05:50 -0500 Subject: Re: [PATCH 0/6] s390: improve speculative execution handling To: Cornelia Huck , Martin Schwidefsky Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, Heiko Carstens , Paolo Bonzini , Greg Kroah-Hartman , Jon Masters , Marcus Meissner , Jiri Kosina References: <1516182519-10623-1-git-send-email-schwidefsky@de.ibm.com> <20180117130038.4830f89b.cohuck@redhat.com> From: Christian Borntraeger Date: Wed, 17 Jan 2018 13:05:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20180117130038.4830f89b.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18011712-0008-0000-0000-000004C2C60F X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011712-0009-0000-0000-00001E5634D0 Message-Id: <9a542409-59ef-57f0-3d90-04e88354d1c3@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-17_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801170175 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 01/17/2018 01:00 PM, Cornelia Huck wrote: > On Wed, 17 Jan 2018 10:48:33 +0100 > Martin Schwidefsky wrote: > >> This patch series implements multiple mitigations for the speculative >> execution findings: >> 1. The definition of the gmb() barrier as currently used by the >> distributions, we may have to find a better name for it >> 2. The architecture code for the nospec interfaces, the macros for >> nospec_ptr and nospec_load just use the gmb() barrier >> 3. The enablement for firmware features to switch between different >> branch prediction modes. It comes with a config option >> CONFIG_KERNEL_NOBP, two new kernel parameters "nobp=[0|1]" and >> "nospec", and a new system call s390_modify_bp. >> With CONFIG_KERNEL_NOBP=y the new branch prediction mode is active >> for the kernel code by default and can be switched off with "nospec" >> or "nobp=0". With CONFIG_KERNEL_NOBP=n the new mode is inactive for >> kernel code unless "nobp=1" is specified. >> User space code can use the trapdoor system call s390_modify_bp to >> set the new TIF_NOBP bit. This switches to the new branch prediction >> mode for the lifetime of the task, any children of the task will >> inherit this attribute. >> The vCPU of a KVM guest will run with the new branch prediction >> mode if either the associated qemu task has TIF_NOBP set or if the >> KVM kernel code sets TIF_NOBP_GUEST. The later will require a small >> update to KVM backend. > > How does this interact with the facility bits? Bit 81 seems to indicate > function code f (gmb), while bit 82 seems to indicate function codes > c/d (branch prediction modes). Both seem to be in the range of bits > transparently passed through for kvm (although this still needs a qemu > update to the cpu models so the bits are not masked out as unknown.) Correct. I will send a qemu patch soon.