Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1634990ybv; Fri, 21 Feb 2020 00:42:56 -0800 (PST) X-Google-Smtp-Source: APXvYqzxStAPfw68TBkCb11UoUJJs4jxKWtQd9LwH+cwg8gWZuX5D4xgSaexU+hargeQoDwp9Y85 X-Received: by 2002:a05:6830:22cd:: with SMTP id q13mr27338613otc.224.1582274576503; Fri, 21 Feb 2020 00:42:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582274576; cv=none; d=google.com; s=arc-20160816; b=bvWElusiUPFDW/siPho4SDW15CqBe6PEaQ1ZU/c0PIf8xr+tZaHVHfb7ghpLhEjrwy lBYWdmgpNT/tvoDkkYrS3EljoVnPwKtzo/99zNFwBzXspbbBA7P+JeU3Yca4SYMXYBr8 0x6rK8SPR7J49yYuXfBZfaemK7VoqpQwEAxch/Wmng+mPHxTxImvIAOjgfiW4xxPdiTX NtTp99U0sd7p574/8mL2DDSkVuM9oVQ8hzTchblNnCLrMO9Ln+xtN0UoWxPTkfuGYdEr rPjlv/tKECIT1o686vRGyWPmfe2jBHpasV2mIdIHbNS3Pn4jtTGkkOAV9Zz1SPKq4kW0 3aSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=qZ2vYX6aTEtYA+Rmtsl2PSnzUra/4wEX+6A+xs3OWnE=; b=0IE9JJ2r7j9mP/M16xUYAQo7SLyOGA0WXBYjZNPnPbiCCTQDZvnDCsWuMeCorIV1JC qMNHDzUXkG89z7+DNfySUcdaL+ANBhVkVizEGE9K2muNk7xQ3bB4xRyUwGj3tFLIrHNl VUcodeEPDKQRKSIB/12anmn+cDrxpgkpTC2tgAj5llAcI8+gdH5jl8rwAuqZsmUj59Tt klxrwezeBHWfiXQnqxAIuozE5Bi2JpU5fdflhmg03ySUF5OEOB39WIwovnkVMCvhElWo 8BeNQ5ImsNZvLxUCBNl/YDtwy+64iQ4NqbqpRSdKK563Ug3hZgJXIMtATCrqDDfmDvJ5 WCYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fICJukfY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u21si1128354otq.137.2020.02.21.00.42.44; Fri, 21 Feb 2020 00:42:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fICJukfY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731015AbgBUIlL (ORCPT + 99 others); Fri, 21 Feb 2020 03:41:11 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:50435 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730683AbgBUH5x (ORCPT ); Fri, 21 Feb 2020 02:57:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582271872; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qZ2vYX6aTEtYA+Rmtsl2PSnzUra/4wEX+6A+xs3OWnE=; b=fICJukfYhcyMyFkOqBlQi6nnMvVXDkasO/fHBO4MvkX33xhY7jiPQbioiDX7/DQktAMZVy L3sFBD3s/TTKuZ0NtGge89eKIL1o8fV1jQFNHw9YxruLPMQ/aQq6TnmWn5smQgWkbnxd9B zU6S0yr0b6bUzkhn3IntLZjHwUlHZ/g= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-347-s328FKtIP_GiYZgic4bVwg-1; Fri, 21 Feb 2020 02:57:50 -0500 X-MC-Unique: s328FKtIP_GiYZgic4bVwg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 89523107ACC5; Fri, 21 Feb 2020 07:57:47 +0000 (UTC) Received: from [10.72.13.208] (ovpn-13-208.pek2.redhat.com [10.72.13.208]) by smtp.corp.redhat.com (Postfix) with ESMTP id A094B8ECFD; Fri, 21 Feb 2020 07:57:31 +0000 (UTC) Subject: Re: [PATCH V4 5/5] vdpasim: vDPA device simulator To: Jason Gunthorpe Cc: "mst@redhat.com" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "netdev@vger.kernel.org" , "tiwei.bie@intel.com" , "maxime.coquelin@redhat.com" , "cunming.liang@intel.com" , "zhihong.wang@intel.com" , "rob.miller@broadcom.com" , "xiao.w.wang@intel.com" , "haotian.wang@sifive.com" , "lingshan.zhu@intel.com" , "eperezma@redhat.com" , "lulu@redhat.com" , Parav Pandit , "kevin.tian@intel.com" , "stefanha@redhat.com" , "rdunlap@infradead.org" , "hch@infradead.org" , "aadam@redhat.com" , Jiri Pirko , Shahaf Shuler , "hanand@xilinx.com" , "mhabets@solarflare.com" References: <20200220061141.29390-1-jasowang@redhat.com> <20200220061141.29390-6-jasowang@redhat.com> <20200220151215.GU23930@mellanox.com> From: Jason Wang Message-ID: <6c341a77-a297-b7c7-dea5-b3f7b920b1f3@redhat.com> Date: Fri, 21 Feb 2020 15:57:29 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20200220151215.GU23930@mellanox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/2/20 =E4=B8=8B=E5=8D=8811:12, Jason Gunthorpe wrote: > On Thu, Feb 20, 2020 at 02:11:41PM +0800, Jason Wang wrote: >> +static void vdpasim_device_release(struct device *dev) >> +{ >> + struct vdpasim *vdpasim =3D dev_to_sim(dev); >> + >> + cancel_work_sync(&vdpasim->work); >> + kfree(vdpasim->buffer); >> + vhost_iotlb_free(vdpasim->iommu); >> + kfree(vdpasim); >> +} >> + >> +static struct vdpasim *vdpasim_create(void) >> +{ >> + struct virtio_net_config *config; >> + struct vhost_iotlb *iommu; >> + struct vdpasim *vdpasim; >> + struct device *dev; >> + void *buffer; >> + int ret =3D -ENOMEM; >> + >> + iommu =3D vhost_iotlb_alloc(2048, 0); >> + if (!iommu) >> + goto err; >> + >> + buffer =3D kmalloc(PAGE_SIZE, GFP_KERNEL); >> + if (!buffer) >> + goto err_buffer; >> + >> + vdpasim =3D kzalloc(sizeof(*vdpasim), GFP_KERNEL); >> + if (!vdpasim) >> + goto err_alloc; >> + >> + vdpasim->buffer =3D buffer; >> + vdpasim->iommu =3D iommu; >> + >> + config =3D &vdpasim->config; >> + config->mtu =3D 1500; >> + config->status =3D VIRTIO_NET_S_LINK_UP; >> + eth_random_addr(config->mac); >> + >> + INIT_WORK(&vdpasim->work, vdpasim_work); >> + spin_lock_init(&vdpasim->lock); >> + >> + vringh_set_iotlb(&vdpasim->vqs[0].vring, vdpasim->iommu); >> + vringh_set_iotlb(&vdpasim->vqs[1].vring, vdpasim->iommu); >> + >> + dev =3D &vdpasim->dev; >> + dev->release =3D vdpasim_device_release; >> + dev->coherent_dma_mask =3D DMA_BIT_MASK(64); >> + set_dma_ops(dev, &vdpasim_dma_ops); >> + dev_set_name(dev, "%s", VDPASIM_NAME); >> + >> + ret =3D device_register(&vdpasim->dev); >> + if (ret) >> + goto err_init; > It is a bit weird to be creating this dummy parent, couldn't this be > done by just passing a NULL parent to vdpa_alloc_device, doing > set_dma_ops() on the vdpasim->vdpa->dev and setting dma_device to > vdpasim->vdpa->dev ? I think it works. >> + vdpasim->vdpa =3D vdpa_alloc_device(dev, dev, &vdpasim_net_config_op= s); >> + if (ret) >> + goto err_vdpa; >> + ret =3D vdpa_register_device(vdpasim->vdpa); >> + if (ret) >> + goto err_register; >> + >> + return vdpasim; >> + >> +err_register: >> + put_device(&vdpasim->vdpa->dev); >> +err_vdpa: >> + device_del(&vdpasim->dev); >> + goto err; >> +err_init: >> + put_device(&vdpasim->dev); >> + goto err; > If you do the vdmasim alloc first, and immediately do > device_initialize() then all the failure paths can do put_device > instead of having this ugly goto unwind split. Just check for > vdpasim->iommu =3D=3D NULL during release. Yes, that looks simpler. > >> +static int __init vdpasim_dev_init(void) >> +{ >> + vdpasim_dev =3D vdpasim_create(); >> + >> + if (!IS_ERR(vdpasim_dev)) >> + return 0; >> + >> + return PTR_ERR(vdpasim_dev); >> +} >> + >> +static int vdpasim_device_remove_cb(struct device *dev, void *data) >> +{ >> + struct vdpa_device *vdpa =3D dev_to_vdpa(dev); >> + >> + vdpa_unregister_device(vdpa); >> + >> + return 0; >> +} >> + >> +static void __exit vdpasim_dev_exit(void) >> +{ >> + device_for_each_child(&vdpasim_dev->dev, NULL, >> + vdpasim_device_remove_cb); > Why the loop? There is only one device, and it is in the global > varaible vdmasim_dev ? Not necessary but doesn't harm, will remove this. Thanks > > Jason >