{"id":2226036,"url":"http://patchwork.ozlabs.org/api/1.2/patches/2226036/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-pci/patch/20260422023239.1171963-9-mrathor@linux.microsoft.com/","project":{"id":28,"url":"http://patchwork.ozlabs.org/api/1.2/projects/28/?format=json","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":"<20260422023239.1171963-9-mrathor@linux.microsoft.com>","list_archive_url":null,"date":"2026-04-22T02:32:34","name":"[V1,08/13] PCI: hv: rename hv_compose_msi_msg to hv_vmbus_compose_msi_msg","commit_ref":null,"pull_url":null,"state":"new","archived":false,"hash":"6bf8cd2f363fa4f2144a8a9eb6316fcf4cf2d515","submitter":{"id":91512,"url":"http://patchwork.ozlabs.org/api/1.2/people/91512/?format=json","name":"Mukesh R","email":"mrathor@linux.microsoft.com"},"delegate":null,"mbox":"http://patchwork.ozlabs.org/project/linux-pci/patch/20260422023239.1171963-9-mrathor@linux.microsoft.com/mbox/","series":[{"id":500915,"url":"http://patchwork.ozlabs.org/api/1.2/series/500915/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-pci/list/?series=500915","date":"2026-04-22T02:32:26","name":"PCI passthru on Hyper-V (Part I)","version":1,"mbox":"http://patchwork.ozlabs.org/series/500915/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/patches/2226036/comments/","check":"pending","checks":"http://patchwork.ozlabs.org/api/patches/2226036/checks/","tags":{},"related":[],"headers":{"Return-Path":"\n ","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\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.microsoft.com header.i=@linux.microsoft.com\n header.a=rsa-sha256 header.s=default header.b=Pc0TBr6d;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52904-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=linux.microsoft.com\n header.i=@linux.microsoft.com header.b=\"Pc0TBr6d\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=13.77.154.182","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.microsoft.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.microsoft.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::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 4g0k6r5Dnkz1yGs\n\tfor ; Wed, 22 Apr 2026 12:43:16 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 92BF430911F1\n\tfor ; Wed, 22 Apr 2026 02:34:59 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 6D6163909AB;\n\tWed, 22 Apr 2026 02:34:09 +0000 (UTC)","from linux.microsoft.com (linux.microsoft.com [13.77.154.182])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 7F6F438737F;\n\tWed, 22 Apr 2026 02:33:52 +0000 (UTC)","from mrdev.corp.microsoft.com\n (192-184-212-33.fiber.dynamic.sonic.net [192.184.212.33])\n\tby linux.microsoft.com (Postfix) with ESMTPSA id 7D62C20B6F01;\n\tTue, 21 Apr 2026 19:33:47 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776825244; cv=none;\n b=bdlkaatiBgs1X0SuKsjs6nJO4S3d5Ke7ky8iWs/PCR7y/im9AktI7ATXgKEPdgniGvgC07v0uXupIbzmdBSiR59TuPS0tFphwmcoM7x+xUpriw9QlW2z+MYbYl7dTcOaHHLdFvN3+p6EuZhBCXSuOFbIGw0toucFi3pJUDHsfEM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776825244; c=relaxed/simple;\n\tbh=3p+UYzYAVK6Oc1T3Ui1NuwCE4yM8MDdRlrXl61kkDDE=;\n\th=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:\n\t MIME-Version;\n b=OrNBcvrSWcmI5ejHh0qN+42OOBIdPjWI1BVOT5HvQR+5VS8I7dofSSW+5x9sdKB+UuLefOqeoGOOgIbxJxWZQGAu5GpAGIkElfBoMXaUME3AIRqAoMJ71eEBQjeRH2AvFDffjaMcacbdSR/RbcWsXEisVfxl3DMXANGR7SPqnT0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.microsoft.com;\n spf=pass smtp.mailfrom=linux.microsoft.com;\n dkim=pass (1024-bit key) header.d=linux.microsoft.com\n header.i=@linux.microsoft.com header.b=Pc0TBr6d;\n arc=none smtp.client-ip=13.77.154.182","DKIM-Filter":"OpenDKIM Filter v2.11.0 linux.microsoft.com 7D62C20B6F01","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;\n\ts=default; t=1776825228;\n\tbh=o6ztznKN0i+oDxkVKgM3YRDnCNaOjwDWRVoXxAfAsww=;\n\th=From:To:Cc:Subject:Date:In-Reply-To:References:From;\n\tb=Pc0TBr6dRCkXuecEpzOQW9DZK1BlT8DoPhItNDPwLPiilJpMdJ46A+h4qz0zVtPMs\n\t m7eaU3/0fYsOx5Fo+aJzdGgMUH4F5VTXRLhFPExrpYpbyDUWJi3Wxr8+M1gkoHtj6O\n\t /TaNasCwXiWRoz8aGA8N8ODVTgf6l41putV/KTAA=","From":"Mukesh R ","To":"hpa@zytor.com,\n\trobin.murphy@arm.com,\n\trobh@kernel.org,\n\twei.liu@kernel.org,\n\tmrathor@linux.microsoft.com,\n\tmhklinux@outlook.com,\n\tmuislam@microsoft.com,\n\tnamjain@linux.microsoft.com,\n\tmagnuskulke@linux.microsoft.com,\n\tanbelski@linux.microsoft.com,\n\tlinux-kernel@vger.kernel.org,\n\tlinux-hyperv@vger.kernel.org,\n\tiommu@lists.linux.dev,\n\tlinux-pci@vger.kernel.org,\n\tlinux-arch@vger.kernel.org","Cc":"kys@microsoft.com,\n\thaiyangz@microsoft.com,\n\tdecui@microsoft.com,\n\tlongli@microsoft.com,\n\ttglx@kernel.org,\n\tmingo@redhat.com,\n\tbp@alien8.de,\n\tdave.hansen@linux.intel.com,\n\tx86@kernel.org,\n\tjoro@8bytes.org,\n\twill@kernel.org,\n\tlpieralisi@kernel.org,\n\tkwilczynski@kernel.org,\n\tbhelgaas@google.com,\n\tarnd@arndb.de","Subject":"[PATCH V1 08/13] PCI: hv: rename hv_compose_msi_msg to\n hv_vmbus_compose_msi_msg","Date":"Tue, 21 Apr 2026 19:32:34 -0700","Message-ID":"<20260422023239.1171963-9-mrathor@linux.microsoft.com>","X-Mailer":"git-send-email 2.51.2.vfs.0.1","In-Reply-To":"<20260422023239.1171963-1-mrathor@linux.microsoft.com>","References":"<20260422023239.1171963-1-mrathor@linux.microsoft.com>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Transfer-Encoding":"8bit"},"content":"Main change here is to rename hv_compose_msi_msg to\nhv_vmbus_compose_msi_msg as we introduce hv_compose_msi_msg in upcoming\npatches that builds MSI messages for both VMBus and non-VMBus cases. VMBus\nis not used on baremetal root partition for example. While at it, replace\nspaces with tabs and fix some formatting involving excessive line wraps.\n\nThere is no functional change.\n\nSigned-off-by: Mukesh R \n---\n drivers/pci/controller/pci-hyperv.c | 95 +++++++++++++++--------------\n 1 file changed, 48 insertions(+), 47 deletions(-)","diff":"diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c\nindex cfc8fa403dad..ed6b399afc80 100644\n--- a/drivers/pci/controller/pci-hyperv.c\n+++ b/drivers/pci/controller/pci-hyperv.c\n@@ -30,7 +30,7 @@\n * function's configuration space is zero.\n *\n * The rest of this driver mostly maps PCI concepts onto underlying Hyper-V\n- * facilities. For instance, the configuration space of a function exposed\n+ * facilities.\tFor instance, the configuration space of a function exposed\n * by Hyper-V is mapped into a single page of memory space, and the\n * read and write handlers for config space must be aware of this mechanism.\n * Similarly, device setup and teardown involves messages sent to and from\n@@ -109,33 +109,33 @@ enum pci_message_type {\n \t/*\n \t * Version 1.1\n \t */\n-\tPCI_MESSAGE_BASE = 0x42490000,\n-\tPCI_BUS_RELATIONS = PCI_MESSAGE_BASE + 0,\n-\tPCI_QUERY_BUS_RELATIONS = PCI_MESSAGE_BASE + 1,\n-\tPCI_POWER_STATE_CHANGE = PCI_MESSAGE_BASE + 4,\n+\tPCI_MESSAGE_BASE\t\t= 0x42490000,\n+\tPCI_BUS_RELATIONS\t\t= PCI_MESSAGE_BASE + 0,\n+\tPCI_QUERY_BUS_RELATIONS\t\t= PCI_MESSAGE_BASE + 1,\n+\tPCI_POWER_STATE_CHANGE\t\t= PCI_MESSAGE_BASE + 4,\n \tPCI_QUERY_RESOURCE_REQUIREMENTS = PCI_MESSAGE_BASE + 5,\n-\tPCI_QUERY_RESOURCE_RESOURCES = PCI_MESSAGE_BASE + 6,\n-\tPCI_BUS_D0ENTRY = PCI_MESSAGE_BASE + 7,\n-\tPCI_BUS_D0EXIT = PCI_MESSAGE_BASE + 8,\n-\tPCI_READ_BLOCK = PCI_MESSAGE_BASE + 9,\n-\tPCI_WRITE_BLOCK = PCI_MESSAGE_BASE + 0xA,\n-\tPCI_EJECT = PCI_MESSAGE_BASE + 0xB,\n-\tPCI_QUERY_STOP = PCI_MESSAGE_BASE + 0xC,\n-\tPCI_REENABLE = PCI_MESSAGE_BASE + 0xD,\n-\tPCI_QUERY_STOP_FAILED = PCI_MESSAGE_BASE + 0xE,\n-\tPCI_EJECTION_COMPLETE = PCI_MESSAGE_BASE + 0xF,\n-\tPCI_RESOURCES_ASSIGNED = PCI_MESSAGE_BASE + 0x10,\n-\tPCI_RESOURCES_RELEASED = PCI_MESSAGE_BASE + 0x11,\n-\tPCI_INVALIDATE_BLOCK = PCI_MESSAGE_BASE + 0x12,\n-\tPCI_QUERY_PROTOCOL_VERSION = PCI_MESSAGE_BASE + 0x13,\n-\tPCI_CREATE_INTERRUPT_MESSAGE = PCI_MESSAGE_BASE + 0x14,\n-\tPCI_DELETE_INTERRUPT_MESSAGE = PCI_MESSAGE_BASE + 0x15,\n+\tPCI_QUERY_RESOURCE_RESOURCES\t= PCI_MESSAGE_BASE + 6,\n+\tPCI_BUS_D0ENTRY\t\t\t= PCI_MESSAGE_BASE + 7,\n+\tPCI_BUS_D0EXIT\t\t\t= PCI_MESSAGE_BASE + 8,\n+\tPCI_READ_BLOCK\t\t\t= PCI_MESSAGE_BASE + 9,\n+\tPCI_WRITE_BLOCK\t\t\t= PCI_MESSAGE_BASE + 0xA,\n+\tPCI_EJECT\t\t\t= PCI_MESSAGE_BASE + 0xB,\n+\tPCI_QUERY_STOP\t\t\t= PCI_MESSAGE_BASE + 0xC,\n+\tPCI_REENABLE\t\t\t= PCI_MESSAGE_BASE + 0xD,\n+\tPCI_QUERY_STOP_FAILED\t\t= PCI_MESSAGE_BASE + 0xE,\n+\tPCI_EJECTION_COMPLETE\t\t= PCI_MESSAGE_BASE + 0xF,\n+\tPCI_RESOURCES_ASSIGNED\t\t= PCI_MESSAGE_BASE + 0x10,\n+\tPCI_RESOURCES_RELEASED\t\t= PCI_MESSAGE_BASE + 0x11,\n+\tPCI_INVALIDATE_BLOCK\t\t= PCI_MESSAGE_BASE + 0x12,\n+\tPCI_QUERY_PROTOCOL_VERSION\t= PCI_MESSAGE_BASE + 0x13,\n+\tPCI_CREATE_INTERRUPT_MESSAGE\t= PCI_MESSAGE_BASE + 0x14,\n+\tPCI_DELETE_INTERRUPT_MESSAGE\t= PCI_MESSAGE_BASE + 0x15,\n \tPCI_RESOURCES_ASSIGNED2\t\t= PCI_MESSAGE_BASE + 0x16,\n \tPCI_CREATE_INTERRUPT_MESSAGE2\t= PCI_MESSAGE_BASE + 0x17,\n \tPCI_DELETE_INTERRUPT_MESSAGE2\t= PCI_MESSAGE_BASE + 0x18, /* unused */\n \tPCI_BUS_RELATIONS2\t\t= PCI_MESSAGE_BASE + 0x19,\n-\tPCI_RESOURCES_ASSIGNED3 = PCI_MESSAGE_BASE + 0x1A,\n-\tPCI_CREATE_INTERRUPT_MESSAGE3 = PCI_MESSAGE_BASE + 0x1B,\n+\tPCI_RESOURCES_ASSIGNED3\t\t= PCI_MESSAGE_BASE + 0x1A,\n+\tPCI_CREATE_INTERRUPT_MESSAGE3\t= PCI_MESSAGE_BASE + 0x1B,\n \tPCI_MESSAGE_MAXIMUM\n };\n \n@@ -1774,20 +1774,21 @@ static u32 hv_compose_msi_req_v1(\n * via the HVCALL_RETARGET_INTERRUPT hypercall. But the choice of dummy vCPU is\n * not irrelevant because Hyper-V chooses the physical CPU to handle the\n * interrupts based on the vCPU specified in message sent to the vPCI VSP in\n- * hv_compose_msi_msg(). Hyper-V's choice of pCPU is not visible to the guest,\n- * but assigning too many vPCI device interrupts to the same pCPU can cause a\n- * performance bottleneck. So we spread out the dummy vCPUs to influence Hyper-V\n- * to spread out the pCPUs that it selects.\n+ * hv_vmbus_compose_msi_msg(). Hyper-V's choice of pCPU is not visible to the\n+ * guest, but assigning too many vPCI device interrupts to the same pCPU can\n+ * cause a performance bottleneck. So we spread out the dummy vCPUs to influence\n+ * Hyper-V to spread out the pCPUs that it selects.\n *\n * For the single-MSI and MSI-X cases, it's OK for hv_compose_msi_req_get_cpu()\n * to always return the same dummy vCPU, because a second call to\n- * hv_compose_msi_msg() contains the \"real\" vCPU, causing Hyper-V to choose a\n- * new pCPU for the interrupt. But for the multi-MSI case, the second call to\n- * hv_compose_msi_msg() exits without sending a message to the vPCI VSP, so the\n- * original dummy vCPU is used. This dummy vCPU must be round-robin'ed so that\n- * the pCPUs are spread out. All interrupts for a multi-MSI device end up using\n- * the same pCPU, even though the vCPUs will be spread out by later calls\n- * to hv_irq_unmask(), but that is the best we can do now.\n+ * hv_vmbus_compose_msi_msg() contains the \"real\" vCPU, causing Hyper-V to\n+ * choose a new pCPU for the interrupt. But for the multi-MSI case, the second\n+ * call to hv_vmbus_compose_msi_msg() exits without sending a message to the\n+ * vPCI VSP, so the original dummy vCPU is used. This dummy vCPU must be\n+ * round-robin'ed so that the pCPUs are spread out. All interrupts for a\n+ * multi-MSI device end up using the same pCPU, even though the vCPUs will be\n+ * spread out by later calls to hv_irq_unmask(), but that is the best we can do\n+ * now.\n *\n * With Hyper-V in Nov 2022, the HVCALL_RETARGET_INTERRUPT hypercall does *not*\n * cause Hyper-V to reselect the pCPU based on the specified vCPU. Such an\n@@ -1862,7 +1863,7 @@ static u32 hv_compose_msi_req_v3(\n }\n \n /**\n- * hv_compose_msi_msg() - Supplies a valid MSI address/data\n+ * hv_vmbus_compose_msi_msg() - Supplies a valid MSI address/data\n * @data:\tEverything about this MSI\n * @msg:\tBuffer that is filled in by this function\n *\n@@ -1872,7 +1873,7 @@ static u32 hv_compose_msi_req_v3(\n * response supplies a data value and address to which that data\n * should be written to trigger that interrupt.\n */\n-static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)\n+static void hv_vmbus_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)\n {\n \tstruct hv_pcibus_device *hbus;\n \tstruct vmbus_channel *channel;\n@@ -1954,7 +1955,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)\n \t\t\treturn;\n \t\t}\n \t\t/*\n-\t\t * The vector we select here is a dummy value. The correct\n+\t\t * The vector we select here is a dummy value.\tThe correct\n \t\t * value gets sent to the hypervisor in unmask(). This needs\n \t\t * to be aligned with the count, and also not zero. Multi-msi\n \t\t * is powers of 2 up to 32, so 32 will always work here.\n@@ -2046,7 +2047,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)\n \n \t\t/*\n \t\t * Make sure that the ring buffer data structure doesn't get\n-\t\t * freed while we dereference the ring buffer pointer. Test\n+\t\t * freed while we dereference the ring buffer pointer.\tTest\n \t\t * for the channel's onchannel_callback being NULL within a\n \t\t * sched_lock critical section. See also the inline comments\n \t\t * in vmbus_reset_channel_cb().\n@@ -2146,7 +2147,7 @@ static const struct msi_parent_ops hv_pcie_msi_parent_ops = {\n /* HW Interrupt Chip Descriptor */\n static struct irq_chip hv_msi_irq_chip = {\n \t.name\t\t\t= \"Hyper-V PCIe MSI\",\n-\t.irq_compose_msi_msg\t= hv_compose_msi_msg,\n+\t.irq_compose_msi_msg\t= hv_vmbus_compose_msi_msg,\n \t.irq_set_affinity\t= irq_chip_set_affinity_parent,\n \t.irq_ack\t\t= irq_chip_ack_parent,\n \t.irq_eoi\t\t= irq_chip_eoi_parent,\n@@ -2158,8 +2159,8 @@ static int hv_pcie_domain_alloc(struct irq_domain *d, unsigned int virq, unsigne\n \t\t\t void *arg)\n {\n \t/*\n-\t * TODO: Allocating and populating struct tran_int_desc in hv_compose_msi_msg()\n-\t * should be moved here.\n+\t * TODO: Allocating and populating struct tran_int_desc in\n+\t *\t hv_vmbus_compose_msi_msg() should be moved here.\n \t */\n \tint ret;\n \n@@ -2226,7 +2227,7 @@ static int hv_pcie_init_irq_domain(struct hv_pcibus_device *hbus)\n /**\n * get_bar_size() - Get the address space consumed by a BAR\n * @bar_val:\tValue that a BAR returned after -1 was written\n- * to it.\n+ *\t\tto it.\n *\n * This function returns the size of the BAR, rounded up to 1\n * page. It has to be rounded up because the hypervisor's page\n@@ -2580,7 +2581,7 @@ static void q_resource_requirements(void *context, struct pci_response *resp,\n * new_pcichild_device() - Create a new child device\n * @hbus:\tThe internal struct tracking this root PCI bus.\n * @desc:\tThe information supplied so far from the host\n- * about the device.\n+ *\t\tabout the device.\n *\n * This function creates the tracking structure for a new child\n * device and kicks off the process of figuring out what it is.\n@@ -3105,7 +3106,7 @@ static void hv_pci_onchannelcallback(void *context)\n \t\t\t * sure that the packet pointer is still valid during the call:\n \t\t\t * here 'valid' means that there's a task still waiting for the\n \t\t\t * completion, and that the packet data is still on the waiting\n-\t\t\t * task's stack. Cf. hv_compose_msi_msg().\n+\t\t\t * task's stack. Cf. hv_vmbus_compose_msi_msg().\n \t\t\t */\n \t\t\tcomp_packet->completion_func(comp_packet->compl_ctxt,\n \t\t\t\t\t\t response,\n@@ -3422,7 +3423,7 @@ static int hv_allocate_config_window(struct hv_pcibus_device *hbus)\n \t * vmbus_allocate_mmio() gets used for allocating both device endpoint\n \t * resource claims (those which cannot be overlapped) and the ranges\n \t * which are valid for the children of this bus, which are intended\n-\t * to be overlapped by those children. Set the flag on this claim\n+\t * to be overlapped by those children.\tSet the flag on this claim\n \t * meaning that this region can't be overlapped.\n \t */\n \n@@ -4069,7 +4070,7 @@ static int hv_pci_restore_msi_msg(struct pci_dev *pdev, void *arg)\n \t\tirq_data = irq_get_irq_data(entry->irq);\n \t\tif (WARN_ON_ONCE(!irq_data))\n \t\t\treturn -EINVAL;\n-\t\thv_compose_msi_msg(irq_data, &entry->msg);\n+\t\thv_vmbus_compose_msi_msg(irq_data, &entry->msg);\n \t}\n \treturn 0;\n }\n@@ -4077,7 +4078,7 @@ static int hv_pci_restore_msi_msg(struct pci_dev *pdev, void *arg)\n /*\n * Upon resume, pci_restore_msi_state() -> ... -> __pci_write_msi_msg()\n * directly writes the MSI/MSI-X registers via MMIO, but since Hyper-V\n- * doesn't trap and emulate the MMIO accesses, here hv_compose_msi_msg()\n+ * doesn't trap and emulate the MMIO accesses, here hv_vmbus_compose_msi_msg()\n * must be used to ask Hyper-V to re-create the IOMMU Interrupt Remapping\n * Table entries.\n */\n","prefixes":["V1","08/13"]}