On Mon, Jan 19, 2026 at 10:42:23PM -0800, Mukesh R wrote: > From: Mukesh Rathor <[email protected]> > > 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 <[email protected]> > --- > 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 > -- மணிவண்ணன் சதாசிவம்
