Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/2219419/?format=api
{ "id": 2219419, "url": "http://patchwork.ozlabs.org/api/patches/2219419/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-pci/patch/20260402234313.2490779-1-decui@microsoft.com/", "project": { "id": 28, "url": "http://patchwork.ozlabs.org/api/projects/28/?format=api", "name": "Linux PCI development", "link_name": "linux-pci", "list_id": "linux-pci.vger.kernel.org", "list_email": "linux-pci@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20260402234313.2490779-1-decui@microsoft.com>", "list_archive_url": null, "date": "2026-04-02T23:43:13", "name": "[v2] PCI: hv: Allocate MMIO from above 4GB for the config window", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "5d7182320ab706feeaf7d95460e6f0f4264f2b62", "submitter": { "id": 64601, "url": "http://patchwork.ozlabs.org/api/people/64601/?format=api", "name": "Dexuan Cui", "email": "decui@microsoft.com" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/linux-pci/patch/20260402234313.2490779-1-decui@microsoft.com/mbox/", "series": [ { "id": 498565, "url": "http://patchwork.ozlabs.org/api/series/498565/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-pci/list/?series=498565", "date": "2026-04-02T23:43:13", "name": "[v2] PCI: hv: Allocate MMIO from above 4GB for the config window", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/498565/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2219419/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2219419/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "\n <linux-pci+bounces-51792-incoming=patchwork.ozlabs.org@vger.kernel.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-pci@vger.kernel.org" ], "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-51792-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)", "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=13.77.154.182", "smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=microsoft.com", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.microsoft.com" ], "Received": [ "from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fmz306rlXz1yCs\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 03 Apr 2026 10:44:12 +1100 (AEDT)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 3EBC83013FC0\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 2 Apr 2026 23:44:09 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id D1D8F3876C7;\n\tThu, 2 Apr 2026 23:44:07 +0000 (UTC)", "from linux.microsoft.com (linux.microsoft.com [13.77.154.182])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 8BBD236B043;\n\tThu, 2 Apr 2026 23:44:06 +0000 (UTC)", "by linux.microsoft.com (Postfix, from userid 1009)\n\tid A64F420B7001; Thu, 2 Apr 2026 16:44:06 -0700 (PDT)" ], "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775173447; cv=none;\n b=RhCPKo/BdFXkGGVKBuZ6xqOj6FzzQNw4tIh2AQss6qNeuyDrOOGiywk4YyjgEQy722dKQTN0l1+Ipaucs7TgrmBuknjpsM1cImAUY8chaCrVhSIgHhIQB6ychYz6CrusFE4WakbTEbCgOzWZbDfSjlKf8dXC1QM3EwTH/z2LrII=", "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775173447; c=relaxed/simple;\n\tbh=t3GTXZP+Qx6sXooMZV8eBLTayxLudqq1llwsAayvvpU=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version;\n b=eRwaH7jFqLEs7FIb4Yl8OrzEjywMPAvm8WVcDDoL5JWmJ/Oi7ZViW1XmSHLpa4ejKo3LPjSx8ODi4K0KOsluvzkRVbIBLXqx5esqmk/FN/zWNtKYUdeRBy/TR++HvAF/60PTkon/8V2f1xuRGDHNrAKlX00jy+ccEqE2rcHFdoI=", "ARC-Authentication-Results": "i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=microsoft.com;\n spf=pass smtp.mailfrom=linux.microsoft.com;\n arc=none smtp.client-ip=13.77.154.182", "DKIM-Filter": "OpenDKIM Filter v2.11.0 linux.microsoft.com A64F420B7001", "From": "Dexuan Cui <decui@microsoft.com>", "To": "kys@microsoft.com,\n\thaiyangz@microsoft.com,\n\twei.liu@kernel.org,\n\tdecui@microsoft.com,\n\tlongli@microsoft.com,\n\tlpieralisi@kernel.org,\n\tkwilczynski@kernel.org,\n\tmani@kernel.org,\n\trobh@kernel.org,\n\tbhelgaas@google.com,\n\tjakeo@microsoft.com,\n\tlinux-hyperv@vger.kernel.org,\n\tlinux-pci@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org,\n\tmhklinux@outlook.com,\n\tmatthew.ruffell@canonical.com,\n\tkjlx@templeofstupid.com", "Cc": "Krister Johansen <johansen@templeofstupid.com>,\n\tstable@vger.kernel.org", "Subject": "[PATCH v2] PCI: hv: Allocate MMIO from above 4GB for the config\n window", "Date": "Thu, 2 Apr 2026 16:43:13 -0700", "Message-ID": "<20260402234313.2490779-1-decui@microsoft.com>", "X-Mailer": "git-send-email 2.43.7", "Precedence": "bulk", "X-Mailing-List": "linux-pci@vger.kernel.org", "List-Id": "<linux-pci.vger.kernel.org>", "List-Subscribe": "<mailto:linux-pci+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-pci+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit" }, "content": "There has been a longstanding MMIO conflict between the pci_hyperv\ndriver's config_window (see hv_allocate_config_window()) and the\nhyperv_drm (or hyperv_fb) driver (see hyperv_setup_vram()): typically\nboth get MMIO from the low MMIO range below 4GB; this is not an issue\nin the normal kernel since the VMBus driver reserves the framebuffer\nMMIO range in vmbus_reserve_fb(), so the drm driver's hyperv_setup_vram()\ncan always get the reserved framebuffer MMIO; however, a Gen2 VM's\nkdump kernel can fail to reserve the framebuffer MMIO in\nvmbus_reserve_fb() because the screen_info.lfb_base is zero in the\nkdump kernel due to several possible reasons (see the Link below for\nmore details):\n\n1) on ARM64, the two syscalls (KEXEC_LOAD, KEXEC_FILE_LOAD) don't\ninitialize the screen_info.lfb_base for the kdump kernel;\n\n2) on x86-64, the KEXEC_FILE_LOAD syscall initializes kdump kernel's\nscreen_info.lfb_base, but the KEXEC_LOAD syscall doesn't really do that\nwhen the hyperv_drm driver loads, because the user-space kexec-tools\n(i.e. the program 'kexec') doesn't recognize the hyperv_drm driver\n(let's ignore the behavior of kexec-tools of very old versions).\n\nWhen vmbus_reserve_fb() fails to reserve the framebuffer MMIO in the\nkdump kernel, if pci_hyperv in the kdump kernel loads before hyperv_drm\nloads, pci_hyperv's vmbus_allocate_mmio() gets the framebuffer MMIO\nand tries to use it, but since the host thinks that the MMIO range is\nstill in use by hyperv_drm, the host refuses to accept the MMIO range\nas the config window, and pci_hyperv's hv_pci_enter_d0() errors out,\ne.g. an error can be \"PCI Pass-through VSP failed D0 Entry with status\nc0370048\".\n\nTypically, this pci_hyperv error in the kdump kernel was not fatal in\nthe past because the kdump kernel typically doesn't rely on pci_hyperv,\ni.e. the root file system is on a VMBus SCSI device.\n\nNow, a VM on Azure can boot from NVMe, i.e. the root file system can be\non a NVMe device, which depends on pci_hyperv. When the error occurs,\nthe kdump kernel fails to boot up since no root file system is detected.\n\nFix the MMIO conflict by allocating MMIO above 4GB for the config_window,\nso it won't conflict with hyperv_drm's MMIO, which should be below the\n4GB boundary. The size of config_window is small: it's only 8KB per PCI\ndevice, so there should be sufficient MMIO space available above 4GB.\n\nNote: we still need to figure out how to address the possible MMIO\nconflict between hyperv_drm and pci_hyperv in the case of 32-bit PCI\nMMIO BARs, but that's of low priority because all PCI devices available\nto a Linux VM on Azure or on a modern host should use 64-bit BARs and\nshould not use 32-bit BARs -- I checked Mellanox VFs, MANA VFs, NVMe\ndevices, and GPUs in Linux VMs on Azure, and found no 32-bit BARs.\n\nFixes: 4daace0d8ce8 (\"PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs\")\nLink: https://lore.kernel.org/all/SA1PR21MB692176C1BC53BFC9EAE5CF8EBF51A@SA1PR21MB6921.namprd21.prod.outlook.com/\nTested-by: Matthew Ruffell <matthew.ruffell@canonical.com>\nTested-by: Krister Johansen <johansen@templeofstupid.com>\nSigned-off-by: Dexuan Cui <decui@microsoft.com>\nCc: stable@vger.kernel.org\n---\n\nChanges since v1:\n Updated the commit message and the comment to better explain\n why screen_info.lfb_base can be 0 in the kdump kernel.\n\n No code change since v1.\n\n\n drivers/pci/controller/pci-hyperv.c | 21 +++++++++++++++++++--\n 1 file changed, 19 insertions(+), 2 deletions(-)", "diff": "diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c\nindex 2c7a406b4ba8..1a79334ea9f4 100644\n--- a/drivers/pci/controller/pci-hyperv.c\n+++ b/drivers/pci/controller/pci-hyperv.c\n@@ -3403,9 +3403,26 @@ static int hv_allocate_config_window(struct hv_pcibus_device *hbus)\n \n \t/*\n \t * Set up a region of MMIO space to use for accessing configuration\n-\t * space.\n+\t * space. Use the high MMIO range to not conflict with the hyperv_drm\n+\t * driver (which normally gets MMIO from the low MMIO range) in the\n+\t * kdump kernel of a Gen2 VM, which may fail to reserve the framebuffer\n+\t * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being\n+\t * zero in the kdump kernel:\n+\t *\n+\t * on ARM64, the two syscalls (KEXEC_LOAD, KEXEC_FILE_LOAD) don't\n+\t * initialize the screen_info.lfb_base for the kdump kernel;\n+\t *\n+\t * on x86-64, the KEXEC_FILE_LOAD syscall initializes kdump kernel's\n+\t * screen_info.lfb_base (see bzImage64_load() -> setup_boot_parameters())\n+\t * but the KEXEC_LOAD syscall doesn't really do that when the hyperv_drm\n+\t * driver loads, because the user-space program 'kexec' doesn't\n+\t * recognize hyperv_drm: see the function setup_linux_vesafb() in the\n+\t * kexec-tools.git repo. Note: old versions of kexec-tools, e.g.\n+\t * v2.0.18, initialize screen_info.lfb_base if the hyperv_fb driver\n+\t * loads, but hyperv_fb is deprecated and has been removed from the\n+\t * mainline kernel.\n \t */\n-\tret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,\n+\tret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,\n \t\t\t\t PCI_CONFIG_MMIO_LENGTH, 0x1000, false);\n \tif (ret)\n \t\treturn ret;\n", "prefixes": [ "v2" ] }