Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1263565pxb; Fri, 13 Nov 2020 08:14:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJyxQKk3fdWrVOLjBHEA97vXXT3vwwybe16Va3pwp3qz+kpP37a5xEBEeamaRnpftTeWT3FF X-Received: by 2002:aa7:d894:: with SMTP id u20mr3177843edq.284.1605284065487; Fri, 13 Nov 2020 08:14:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605284065; cv=none; d=google.com; s=arc-20160816; b=jp6S+T6KfrWhiFlmM6yRsBQois/d3iShcTxRt9Ucai3vL2Hecj2vzi6Vd/uZQ8r04D BOV4DHcSNAQ+9oEsESyOuiv2Z/PLlBpPjDS+2JbU5/sxElZrEbIdkSDJ7KgUdaYjXLsa xvFjnZiDbnDcclkyUL9zohRzsS1gp41sFlmn9W0xHJbMkbfxsSktVE6BIZso6n5eHdnH AnUvuCkm+3NxmiSch+aXDi/NRIWwzuiI+hUHAyoYjkbvN8ldFRftqhTd3c1ba/G5uakS QDLOoGZLxErphN4XQYVFVGm05IgYA4Aga/V+kVGAhErho5mngrBFPEXk7svsPz+0oVY7 O/GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:dkim-signature; bh=MzPV3G2COP33yZAJV3i6S/9jkDAO8h9mjkNYvu/SPwg=; b=fS6ZfEp3Tvial7kI91NmDPSybBj1ED8osDe8RZ37Ss92++oWeL6Ew2gwpFNIwhTY+B AOpbUsbtoUAQRB5c+lWh4Chh8gBLoQ2DCCLK8wvzS2PS2fXMLVjZTA7EXZERhSQB56g4 mjySzQKIwDTim6MkhsSNTbcHiNmPjG06ZkH8cDauKEmToWFVN8XTTPycC+v2V6dlqKoK 2x390qR7cWs2PNEja04wG6dpO8aqLE3tq2thrEEK0Hcctg8jIi+oMq/qVxW964eYfQgB UI2YzkG4AJqPvA1CKMbixI3Y3AscUAVkWnE2jA3tT41q5svw9QZy/NlJCIvLt8VzMQWt GPGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZMfFlICi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id qn24si6103025ejb.680.2020.11.13.08.14.02; Fri, 13 Nov 2020 08:14:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZMfFlICi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1726988AbgKMQMO (ORCPT + 99 others); Fri, 13 Nov 2020 11:12:14 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:56683 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726920AbgKMQMD (ORCPT ); Fri, 13 Nov 2020 11:12:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605283922; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MzPV3G2COP33yZAJV3i6S/9jkDAO8h9mjkNYvu/SPwg=; b=ZMfFlICiyxVYaVKoA75+pBccEyW5XzhvdG9W7JVTkuifiylnwQq77X9zjKUbYB6w+qagwD OrKBuzfVlD6zlyhKtKQFGVb4swRPL50D2ffVdwk7TUo+7C7dorVz0u1433nD20bEnEsRcD OtfrrOgXskbOQL8IuSp1jAGzpr9KAag= 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-130-vDgneSjqO1Gg21M8dJbxMw-1; Fri, 13 Nov 2020 11:11:58 -0500 X-MC-Unique: vDgneSjqO1Gg21M8dJbxMw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 58756801FDE; Fri, 13 Nov 2020 16:11:56 +0000 (UTC) Received: from [10.36.114.125] (ovpn-114-125.ams2.redhat.com [10.36.114.125]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8442B46; Fri, 13 Nov 2020 16:11:49 +0000 (UTC) Subject: Re: [PATCH v10 05/11] vfio/pci: Register an iommu fault handler To: Zenghui Yu , eric.auger.pro@gmail.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, joro@8bytes.org, alex.williamson@redhat.com, jacob.jun.pan@linux.intel.com, yi.l.liu@intel.com, robin.murphy@arm.com References: <20200320161911.27494-1-eric.auger@redhat.com> <20200320161911.27494-6-eric.auger@redhat.com> <571978ff-ee8a-6e9f-6755-519d0871646f@huawei.com> From: Auger Eric Message-ID: <80befd0f-8876-2cd2-7af0-c5e32e79323b@redhat.com> Date: Fri, 13 Nov 2020 17:11:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <571978ff-ee8a-6e9f-6755-519d0871646f@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Zenghui, On 9/24/20 10:49 AM, Zenghui Yu wrote: > Hi Eric, > > On 2020/3/21 0:19, Eric Auger wrote: >> Register an IOMMU fault handler which records faults in >> the DMA FAULT region ring buffer. In a subsequent patch, we >> will add the signaling of a specific eventfd to allow the >> userspace to be notified whenever a new fault as shown up. >> >> Signed-off-by: Eric Auger > > [...] > >> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c >> index 586b89debed5..69595c240baf 100644 >> --- a/drivers/vfio/pci/vfio_pci.c >> +++ b/drivers/vfio/pci/vfio_pci.c >> @@ -27,6 +27,7 @@ >>   #include >>   #include >>   #include >> +#include >>     #include "vfio_pci_private.h" >>   @@ -283,6 +284,38 @@ static const struct vfio_pci_regops >> vfio_pci_dma_fault_regops = { >>       .add_capability = vfio_pci_dma_fault_add_capability, >>   }; >>   +int vfio_pci_iommu_dev_fault_handler(struct iommu_fault *fault, >> void *data) >> +{ >> +    struct vfio_pci_device *vdev = (struct vfio_pci_device *)data; >> +    struct vfio_region_dma_fault *reg = >> +        (struct vfio_region_dma_fault *)vdev->fault_pages; >> +    struct iommu_fault *new = >> +        (struct iommu_fault *)(vdev->fault_pages + reg->offset + >> +            reg->head * reg->entry_size); > > Shouldn't 'reg->head' be protected under the fault_queue_lock? Otherwise > things may change behind our backs...> > We shouldn't take any assumption about how IOMMU driver would report the > fault (serially or in parallel), I think. Yes I modified the locking Thanks Eric > >> +    int head, tail, size; >> +    int ret = 0; >> + >> +    if (fault->type != IOMMU_FAULT_DMA_UNRECOV) >> +        return -ENOENT; >> + >> +    mutex_lock(&vdev->fault_queue_lock); >> + >> +    head = reg->head; >> +    tail = reg->tail; >> +    size = reg->nb_entries; >> + >> +    if (CIRC_SPACE(head, tail, size) < 1) { >> +        ret = -ENOSPC; >> +        goto unlock; >> +    } >> + >> +    *new = *fault; >> +    reg->head = (head + 1) % size; >> +unlock: >> +    mutex_unlock(&vdev->fault_queue_lock); >> +    return ret; >> +} >> + >>   #define DMA_FAULT_RING_LENGTH 512 >>     static int vfio_pci_init_dma_fault_region(struct vfio_pci_device >> *vdev) >> @@ -317,6 +350,13 @@ static int vfio_pci_init_dma_fault_region(struct >> vfio_pci_device *vdev) >>       header->entry_size = sizeof(struct iommu_fault); >>       header->nb_entries = DMA_FAULT_RING_LENGTH; >>       header->offset = sizeof(struct vfio_region_dma_fault); >> + >> +    ret = iommu_register_device_fault_handler(&vdev->pdev->dev, >> +                    vfio_pci_iommu_dev_fault_handler, >> +                    vdev); >> +    if (ret) >> +        goto out; >> + >>       return 0; >>   out: >>       kfree(vdev->fault_pages); > > > Thanks, > Zenghui >