From: Mukesh R <mrathor@linux.microsoft.com>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arch@vger.kernel.org,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com,
catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, joro@8bytes.org, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, robh@kernel.org,
bhelgaas@google.com, arnd@arndb.de,
nunodasneves@linux.microsoft.com, mhklinux@outlook.com,
romank@linux.microsoft.com
Subject: Re: [PATCH v0 11/15] x86/hyperv: Build logical device ids for PCI passthru hcalls
Date: Fri, 23 Jan 2026 16:44:01 -0800 [thread overview]
Message-ID: <8302b48c-bd78-6348-eef2-be957d0e8bc4@linux.microsoft.com> (raw)
In-Reply-To: <aXABVTS6xDb2GB2s@skinsburskii.localdomain>
On 1/20/26 14:27, Stanislav Kinsburskii wrote:
> On Mon, Jan 19, 2026 at 10:42:26PM -0800, Mukesh R wrote:
>> From: Mukesh Rathor <mrathor@linux.microsoft.com>
>>
>> On Hyper-V, most hypercalls related to PCI passthru to map/unmap regions,
>> interrupts, etc need a device id as a parameter. A device id refers
>> to a specific device. A device id is of two types:
>> o Logical: used for direct attach (see below) hypercalls. A logical
>> device id is a unique 62bit value that is created and
>> sent during the initial device attach. Then all further
>> communications (for interrupt remaps etc) must use this
>> logical id.
>> o PCI: used for device domain hypercalls such as map, unmap, etc.
>> This is built using actual device BDF info.
>>
>> PS: Since an L1VH only supports direct attaches, a logical device id
>> on an L1VH VM is always a VMBus device id. For non-L1VH cases,
>> we just use PCI BDF info, altho not strictly needed, to build the
>> logical device id.
>>
>> At a high level, Hyper-V supports two ways to do PCI passthru:
>> 1. Device Domain: root must create a device domain in the hypervisor,
>> and do map/unmap hypercalls for mapping and unmapping guest RAM.
>> All hypervisor communications use device id of type PCI for
>> identifying and referencing the device.
>>
>> 2. Direct Attach: the hypervisor will simply use the guest's HW
>> page table for mappings, thus the host need not do map/unmap
>> hypercalls. A direct attached device must be referenced
>> via logical device id and never via the PCI device id. For an
>> L1VH root/parent, Hyper-V only supports direct attaches.
>>
>> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
>> ---
>> arch/x86/hyperv/irqdomain.c | 60 ++++++++++++++++++++++++++++++---
>> arch/x86/include/asm/mshyperv.h | 14 ++++++++
>> 2 files changed, 70 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
>> index ccbe5848a28f..33017aa0caa4 100644
>> --- a/arch/x86/hyperv/irqdomain.c
>> +++ b/arch/x86/hyperv/irqdomain.c
>> @@ -137,7 +137,7 @@ static int get_rid_cb(struct pci_dev *pdev, u16 alias, void *data)
>> return 0;
>> }
>>
>> -static union hv_device_id hv_build_devid_type_pci(struct pci_dev *pdev)
>> +static u64 hv_build_devid_type_pci(struct pci_dev *pdev)
>> {
>> int pos;
>> union hv_device_id hv_devid;
>> @@ -197,7 +197,58 @@ static union hv_device_id hv_build_devid_type_pci(struct pci_dev *pdev)
>> }
>>
>> out:
>> - return hv_devid;
>> + return hv_devid.as_uint64;
>> +}
>> +
>> +/* Build device id for direct attached devices */
>> +static u64 hv_build_devid_type_logical(struct pci_dev *pdev)
>> +{
>> + hv_pci_segment segment;
>> + union hv_device_id hv_devid;
>> + union hv_pci_bdf bdf = {.as_uint16 = 0};
>> + struct rid_data data = {
>> + .bridge = NULL,
>> + .rid = PCI_DEVID(pdev->bus->number, pdev->devfn)
>> + };
>> +
>> + segment = pci_domain_nr(pdev->bus);
>> + bdf.bus = PCI_BUS_NUM(data.rid);
>> + bdf.device = PCI_SLOT(data.rid);
>> + bdf.function = PCI_FUNC(data.rid);
>> +
>> + hv_devid.as_uint64 = 0;
>> + hv_devid.device_type = HV_DEVICE_TYPE_LOGICAL;
>> + hv_devid.logical.id = (u64)segment << 16 | bdf.as_uint16;
>> +
>> + return hv_devid.as_uint64;
>> +}
>> +
>> +/* Build device id after the device has been attached */
>> +u64 hv_build_devid_oftype(struct pci_dev *pdev, enum hv_device_type type)
>> +{
>> + if (type == HV_DEVICE_TYPE_LOGICAL) {
>> + if (hv_l1vh_partition())
>> + return hv_pci_vmbus_device_id(pdev);
>
> Should this one be renamed into hv_build_devid_type_vmbus() to align
> with the other two function names?
No, because hyperv only defines two types of device ids, and it would
unnecessary at to confusion. vmbus uses one the two types of device
ids.
> Thanks,
> Stanislav
>
>> + else
>> + return hv_build_devid_type_logical(pdev);
>> + } else if (type == HV_DEVICE_TYPE_PCI)
>> + return hv_build_devid_type_pci(pdev);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(hv_build_devid_oftype);
>> +
>> +/* Build device id for the interrupt path */
>> +static u64 hv_build_irq_devid(struct pci_dev *pdev)
>> +{
>> + enum hv_device_type dev_type;
>> +
>> + if (hv_pcidev_is_attached_dev(pdev) || hv_l1vh_partition())
>> + dev_type = HV_DEVICE_TYPE_LOGICAL;
>> + else
>> + dev_type = HV_DEVICE_TYPE_PCI;
>> +
>> + return hv_build_devid_oftype(pdev, dev_type);
>> }
>>
>> /*
>> @@ -221,7 +272,7 @@ int hv_map_msi_interrupt(struct irq_data *data,
>>
>> msidesc = irq_data_get_msi_desc(data);
>> pdev = msi_desc_to_pci_dev(msidesc);
>> - hv_devid = hv_build_devid_type_pci(pdev);
>> + hv_devid.as_uint64 = hv_build_irq_devid(pdev);
>> cpu = cpumask_first(irq_data_get_effective_affinity_mask(data));
>>
>> return hv_map_interrupt(hv_current_partition_id, hv_devid, false, cpu,
>> @@ -296,7 +347,8 @@ static int hv_unmap_msi_interrupt(struct pci_dev *pdev,
>> {
>> union hv_device_id hv_devid;
>>
>> - hv_devid = hv_build_devid_type_pci(pdev);
>> + hv_devid.as_uint64 = hv_build_irq_devid(pdev);
>> +
>> return hv_unmap_interrupt(hv_devid.as_uint64, irq_entry);
>> }
>>
>> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
>> index 0d7fdfb25e76..97477c5a8487 100644
>> --- a/arch/x86/include/asm/mshyperv.h
>> +++ b/arch/x86/include/asm/mshyperv.h
>> @@ -188,6 +188,20 @@ bool hv_vcpu_is_preempted(int vcpu);
>> static inline void hv_apic_init(void) {}
>> #endif
>>
>> +#if IS_ENABLED(CONFIG_HYPERV_IOMMU)
>> +static inline bool hv_pcidev_is_attached_dev(struct pci_dev *pdev)
>> +{ return false; } /* temporary */
>> +u64 hv_build_devid_oftype(struct pci_dev *pdev, enum hv_device_type type);
>> +#else /* CONFIG_HYPERV_IOMMU */
>> +static inline bool hv_pcidev_is_attached_dev(struct pci_dev *pdev)
>> +{ return false; }
>> +
>> +static inline u64 hv_build_devid_oftype(struct pci_dev *pdev,
>> + enum hv_device_type type)
>> +{ return 0; }
>> +
>> +#endif /* CONFIG_HYPERV_IOMMU */
>> +
>> u64 hv_pci_vmbus_device_id(struct pci_dev *pdev);
>>
>> struct irq_domain *hv_create_pci_msi_domain(void);
>> --
>> 2.51.2.vfs.0.1
>>
>
>
>
>
>
>
>
>
next prev parent reply other threads:[~2026-01-24 0:44 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 6:42 [PATCH v0 00/15] PCI passthru on Hyper-V (Part I) Mukesh R
2026-01-20 6:42 ` [PATCH v0 01/15] iommu/hyperv: rename hyperv-iommu.c to hyperv-irq.c Mukesh R
2026-01-20 19:08 ` kernel test robot
2026-01-20 21:09 ` kernel test robot
2026-02-05 18:48 ` Anirudh Rayabharam
2026-01-20 6:42 ` [PATCH v0 02/15] x86/hyperv: cosmetic changes in irqdomain.c for readability Mukesh R
2026-02-05 18:47 ` Anirudh Rayabharam
2026-01-20 6:42 ` [PATCH v0 03/15] x86/hyperv: add insufficient memory support in irqdomain.c Mukesh R
2026-01-21 0:53 ` kernel test robot
2026-01-20 6:42 ` [PATCH v0 04/15] mshv: Provide a way to get partition id if running in a VMM process Mukesh R
2026-01-23 18:23 ` Nuno Das Neves
2026-01-20 6:42 ` [PATCH v0 05/15] mshv: Declarations and definitions for VFIO-MSHV bridge device Mukesh R
2026-01-23 18:25 ` Nuno Das Neves
2026-01-24 0:36 ` Mukesh R
2026-01-20 6:42 ` [PATCH v0 06/15] mshv: Implement mshv bridge device for VFIO Mukesh R
2026-01-20 16:09 ` Stanislav Kinsburskii
2026-01-23 18:32 ` Nuno Das Neves
2026-01-24 0:37 ` Mukesh R
2026-01-20 6:42 ` [PATCH v0 07/15] mshv: Add ioctl support for MSHV-VFIO bridge device Mukesh R
2026-01-20 16:13 ` Stanislav Kinsburskii
2026-01-20 6:42 ` [PATCH v0 08/15] PCI: hv: rename hv_compose_msi_msg to hv_vmbus_compose_msi_msg Mukesh R
2026-01-28 14:03 ` Manivannan Sadhasivam
2026-01-20 6:42 ` [PATCH v0 09/15] mshv: Import data structs around device domains and irq remapping Mukesh R
2026-01-20 22:17 ` Stanislav Kinsburskii
2026-01-24 0:38 ` Mukesh R
2026-01-20 6:42 ` [PATCH v0 10/15] PCI: hv: Build device id for a VMBus device Mukesh R
2026-01-20 22:22 ` Stanislav Kinsburskii
2026-01-24 0:42 ` Mukesh R
2026-01-26 20:50 ` Stanislav Kinsburskii
2026-01-28 14:36 ` Manivannan Sadhasivam
2026-01-20 6:42 ` [PATCH v0 11/15] x86/hyperv: Build logical device ids for PCI passthru hcalls Mukesh R
2026-01-20 22:27 ` Stanislav Kinsburskii
2026-01-24 0:44 ` Mukesh R [this message]
2026-01-20 6:42 ` [PATCH v0 12/15] x86/hyperv: Implement hyperv virtual iommu Mukesh R
2026-01-21 0:12 ` Stanislav Kinsburskii
2026-01-24 1:26 ` Mukesh R
2026-01-26 15:57 ` Stanislav Kinsburskii
2026-01-27 3:02 ` Mukesh R
2026-01-27 18:46 ` Stanislav Kinsburskii
2026-01-30 22:51 ` Mukesh R
2026-02-02 16:20 ` Stanislav Kinsburskii
2026-01-22 5:18 ` Jacob Pan
2026-01-24 2:01 ` Mukesh R
2026-01-27 19:21 ` Jacob Pan
2026-01-27 22:31 ` Jacob Pan
2026-01-30 22:10 ` Mukesh R
2026-01-30 23:44 ` Mukesh R
2026-01-20 6:42 ` [PATCH v0 13/15] x86/hyperv: Basic interrupt support for direct attached devices Mukesh R
2026-01-21 0:47 ` Stanislav Kinsburskii
2026-01-24 2:08 ` Mukesh R
2026-01-20 6:42 ` [PATCH v0 14/15] mshv: Remove mapping of mmio space during map user ioctl Mukesh R
2026-01-21 1:41 ` Stanislav Kinsburskii
2026-01-23 18:34 ` Nuno Das Neves
2026-01-24 2:12 ` Mukesh R
2026-01-20 6:42 ` [PATCH v0 15/15] mshv: Populate mmio mappings for PCI passthru Mukesh R
2026-01-20 19:52 ` kernel test robot
2026-01-21 1:53 ` Stanislav Kinsburskii
2026-01-24 2:19 ` Mukesh R
2026-01-26 18:15 ` Stanislav Kinsburskii
2026-01-27 3:07 ` Mukesh R
2026-01-27 18:57 ` Stanislav Kinsburskii
2026-01-30 22:17 ` Mukesh R
2026-02-02 16:30 ` Stanislav Kinsburskii
2026-02-04 22:52 ` Mukesh R
2026-02-05 16:28 ` Stanislav Kinsburskii
2026-02-05 17:57 ` Mukesh R
2026-02-05 18:31 ` Stanislav Kinsburskii
2026-01-20 21:50 ` [PATCH v0 00/15] PCI passthru on Hyper-V (Part I) Jacob Pan
2026-01-24 2:27 ` Mukesh R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8302b48c-bd78-6348-eef2-be957d0e8bc4@linux.microsoft.com \
--to=mrathor@linux.microsoft.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kwilczynski@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mhklinux@outlook.com \
--cc=mingo@redhat.com \
--cc=nunodasneves@linux.microsoft.com \
--cc=robh@kernel.org \
--cc=romank@linux.microsoft.com \
--cc=skinsburskii@linux.microsoft.com \
--cc=tglx@linutronix.de \
--cc=wei.liu@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox