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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 EAEF7C10F0E for ; Tue, 9 Apr 2019 13:23:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B44BA20880 for ; Tue, 9 Apr 2019 13:23:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726987AbfDINXr (ORCPT ); Tue, 9 Apr 2019 09:23:47 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56424 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726035AbfDINXr (ORCPT ); Tue, 9 Apr 2019 09:23:47 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x39DNRP4126707 for ; Tue, 9 Apr 2019 09:23:45 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rruwfh9n5-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 09 Apr 2019 09:23:37 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 9 Apr 2019 14:23:20 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp01.uk.ibm.com (192.168.101.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 9 Apr 2019 14:23:17 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x39DNFjm58720366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Apr 2019 13:23:15 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 806E511C052; Tue, 9 Apr 2019 13:23:15 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 01CDD11C050; Tue, 9 Apr 2019 13:23:15 +0000 (GMT) Received: from oc2783563651 (unknown [9.152.224.40]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 9 Apr 2019 13:23:14 +0000 (GMT) Date: Tue, 9 Apr 2019 15:23:13 +0200 From: Halil Pasic To: Cornelia Huck Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org, Martin Schwidefsky , Sebastian Ott , virtualization@lists.linux-foundation.org, Christian Borntraeger , Viktor Mihajlovski , Vasily Gorbik , Janosch Frank , Claudio Imbrenda , Farhan Ali , Eric Farman Subject: Re: [RFC PATCH 02/12] virtio/s390: DMA support for virtio-ccw In-Reply-To: <20190409150120.61abad60.cohuck@redhat.com> References: <20190404231622.52531-1-pasic@linux.ibm.com> <20190404231622.52531-3-pasic@linux.ibm.com> <20190409115743.26e51b81.cohuck@redhat.com> <20190409132927.5df3bc50@oc2783563651> <20190409150120.61abad60.cohuck@redhat.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: 7bit X-TM-AS-GCONF: 00 x-cbid: 19040913-4275-0000-0000-00000325F158 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19040913-4276-0000-0000-000038350AAD Message-Id: <20190409152313.0296e8f1@oc2783563651> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-09_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090085 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 9 Apr 2019 15:01:20 +0200 Cornelia Huck wrote: > On Tue, 9 Apr 2019 13:29:27 +0200 > Halil Pasic wrote: > > > On Tue, 9 Apr 2019 11:57:43 +0200 > > Cornelia Huck wrote: > > > > > On Fri, 5 Apr 2019 01:16:12 +0200 > > > Halil Pasic wrote: > > > > > > > Currently we have a problem if a virtio-ccw device has > > > > VIRTIO_F_IOMMU_PLATFORM. > > > > > > Can you please describe what the actual problem is? > > > > > > > Without this patch: [..] > > virtio_ccw 0.0.0300: no vq > > virtio_blk: probe of virtio1 failed with error -12 > > virtio_blk: probe of virtio3 failed with error -12 > > > > Means virtio devices broken. > > > > Should I > > s/we have a problem if a virtio-ccw device/virtio-ccw devices do not work if the device/ > > ? > > Much better :) > > (That is, this happens if we switch on the feature bit in the > hypervisor, right?) > Yes, that is with qemu -device virtio-blk-ccw,iommu_platform=on (and no PV whatsoever). I will change the commit message accordingly. [..] > > > > @@ -1255,6 +1254,18 @@ static int virtio_ccw_online(struct ccw_device *cdev) > > > > ret = -ENOMEM; > > > > goto out_free; > > > > } > > > > + vcdev->vdev.dev.parent = &cdev->dev; > > > > > > That one makes sense, pci and mmio are doing that as well. > > > > > > > + cdev->dev.dma_mask = &vcdev->dma_mask; > > > > > > That one feels a bit weird. Will this change in one of the follow-on > > > patches? (Have not yet looked at the whole series.) > > > > I don't thinks so. Do you mean this should happen within the cio code? > > I think I started out with the idea to keep the scope as narrow as > > possible. Do you have any suggestions? > > From what I see, you set the mask from the virtio-ccw side, then > propagate it up to the general ccw_device, and then the generic virtio > code will fetch it from the ccw_device. Right! For some reason dma_mask is a pointer. And I need virtio core to use a sane value for virtio_ccw devices. > Don't you potentially need > something for other ccw_devices in that protected hipervisor case as > well (e.g for 3270)? Maybe, maybe not. The first stage is likely to be virito only. I would prefer sorting out stuff like 3270 as the need arises. Also see my response to patch 4 (Message-Id: <20190409141114.7dcce94a@oc2783563651>). > > > > > > > > > > + > > > > + ret = dma_set_mask_and_coherent(&cdev->dev, > > > > DMA_BIT_MASK(64)); > > > > + if (ret) > > > > + ret = dma_set_mask_and_coherent(&cdev->dev, > > > > + > > > > DMA_BIT_MASK(32)); > > > > + if (ret) { > > > > + dev_warn(&cdev->dev, "Failed to enable 64-bit > > > > or 32-bit DMA. Trying to continue, but this might not > > > > work.\n"); > > > > > > This does not look like you'd try to continue? > > > > > > > I remember now. First I did continue, then I changed this to fail > > hard so I can not ignore any such problems while smoke testing ('I > > don't always check the kernel messages'), but kept the old message. > > This basically should not fail anyway, otherwise we have a problem > > AFAIU. > > > > By the way virtio-pci tries to continue indeed, and this is also > > where the wording comes from ;). > > > > What would you prefer? Try to continue or fail right away? > > If it does not have a chance of working properly in the general case, > I'd fail. > Agreed! I will make it so. Would dropping ' Trying to continue, but this might not work.' from the warning message work for you? I could also drop the attempt to set a 32 bit mask if you agree. Do you? Many thanks for your review! Regards, Halil