From patchwork Sun Apr 26 20:42:29 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Henrique Cerri X-Patchwork-Id: 1277233 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 499Kbx3rwMz9sSc; Mon, 27 Apr 2020 06:42:53 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1jSo6y-0003Ie-SY; Sun, 26 Apr 2020 20:42:48 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jSo6w-0003Gf-81 for kernel-team@lists.ubuntu.com; Sun, 26 Apr 2020 20:42:46 +0000 Received: from mail-qk1-f197.google.com ([209.85.222.197]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jSo6v-0001NY-Hx for kernel-team@lists.ubuntu.com; Sun, 26 Apr 2020 20:42:45 +0000 Received: by mail-qk1-f197.google.com with SMTP id f11so17254605qkk.16 for ; Sun, 26 Apr 2020 13:42:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=v+eClUxWUPM64j0TOye4xQ6soeAUP+PAf85Ddgl3VmQ=; b=oM9YS/NWMem0qczAVl1pRM72hoSTKGzPixRIk3skLtjAJwkrHWrrpBk0JWM1uDMCQP O3low/uZjB8SFkydwiUbS+NNxoAsn43AMTZ9Ku/i5d3zgCKp9pdXdDwujNke3EGI0Huo UopBxDLqgF6WxPhdh9bSiEmUfal6OYj8PYui2YS7ZzWuVllVoMyZaB/I/NrvNzeFDz7X 93hpXtDiK8UzHVhr/Hgx71Vfqzoqmi8SOFaRspzOf/HYGopGROV9uqck1H8SgjfDMh0v xikDhxVoYhdl3GAmtan+2vOzJBcclxH8u7uE1ELuiduR/aIdLmW1YsRiLI1vlproxo4n ek8w== X-Gm-Message-State: AGi0PuaBsmuOIhlVhdMDd+P9aonn1jETDmZYQo05O0OPUGcyg8AxQHoi 6OYezybiYhq2tsxFmYIpOC7YA2GUiFDTHxP7OSCnHCMUwvaHEF0D/fi8maM6WuAbUUCzOuad75l /at9/7w1OhVN+co0qZoujkdLHa8QUJW6qEDONTDzZ X-Received: by 2002:a37:508:: with SMTP id 8mr19844953qkf.265.1587933764283; Sun, 26 Apr 2020 13:42:44 -0700 (PDT) X-Google-Smtp-Source: APiQypImEUcK41lm/QyggwObTUV9BBXeBGbRRra+/wBfGDsPXanxUGOMO0ukKw1AzUbMNtNLsMwtpw== X-Received: by 2002:a37:508:: with SMTP id 8mr19844940qkf.265.1587933763946; Sun, 26 Apr 2020 13:42:43 -0700 (PDT) Received: from gallifrey.lan ([201.82.186.200]) by smtp.gmail.com with ESMTPSA id m7sm8321858qke.124.2020.04.26.13.42.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Apr 2020 13:42:43 -0700 (PDT) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [bionic:linux-azure-4.15][PATCH 5/5] PCI: hv: Use bytes 4 and 5 from instance ID as the PCI domain numbers Date: Sun, 26 Apr 2020 17:42:29 -0300 Message-Id: <20200426204229.119093-6-marcelo.cerri@canonical.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200426204229.119093-1-marcelo.cerri@canonical.com> References: <20200426203646.115503-1-marcelo.cerri@canonical.com> <20200426204229.119093-1-marcelo.cerri@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Haiyang Zhang BugLink: https://bugs.launchpad.net/bugs/1867220 As recommended by Azure host team, the bytes 4, 5 have more uniqueness (info entropy) than bytes 8, 9 so use them as the PCI domain numbers. On older hosts, bytes 4, 5 can also be used -- no backward compatibility issues are introduced and the chance of collision is greatly reduced. In the rare cases of collision, the driver code detects and finds another number that is not in use. Suggested-by: Michael Kelley Signed-off-by: Haiyang Zhang Signed-off-by: Lorenzo Pieralisi Acked-by: Sasha Levin (backported from commit f73f8a504e27959576a2f4d85182202561e426f2) [marcelo.cerri@canonical.com: basically a clean cherry-pick, but the changes from drivers/pci/controller/pci-hyperv.c had to be applied to drivers/pci/host/pci-hyperv.c instead] Signed-off-by: Marcelo Henrique Cerri --- drivers/pci/host/pci-hyperv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c index c414255d2ae6..81da709aa757 100644 --- a/drivers/pci/host/pci-hyperv.c +++ b/drivers/pci/host/pci-hyperv.c @@ -2632,7 +2632,7 @@ static int hv_pci_probe(struct hv_device *hdev, * (2) There will be no overlap between domains (after fixing possible * collisions) in the same VM. */ - dom_req = hdev->dev_instance.b[8] << 8 | hdev->dev_instance.b[9]; + dom_req = hdev->dev_instance.b[5] << 8 | hdev->dev_instance.b[4]; dom = hv_get_dom_num(dom_req); if (dom == HVPCI_DOM_INVALID) {