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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,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 2F625C10F11 for ; Wed, 10 Apr 2019 17:49:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F4182082E for ; Wed, 10 Apr 2019 17:49:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730270AbfDJRs7 (ORCPT ); Wed, 10 Apr 2019 13:48:59 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60882 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729224AbfDJRs6 (ORCPT ); Wed, 10 Apr 2019 13:48:58 -0400 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3AHj67N013197 for ; Wed, 10 Apr 2019 13:48:57 -0400 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rsmj19ycy-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 10 Apr 2019 13:48:57 -0400 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 10 Apr 2019 18:48:55 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) 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) Wed, 10 Apr 2019 18:48:53 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x3AHmpSK42991810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Apr 2019 17:48:51 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 334135204F; Wed, 10 Apr 2019 17:48:51 +0000 (GMT) Received: from oc2783563651 (unknown [9.152.224.40]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id B370C5204E; Wed, 10 Apr 2019 17:48:50 +0000 (GMT) Date: Wed, 10 Apr 2019 19:48:49 +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 10/12] virtio/s390: consolidate DMA allocations In-Reply-To: <20190410183643.694ccb85.cohuck@redhat.com> References: <20190404231622.52531-1-pasic@linux.ibm.com> <20190404231622.52531-11-pasic@linux.ibm.com> <20190410104649.12cdbcba.cohuck@redhat.com> <20190410171254.71206015@oc2783563651> <20190410183643.694ccb85.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: 19041017-0012-0000-0000-0000030D6C39 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19041017-0013-0000-0000-000021459197 Message-Id: <20190410194849.511ecc46@oc2783563651> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-10_08:,, 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904100119 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 10 Apr 2019 18:36:43 +0200 Cornelia Huck wrote: > On Wed, 10 Apr 2019 17:12:54 +0200 > Halil Pasic wrote: > > > On Wed, 10 Apr 2019 10:46:49 +0200 > > Cornelia Huck wrote: > > > > > On Fri, 5 Apr 2019 01:16:20 +0200 > > > Halil Pasic wrote: > > > > > diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c > > > > index aa45a6a027ae..7268149f2ee8 100644 > > > > --- a/drivers/s390/virtio/virtio_ccw.c > > > > +++ b/drivers/s390/virtio/virtio_ccw.c > > > > @@ -49,12 +49,12 @@ struct vq_config_block { > > > > struct vcdev_dma_area { > > > > unsigned long indicators; > > > > unsigned long indicators2; > > > > + struct vq_config_block config_block; > > > > + __u8 status; /* TODO check __aligned(8); */ > > > > > > ...I think that needs attention. > > > > Yes I wanted to discuss this with you. I could not find anything > > in the virtio spec that would put requirements on how this > > status field needs to be aligned. But I did not look to hard. > > > > The ccw.cda can hold an arbitrary data address AFAIR (for indirect, > > of course we do have alignment requirements). > > I think it needs to be doubleword aligned. > I've re-read the part of the PoP that describes the ccw formats. And it reinforced my position: for IDA and MIDA we need proper alignment, but if the CCW ain't an indirect one there is no alignment requirement. QEMU also does not seem to check either. Can you double-check and provide me with a reference that proves me wrong if I'm wrong. > > > > Apparently status used to be a normal field, and became a pointer with > > 73fa21ea4fc6 "KVM: s390: Dynamic allocation of virtio-ccw I/O > > data." (Cornelia Huck, 2013-01-07). I could not quite figure out why. > > In the beginning, the code used a below-2G-area for all commands. > Rather than adding locking to avoid races there, that commit switches > to allocating the needed structures individually. The status field > needed to be below 2G, so it needed to be allocated separately. > I get it now. The confusing part was that the field 'area' was about holding the address of the also previously dynamically allocated below 2G area that was used for talking to the hypervisor via CCW I/O. > > > > So maybe dropping the TODO comment will do just fine. What do you think? > I still think we just need to drop the comment, as we don't have to align it. Regards, Halil