From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF6EDC54FCB for ; Thu, 23 Apr 2020 13:57:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C2EE820728 for ; Thu, 23 Apr 2020 13:57:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728606AbgDWN5p (ORCPT ); Thu, 23 Apr 2020 09:57:45 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41198 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728431AbgDWN5p (ORCPT ); Thu, 23 Apr 2020 09:57:45 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03NDaC5J084306 for ; Thu, 23 Apr 2020 09:57:44 -0400 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 30jrj6tju6-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 23 Apr 2020 09:57:43 -0400 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Apr 2020 14:57:17 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp03.uk.ibm.com (192.168.101.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 23 Apr 2020 14:57:13 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 03NDuMQM7930322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Apr 2020 13:56:22 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4FE9952050; Thu, 23 Apr 2020 13:56:22 +0000 (GMT) Received: from oc2783563651 (unknown [9.145.58.187]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id EA8FF5204F; Thu, 23 Apr 2020 13:56:21 +0000 (GMT) Date: Thu, 23 Apr 2020 15:56:20 +0200 From: Halil Pasic To: Jared Rossi Cc: Eric Farman , Cornelia Huck , linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] vfio-ccw: Enable transparent CCW IPL from DASD In-Reply-To: <20200417182939.11460-2-jrossi@linux.ibm.com> References: <20200417182939.11460-1-jrossi@linux.ibm.com> <20200417182939.11460-2-jrossi@linux.ibm.com> Organization: IBM X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 20042313-0012-0000-0000-000003A9E399 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 20042313-0013-0000-0000-000021E73824 Message-Id: <20200423155620.493cb7cb.pasic@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676 definitions=2020-04-23_10:2020-04-23,2020-04-23 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 spamscore=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 mlxlogscore=847 phishscore=0 suspectscore=0 clxscore=1011 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004230103 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 17 Apr 2020 14:29:39 -0400 Jared Rossi wrote: > Remove the explicit prefetch check when using vfio-ccw devices. > This check is not needed as all Linux channel programs are intended > to use prefetch and will be executed in the same way regardless. Hm. This is a guest thing or? So you basically say, it is OK to do this, because you know that the guest is gonna be Linux and that it the channel program is intended to use prefetch -- but the ORB supplied by the guest that designates the channel program happens to state the opposite. Or am I missing something? Regards, Halil