From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59972)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cohuck@redhat.com>) id 1fLX7O-00050i-Sr
	for qemu-devel@nongnu.org; Wed, 23 May 2018 13:00:10 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cohuck@redhat.com>) id 1fLX7L-0000p6-1b
	for qemu-devel@nongnu.org; Wed, 23 May 2018 13:00:06 -0400
Date: Wed, 23 May 2018 18:59:57 +0200
From: Cornelia Huck <cohuck@redhat.com>
Message-ID: <20180523185957.41af37b2.cohuck@redhat.com>
In-Reply-To: <5de50b20-a331-78ea-a7f4-6fdd995ed083@linux.ibm.com>
References: <20180522221655.78979-1-pasic@linux.ibm.com>
	<20180522221655.78979-2-pasic@linux.ibm.com>
	<20180523113708.50b21a77.cohuck@redhat.com>
	<a3ab7dfd-4cc1-5632-1590-bce4a40f063e@linux.ibm.com>
	<20180523164640.225908a9.cohuck@redhat.com>
	<5de50b20-a331-78ea-a7f4-6fdd995ed083@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v2 1/2] vfio-ccw: add force
 unlimited prefetch property
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: Halil Pasic <pasic@linux.ibm.com>
Cc: Dong Jia Shi <bjsdjshi@linux.ibm.com>, "Jason J. Herne" <jjherne@linux.ibm.com>, qemu-s390x@nongnu.org, qemu-devel@nongnu.org

On Wed, 23 May 2018 18:23:44 +0200
Halil Pasic <pasic@linux.ibm.com> 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...