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=-6.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,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 362DCCA9EA0 for ; Tue, 22 Oct 2019 08:22:18 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id C71D020684 for ; Tue, 22 Oct 2019 08:22:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="A2aPHdPY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C71D020684 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0B42A1B94A; Tue, 22 Oct 2019 10:22:09 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 2192FF04 for ; Tue, 22 Oct 2019 10:22:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571732526; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rbrogettcKpP4nHURRilyn1GPxCxNz65MKTNw86On/g=; b=A2aPHdPYAwfrtPtmdyKLyRiMXe763EfLL83SWYuHW4H+19I7hY0TuYWlkdfazDRfbsiXt3 nLlPiulWvV3ftg1eJjwxUPxQqblib5QZIYGeYbx+avDldAqD83po+FXMSlLKS3xRDrZLDq toWMrZGw6TUH97J1eu5EX1P9UsZdXmU= 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-74-ajI7fAWKPuqbBtYGGzgDRA-1; Tue, 22 Oct 2019 04:22:02 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B0CE51005500; Tue, 22 Oct 2019 08:22:01 +0000 (UTC) Received: from dmarchan.remote.csb (ovpn-204-129.brq.redhat.com [10.40.204.129]) by smtp.corp.redhat.com (Postfix) with ESMTP id 70B6B60C57; Tue, 22 Oct 2019 08:22:00 +0000 (UTC) From: David Marchand To: dev@dpdk.org Cc: maxime.coquelin@redhat.com, Tiwei Bie , Zhihong Wang Date: Tue, 22 Oct 2019 10:21:43 +0200 Message-Id: <1571732503-30424-3-git-send-email-david.marchand@redhat.com> In-Reply-To: <1571732503-30424-1-git-send-email-david.marchand@redhat.com> References: <1571313388-32142-1-git-send-email-david.marchand@redhat.com> <1571732503-30424-1-git-send-email-david.marchand@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: ajI7fAWKPuqbBtYGGzgDRA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: [dpdk-dev] [PATCH v3 2/2] net/virtio: do not require IO permissions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On x86, iopl permissions are only available to root user (or users that have the CAP_SYS_RAWIO capability). But those permissions are only needed when the virtio devices accesses are done with inb/outb instructions, which is when the device is bound to a UIO kernel module. So far, the virtio driver was refusing to register based on the check on IO permissions. This check does not make sense when binding the device to vfio. Now that the check on IO permissions has been abstracted in the ioport API, we can remove it on virtio side. We still need to call rte_eal_iopl_init() in the virtio constructor so that the interrupt thread inherits this permission in the case it could be used with UIO later. Signed-off-by: David Marchand Reviewed-by: Maxime Coquelin --- Changelog since v1: - remove log message in constructor (thanks Tiwei), - reword commit log, --- drivers/net/virtio/virtio_ethdev.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio= _ethdev.c index 7261109..0a2ed2e 100644 --- a/drivers/net/virtio/virtio_ethdev.c +++ b/drivers/net/virtio/virtio_ethdev.c @@ -1995,11 +1995,6 @@ exit: static int eth_virtio_pci_probe(struct rte_pci_driver *pci_drv __rte_unuse= d, =09struct rte_pci_device *pci_dev) { -=09if (rte_eal_iopl_init() !=3D 0) { -=09=09PMD_INIT_LOG(ERR, "IOPL call failed - cannot use virtio PMD"); -=09=09return 1; -=09} - =09/* virtio pmd skips probe if device needs to work in vdpa mode */ =09if (vdpa_mode_selected(pci_dev->device.devargs)) =09=09return 1; --=20 1.8.3.1