Message-ID: <vvxvn53hffoh6w4lkpfnwaenmz4nib3tbolvnxcggperdtamdl@j7d6ub75r7d4>
Date: Wed, 28 Jan 2026 19:33:57 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Mukesh R <mrathor@...ux.microsoft.com>
Cc: linux-kernel@...r.kernel.org, linux-hyperv@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev, linux-pci@...r.kernel.org, 
	linux-arch@...r.kernel.org, kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org, 
	decui@...rosoft.com, longli@...rosoft.com, catalin.marinas@....com, will@...nel.org, 
	tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, 
	hpa@...or.com, joro@...tes.org, lpieralisi@...nel.org, kwilczynski@...nel.org, 
	robh@...nel.org, bhelgaas@...gle.com, arnd@...db.de, 
	nunodasneves@...ux.microsoft.com, mhklinux@...look.com, romank@...ux.microsoft.com
Subject: Re: [PATCH v0 08/15] PCI: hv: rename hv_compose_msi_msg to
 hv_vmbus_compose_msi_msg

On Mon, Jan 19, 2026 at 10:42:23PM -0800, Mukesh R wrote:
> From: Mukesh Rathor <mrathor@...ux.microsoft.com>
> 
> Main change here is to rename hv_compose_msi_msg to
> hv_vmbus_compose_msi_msg as we introduce hv_compose_msi_msg in upcoming
> patches that builds MSI messages for both VMBus and non-VMBus cases. VMBus
> is not used on baremetal root partition for example.

> While at it, replace
> spaces with tabs and fix some formatting involving excessive line wraps.
>

Don't mix up cleanup changes. Do it in a separate patch.

- Mani
 
> There is no functional change.
> 
> Signed-off-by: Mukesh Rathor <mrathor@...ux.microsoft.com>
> ---
>  drivers/pci/controller/pci-hyperv.c | 95 +++++++++++++++--------------
>  1 file changed, 48 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index 1e237d3538f9..8bc6a38c9b5a 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -30,7 +30,7 @@
>   * function's configuration space is zero.
>   *
>   * The rest of this driver mostly maps PCI concepts onto underlying Hyper-V
> - * facilities.  For instance, the configuration space of a function exposed
> + * facilities.	For instance, the configuration space of a function exposed
>   * by Hyper-V is mapped into a single page of memory space, and the
>   * read and write handlers for config space must be aware of this mechanism.
>   * Similarly, device setup and teardown involves messages sent to and from
> @@ -109,33 +109,33 @@ enum pci_message_type {
>  	/*
>  	 * Version 1.1
>  	 */
> -	PCI_MESSAGE_BASE                = 0x42490000,
> -	PCI_BUS_RELATIONS               = PCI_MESSAGE_BASE + 0,
> -	PCI_QUERY_BUS_RELATIONS         = PCI_MESSAGE_BASE + 1,
> -	PCI_POWER_STATE_CHANGE          = PCI_MESSAGE_BASE + 4,
> +	PCI_MESSAGE_BASE		= 0x42490000,
> +	PCI_BUS_RELATIONS		= PCI_MESSAGE_BASE + 0,
> +	PCI_QUERY_BUS_RELATIONS		= PCI_MESSAGE_BASE + 1,
> +	PCI_POWER_STATE_CHANGE		= PCI_MESSAGE_BASE + 4,
>  	PCI_QUERY_RESOURCE_REQUIREMENTS = PCI_MESSAGE_BASE + 5,
> -	PCI_QUERY_RESOURCE_RESOURCES    = PCI_MESSAGE_BASE + 6,
> -	PCI_BUS_D0ENTRY                 = PCI_MESSAGE_BASE + 7,
> -	PCI_BUS_D0EXIT                  = PCI_MESSAGE_BASE + 8,
> -	PCI_READ_BLOCK                  = PCI_MESSAGE_BASE + 9,
> -	PCI_WRITE_BLOCK                 = PCI_MESSAGE_BASE + 0xA,
> -	PCI_EJECT                       = PCI_MESSAGE_BASE + 0xB,
> -	PCI_QUERY_STOP                  = PCI_MESSAGE_BASE + 0xC,
> -	PCI_REENABLE                    = PCI_MESSAGE_BASE + 0xD,
> -	PCI_QUERY_STOP_FAILED           = PCI_MESSAGE_BASE + 0xE,
> -	PCI_EJECTION_COMPLETE           = PCI_MESSAGE_BASE + 0xF,
> -	PCI_RESOURCES_ASSIGNED          = PCI_MESSAGE_BASE + 0x10,
> -	PCI_RESOURCES_RELEASED          = PCI_MESSAGE_BASE + 0x11,
> -	PCI_INVALIDATE_BLOCK            = PCI_MESSAGE_BASE + 0x12,
> -	PCI_QUERY_PROTOCOL_VERSION      = PCI_MESSAGE_BASE + 0x13,
> -	PCI_CREATE_INTERRUPT_MESSAGE    = PCI_MESSAGE_BASE + 0x14,
> -	PCI_DELETE_INTERRUPT_MESSAGE    = PCI_MESSAGE_BASE + 0x15,
> +	PCI_QUERY_RESOURCE_RESOURCES	= PCI_MESSAGE_BASE + 6,
> +	PCI_BUS_D0ENTRY			= PCI_MESSAGE_BASE + 7,
> +	PCI_BUS_D0EXIT			= PCI_MESSAGE_BASE + 8,
> +	PCI_READ_BLOCK			= PCI_MESSAGE_BASE + 9,
> +	PCI_WRITE_BLOCK			= PCI_MESSAGE_BASE + 0xA,
> +	PCI_EJECT			= PCI_MESSAGE_BASE + 0xB,
> +	PCI_QUERY_STOP			= PCI_MESSAGE_BASE + 0xC,
> +	PCI_REENABLE			= PCI_MESSAGE_BASE + 0xD,
> +	PCI_QUERY_STOP_FAILED		= PCI_MESSAGE_BASE + 0xE,
> +	PCI_EJECTION_COMPLETE		= PCI_MESSAGE_BASE + 0xF,
> +	PCI_RESOURCES_ASSIGNED		= PCI_MESSAGE_BASE + 0x10,
> +	PCI_RESOURCES_RELEASED		= PCI_MESSAGE_BASE + 0x11,
> +	PCI_INVALIDATE_BLOCK		= PCI_MESSAGE_BASE + 0x12,
> +	PCI_QUERY_PROTOCOL_VERSION	= PCI_MESSAGE_BASE + 0x13,
> +	PCI_CREATE_INTERRUPT_MESSAGE	= PCI_MESSAGE_BASE + 0x14,
> +	PCI_DELETE_INTERRUPT_MESSAGE	= PCI_MESSAGE_BASE + 0x15,
>  	PCI_RESOURCES_ASSIGNED2		= PCI_MESSAGE_BASE + 0x16,
>  	PCI_CREATE_INTERRUPT_MESSAGE2	= PCI_MESSAGE_BASE + 0x17,
>  	PCI_DELETE_INTERRUPT_MESSAGE2	= PCI_MESSAGE_BASE + 0x18, /* unused */
>  	PCI_BUS_RELATIONS2		= PCI_MESSAGE_BASE + 0x19,
> -	PCI_RESOURCES_ASSIGNED3         = PCI_MESSAGE_BASE + 0x1A,
> -	PCI_CREATE_INTERRUPT_MESSAGE3   = PCI_MESSAGE_BASE + 0x1B,
> +	PCI_RESOURCES_ASSIGNED3		= PCI_MESSAGE_BASE + 0x1A,
> +	PCI_CREATE_INTERRUPT_MESSAGE3	= PCI_MESSAGE_BASE + 0x1B,
>  	PCI_MESSAGE_MAXIMUM
>  };
>  
> @@ -1775,20 +1775,21 @@ static u32 hv_compose_msi_req_v1(
>   * via the HVCALL_RETARGET_INTERRUPT hypercall. But the choice of dummy vCPU is
>   * not irrelevant because Hyper-V chooses the physical CPU to handle the
>   * interrupts based on the vCPU specified in message sent to the vPCI VSP in
> - * hv_compose_msi_msg(). Hyper-V's choice of pCPU is not visible to the guest,
> - * but assigning too many vPCI device interrupts to the same pCPU can cause a
> - * performance bottleneck. So we spread out the dummy vCPUs to influence Hyper-V
> - * to spread out the pCPUs that it selects.
> + * hv_vmbus_compose_msi_msg(). Hyper-V's choice of pCPU is not visible to the
> + * guest, but assigning too many vPCI device interrupts to the same pCPU can
> + * cause a performance bottleneck. So we spread out the dummy vCPUs to influence
> + * Hyper-V to spread out the pCPUs that it selects.
>   *
>   * For the single-MSI and MSI-X cases, it's OK for hv_compose_msi_req_get_cpu()
>   * to always return the same dummy vCPU, because a second call to
> - * hv_compose_msi_msg() contains the "real" vCPU, causing Hyper-V to choose a
> - * new pCPU for the interrupt. But for the multi-MSI case, the second call to
> - * hv_compose_msi_msg() exits without sending a message to the vPCI VSP, so the
> - * original dummy vCPU is used. This dummy vCPU must be round-robin'ed so that
> - * the pCPUs are spread out. All interrupts for a multi-MSI device end up using
> - * the same pCPU, even though the vCPUs will be spread out by later calls
> - * to hv_irq_unmask(), but that is the best we can do now.
> + * hv_vmbus_compose_msi_msg() contains the "real" vCPU, causing Hyper-V to
> + * choose a new pCPU for the interrupt. But for the multi-MSI case, the second
> + * call to hv_vmbus_compose_msi_msg() exits without sending a message to the
> + * vPCI VSP, so the original dummy vCPU is used. This dummy vCPU must be
> + * round-robin'ed so that the pCPUs are spread out. All interrupts for a
> + * multi-MSI device end up using the same pCPU, even though the vCPUs will be
> + * spread out by later calls to hv_irq_unmask(), but that is the best we can do
> + * now.
>   *
>   * With Hyper-V in Nov 2022, the HVCALL_RETARGET_INTERRUPT hypercall does *not*
>   * cause Hyper-V to reselect the pCPU based on the specified vCPU. Such an
> @@ -1863,7 +1864,7 @@ static u32 hv_compose_msi_req_v3(
>  }
>  
>  /**
> - * hv_compose_msi_msg() - Supplies a valid MSI address/data
> + * hv_vmbus_compose_msi_msg() - Supplies a valid MSI address/data
>   * @data:	Everything about this MSI
>   * @msg:	Buffer that is filled in by this function
>   *
> @@ -1873,7 +1874,7 @@ static u32 hv_compose_msi_req_v3(
>   * response supplies a data value and address to which that data
>   * should be written to trigger that interrupt.
>   */
> -static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +static void hv_vmbus_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
>  {
>  	struct hv_pcibus_device *hbus;
>  	struct vmbus_channel *channel;
> @@ -1955,7 +1956,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
>  			return;
>  		}
>  		/*
> -		 * The vector we select here is a dummy value.  The correct
> +		 * The vector we select here is a dummy value.	The correct
>  		 * value gets sent to the hypervisor in unmask().  This needs
>  		 * to be aligned with the count, and also not zero.  Multi-msi
>  		 * is powers of 2 up to 32, so 32 will always work here.
> @@ -2047,7 +2048,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
>  
>  		/*
>  		 * Make sure that the ring buffer data structure doesn't get
> -		 * freed while we dereference the ring buffer pointer.  Test
> +		 * freed while we dereference the ring buffer pointer.	Test
>  		 * for the channel's onchannel_callback being NULL within a
>  		 * sched_lock critical section.  See also the inline comments
>  		 * in vmbus_reset_channel_cb().
> @@ -2147,7 +2148,7 @@ static const struct msi_parent_ops hv_pcie_msi_parent_ops = {
>  /* HW Interrupt Chip Descriptor */
>  static struct irq_chip hv_msi_irq_chip = {
>  	.name			= "Hyper-V PCIe MSI",
> -	.irq_compose_msi_msg	= hv_compose_msi_msg,
> +	.irq_compose_msi_msg	= hv_vmbus_compose_msi_msg,
>  	.irq_set_affinity	= irq_chip_set_affinity_parent,
>  	.irq_ack		= irq_chip_ack_parent,
>  	.irq_eoi		= irq_chip_eoi_parent,
> @@ -2159,8 +2160,8 @@ static int hv_pcie_domain_alloc(struct irq_domain *d, unsigned int virq, unsigne
>  			       void *arg)
>  {
>  	/*
> -	 * TODO: Allocating and populating struct tran_int_desc in hv_compose_msi_msg()
> -	 * should be moved here.
> +	 * TODO: Allocating and populating struct tran_int_desc in
> +	 *	 hv_vmbus_compose_msi_msg() should be moved here.
>  	 */
>  	int ret;
>  
> @@ -2227,7 +2228,7 @@ static int hv_pcie_init_irq_domain(struct hv_pcibus_device *hbus)
>  /**
>   * get_bar_size() - Get the address space consumed by a BAR
>   * @bar_val:	Value that a BAR returned after -1 was written
> - *              to it.
> + *		to it.
>   *
>   * This function returns the size of the BAR, rounded up to 1
>   * page.  It has to be rounded up because the hypervisor's page
> @@ -2573,7 +2574,7 @@ static void q_resource_requirements(void *context, struct pci_response *resp,
>   * new_pcichild_device() - Create a new child device
>   * @hbus:	The internal struct tracking this root PCI bus.
>   * @desc:	The information supplied so far from the host
> - *              about the device.
> + *		about the device.
>   *
>   * This function creates the tracking structure for a new child
>   * device and kicks off the process of figuring out what it is.
> @@ -3100,7 +3101,7 @@ static void hv_pci_onchannelcallback(void *context)
>  			 * sure that the packet pointer is still valid during the call:
>  			 * here 'valid' means that there's a task still waiting for the
>  			 * completion, and that the packet data is still on the waiting
> -			 * task's stack.  Cf. hv_compose_msi_msg().
> +			 * task's stack.  Cf. hv_vmbus_compose_msi_msg().
>  			 */
>  			comp_packet->completion_func(comp_packet->compl_ctxt,
>  						     response,
> @@ -3417,7 +3418,7 @@ static int hv_allocate_config_window(struct hv_pcibus_device *hbus)
>  	 * vmbus_allocate_mmio() gets used for allocating both device endpoint
>  	 * resource claims (those which cannot be overlapped) and the ranges
>  	 * which are valid for the children of this bus, which are intended
> -	 * to be overlapped by those children.  Set the flag on this claim
> +	 * to be overlapped by those children.	Set the flag on this claim
>  	 * meaning that this region can't be overlapped.
>  	 */
>  
> @@ -4066,7 +4067,7 @@ static int hv_pci_restore_msi_msg(struct pci_dev *pdev, void *arg)
>  		irq_data = irq_get_irq_data(entry->irq);
>  		if (WARN_ON_ONCE(!irq_data))
>  			return -EINVAL;
> -		hv_compose_msi_msg(irq_data, &entry->msg);
> +		hv_vmbus_compose_msi_msg(irq_data, &entry->msg);
>  	}
>  	return 0;
>  }
> @@ -4074,7 +4075,7 @@ static int hv_pci_restore_msi_msg(struct pci_dev *pdev, void *arg)
>  /*
>   * Upon resume, pci_restore_msi_state() -> ... ->  __pci_write_msi_msg()
>   * directly writes the MSI/MSI-X registers via MMIO, but since Hyper-V
> - * doesn't trap and emulate the MMIO accesses, here hv_compose_msi_msg()
> + * doesn't trap and emulate the MMIO accesses, here hv_vmbus_compose_msi_msg()
>   * must be used to ask Hyper-V to re-create the IOMMU Interrupt Remapping
>   * Table entries.
>   */
> -- 
> 2.51.2.vfs.0.1
> 

-- 
மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists