From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLnUf-0001wc-6W for qemu-devel@nongnu.org; Thu, 24 May 2018 06:29:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLnUc-0003Dt-1g for qemu-devel@nongnu.org; Thu, 24 May 2018 06:29:13 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57958) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fLnUb-0003DB-OU for qemu-devel@nongnu.org; Thu, 24 May 2018 06:29:09 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4OASu6r038930 for ; Thu, 24 May 2018 06:29:07 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j5rnc0h4c-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 24 May 2018 06:29:07 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 24 May 2018 11:29:05 +0100 References: <20180522221655.78979-1-pasic@linux.ibm.com> <20180522221655.78979-2-pasic@linux.ibm.com> <20180523113708.50b21a77.cohuck@redhat.com> <20180523164640.225908a9.cohuck@redhat.com> <5de50b20-a331-78ea-a7f4-6fdd995ed083@linux.ibm.com> <20180523185957.41af37b2.cohuck@redhat.com> <20180524091608.1c4e8b00.cohuck@redhat.com> From: Halil Pasic Date: Thu, 24 May 2018 12:29:01 +0200 MIME-Version: 1.0 In-Reply-To: <20180524091608.1c4e8b00.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Message-Id: <8bb3b068-15d3-cb3e-724d-ca7589750175@linux.ibm.com> Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Dong Jia Shi , "Jason J. Herne" , qemu-s390x@nongnu.org, qemu-devel@nongnu.org On 05/24/2018 09:16 AM, Cornelia Huck wrote: > On Wed, 23 May 2018 19:28:31 +0200 > Halil Pasic wrote: > >> On 05/23/2018 06:59 PM, Cornelia Huck wrote: >>> On Wed, 23 May 2018 18:23:44 +0200 >>> Halil Pasic wrote: >>> >>>> On 05/23/2018 04:46 PM, Cornelia Huck wrote: >>>>>>>> + if (!(sch->orb.ctrl0 & ORB_CTRL0_MASK_PFCH)) { >>>>>>>> + if (!(vcdev->force_orb_pfch)) { >>>>>>>> + warn_report("vfio-ccw requires PFCH flag set"); >>>>>>>> + sch_gen_unit_exception(sch); >>>>>>>> + css_inject_io_interrupt(sch); >>>>>>>> + return IOINST_CC_EXPECTED; >>>>>>>> + } else { >>>>>>>> + sch->orb.ctrl0 |= ORB_CTRL0_MASK_PFCH; >>>>>>>> + WARN_ONCE(vcdev->warned_force_orb_pfch, "PFCH flag forced"); >>>>>>> This message should probably mention vfio-ccw as well as the subchannel >>>>>>> id? >>>>>>> >>>>>> I was thinking about this. I think all it would make sense to have a common >>>>>> prefix for all reports coming form vfio-ccw (QEMU). But then I was like, that >>>>>> is a separate patch. >>>>>> >>>>>> Maybe something like: >>>>>> vfio-ccw (xx.xx.xxxx): specific message >>>>>> >>>>>> OTOH we don't seem to do that elsewhere (git grep -e 'warn\|error_report\|error_setg' -- hw/s390x/). >>>>>> AFAIR the error_setg captures context (like, src, line, func) but does not >>>>>> necessarily report it. Another question is if this should be extended to >>>>>> hw/s390x/s390-ccw.c >>>>>> >>>>>> What do you think? >>>>> I'm not sure that makes sense, especially as not everything might >>>>> explicitly refer to a certain subchannel. >>>>> >>>>> Let's just add the subchannel id here? In this case, this is really a >>>>> useful piece of information (which device is showing this behaviour?) >>>>> >>>> >>>> The same applies to warn_report("vfio-ccw requires PFCH flag set") (that is, >>>> on which device (that has no force-orb-pfch=on specified) is the guest issuing >>>> ORBs with the PFCH unset), or? >>>> Should I go for >>>> "vfio-ccw (xx.xx.xxxx): vfio-ccw requires PFCH flag set" >>>> and >>>> "vfio-ccw (xx.xx.xxxx): PFCH flag forced" >>>> or just for the second one, or some third option? >>> >>> Yes, it makes sense for both. >>> >>> Related: Do we expect the guest driver to learn from its experience and >>> not try without pfch again? It is probably not very helpful if the logs >>> get filled with a lot of "vfio-ccw requires pfch" messages... >>> >> >> Don't really know. Dong Jia is probably more qualified to answer that question. >> I don't expect the guest driver to do so. There are probably more intelligent >> strategies to deal with this, but the question is what do we gain in the end >> (linux guests are not affected). We should probably not overthink this. > > So, print both messages just once per device? > We can do that. I will morph warned_force_orb_pfch to warned_orb_pfch. That way we can get away with one boolean, as the both cases are mutually exclusive. Regards, Halil