From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 99C83A034F; Tue, 12 May 2020 20:16:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0D7EC1BFA6; Tue, 12 May 2020 20:16:33 +0200 (CEST) Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by dpdk.org (Postfix) with ESMTP id 7BA811BF92 for ; Tue, 12 May 2020 20:16:31 +0200 (CEST) Received: by mail-pj1-f68.google.com with SMTP id hi11so9918558pjb.3 for ; Tue, 12 May 2020 11:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=4B+MK2GllmT6ivGNv1mvLSjx62nTfI7ZsQSZbNXryUY=; b=FFQlsaTGZqn6PBibfIMVDTHFP/hIaoEmQRr+xCZ/UmcukzkbgJEJzUamlh2wlHBbvz tVQreTzMSpnZHBHu19eem3RXvv3SJf5OY6Qdz8LR9/f9iGAgjEWxjEiivrs6mIORsvX/ aW3lwTphZKajRoJ9yxkjrMlxm8St8BjQyrc2CMkrHFbZok4lyocTD5L0dIRdO3WU0sdb m3zc14qoF4laGZ16EDy5d1ke1V2cSj8aH0nTPikPBfHevBV57Mt/rZ+bX3LmPsS//PwQ N91w7/hiom30ad1iHAlIamrvvpWC35GZHVSTZ/Lu8AvJ6iQg0v5RcwCJs1UA9PjKpd+I cWvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=4B+MK2GllmT6ivGNv1mvLSjx62nTfI7ZsQSZbNXryUY=; b=PR6M0Tu6i7bhFtd9ADvbMEcKF5QxTAr4qgghXcIuU+z83te/soClqk9DuRyv2/I2bz he+JK4Cnbicc4jOjNdbvjiCsHxQ+pkSrLDHj3MEkahVoKf9GBq0Rb1BT1UoLGtTi0iPV 5hKXefktcKcFUhX/XOrKhck8qdWlaqhoYfbSo9lti3A7HTHJ1epPq61Rq4TzUJy+z6Fg lJbHk3/VstWKJEzkVp9FCOVVkksntkfjekWTXEqWYtd3emNeRKYlGCevJPxzoTif68DB maAmbmifHdTdPOLQF/+V3z5Edq0/zKmJUp9Rh24EIywt6HhbDvqRGxW1Ddx+3xhqDDtH FMRA== X-Gm-Message-State: AGi0PuYMwMnNIQ+uAkKrEcBSYzlK/WOrXIdiZnF0l4B2n0L5QaiRpyTX czb6ZBSCfjHEwsV4sXBO4yZ6Vw== X-Google-Smtp-Source: APiQypJGbUMfM6EarBwOwjdpldpgYJg8NCQ0BRehow6ZElBCl58GAoECbehEVasktPKxnJnuVIap5w== X-Received: by 2002:a17:902:728f:: with SMTP id d15mr21279520pll.285.1589307390424; Tue, 12 May 2020 11:16:30 -0700 (PDT) Received: from [192.168.1.18] (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id bg6sm13514050pjb.21.2020.05.12.11.16.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2020 11:16:29 -0700 (PDT) Date: Tue, 12 May 2020 11:16:28 -0700 From: Stephen Hemminger To: Darek Stojaczyk Cc: dev@dpdk.org Message-Id: <1589307388.25513.0@networkplumber.org> In-Reply-To: <20200512133057.106374-1-dariusz.stojaczyk@intel.com> References: <20200512133057.106374-1-dariusz.stojaczyk@intel.com> X-Mailer: geary/3.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] pci: properly parse 32-bit domain numbers 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 Tue, May 12, 2020 at 3:30 pm, Darek Stojaczyk wrote: > The parsing code was bailing on domains greater than UINT16_MAX, > but domain numbers like that are still valid and present on some > systems. > One example is Intel VMD (Volume Management Device), which acts > somewhat > as a software-managed PCI switch and its upstream linux driver assigns > all downstream devices a PCI domain of 0x10000. > > Parsing a BDF like 10000:01:00.0 was failing before. To fix it, > increase > the upper limit of domain number to UINT32_MAX. This matches the size > of > struct rte_pci_addr->domain (uint32). > > Signed-off-by: Darek Stojaczyk > > --- > lib/librte_pci/rte_pci.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_pci/rte_pci.c b/lib/librte_pci/rte_pci.c > index d1ab6b414d..ad2cdfebb2 100644 > --- a/lib/librte_pci/rte_pci.c > +++ b/lib/librte_pci/rte_pci.c > @@ -72,9 +72,9 @@ pci_dbdf_parse(const char *input, struct > rte_pci_addr *dev_addr) > > errno = 0; > val = strtoul(in, &end, 16); > - if (errno != 0 || end[0] != ':' || val > UINT16_MAX) > + if (errno != 0 || end[0] != ':' || val > UINT32_MAX) > return -EINVAL; > - dev_addr->domain = (uint16_t)val; > + dev_addr->domain = (uint32_t)val; > in = end + 1; > in = get_u8_pciaddr_field(in, &dev_addr->bus, ':'); > if (in == NULL) > -- > 2.17.1 Agree this came up before on Hyper-V as well. It meant fixing libpci. Not sure the cast of val is necessary, other than an attempt to silence some static checker about implicit type conversion causing loss of precision. >