From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E1ECF1917FB; Sat, 24 Jan 2026 00:42:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769215377; cv=none; b=qCSs88wTKJmyGl7sjhZ/mB/XlvEO3WfeR6Sqguli29VNMqjqkxnJ5r02ZipntbCaYJYuijkLZ0Qhe5kE7ESpanW8UvMI78jEY5nmYOFIJYRKCQA/5zvnqByqKEgflHbXTNvXKAEIwP+ff/Ba4yHuBd1O2UIi36DX0IxIOtb5qBY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769215377; c=relaxed/simple; bh=QUhuSwU9uBGdExCAe5lHzroC9+YielYRNV8iA0ogkbA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=EUnijhsfAyIXfo1tSqtcdEmLkQKBnNEmmYafUomnoMfq7kQkpWD7ua0TYZdmt848oDitqtHkdJzAHCEzD9dzYJZIWGa6AdKgagvpFKQplDXKQRw+nDP2dNn/Xx6x+kE5c7o/r+7Ijb7qv0PIbpPg7gEt9pzVD137A4IpeAb+ji4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=rUPhcDz9; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="rUPhcDz9" Received: from [100.75.32.59] (unknown [40.78.12.246]) by linux.microsoft.com (Postfix) with ESMTPSA id 8321E20B7167; Fri, 23 Jan 2026 16:42:54 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8321E20B7167 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1769215375; bh=tiTZ+ukMLl4OXHhgzRRQhkhViH6uArijXtaplMQFyNU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rUPhcDz9eRP0YeuPqK34N2lDMwbRB52VGddYs6ysYtjNXUqu4dAK9z+8Rdy3fquD+ kh+U/9/YovoOObrh//W9Upz0QxbWdxObtIFuQEDYmYViTTLYdkb/adpR6JY31dZyRn KYf8PPOmxAf5F9ZFRxUUDnoLuEzTjm9G75F+NqhI= Message-ID: Date: Fri, 23 Jan 2026 16:42:54 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH v0 10/15] PCI: hv: Build device id for a VMBus device Content-Language: en-US To: Stanislav Kinsburskii 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 References: <20260120064230.3602565-1-mrathor@linux.microsoft.com> <20260120064230.3602565-11-mrathor@linux.microsoft.com> From: Mukesh R In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/20/26 14:22, Stanislav Kinsburskii wrote: > On Mon, Jan 19, 2026 at 10:42:25PM -0800, Mukesh R wrote: >> From: Mukesh Rathor >> >> On Hyper-V, most hypercalls related to PCI passthru to map/unmap regions, >> interrupts, etc need a device id as a parameter. This device id refers >> to that specific device during the lifetime of passthru. >> >> An L1VH VM only contains VMBus based devices. A device id for a VMBus >> device is slightly different in that it uses the hv_pcibus_device info >> for building it to make sure it matches exactly what the hypervisor >> expects. This VMBus based device id is needed when attaching devices in >> an L1VH based guest VM. Before building it, a check is done to make sure >> the device is a valid VMBus device. >> >> Signed-off-by: Mukesh Rathor >> --- >> arch/x86/include/asm/mshyperv.h | 2 ++ >> drivers/pci/controller/pci-hyperv.c | 29 +++++++++++++++++++++++++++++ >> 2 files changed, 31 insertions(+) >> >> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h >> index eef4c3a5ba28..0d7fdfb25e76 100644 >> --- a/arch/x86/include/asm/mshyperv.h >> +++ b/arch/x86/include/asm/mshyperv.h >> @@ -188,6 +188,8 @@ bool hv_vcpu_is_preempted(int vcpu); >> static inline void hv_apic_init(void) {} >> #endif >> >> +u64 hv_pci_vmbus_device_id(struct pci_dev *pdev); >> + >> struct irq_domain *hv_create_pci_msi_domain(void); >> >> int hv_map_msi_interrupt(struct irq_data *data, >> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c >> index 8bc6a38c9b5a..40f0b06bb966 100644 >> --- a/drivers/pci/controller/pci-hyperv.c >> +++ b/drivers/pci/controller/pci-hyperv.c >> @@ -579,6 +579,8 @@ static void hv_pci_onchannelcallback(void *context); >> #define DELIVERY_MODE APIC_DELIVERY_MODE_FIXED >> #define HV_MSI_CHIP_FLAGS MSI_CHIP_FLAG_SET_ACK >> >> +static bool hv_vmbus_pci_device(struct pci_bus *pbus); >> + > > Why not moving this static function definition above the called instead of > defining the prototype? Did you see the function implementation? It has other dependencies that are later, it would need code reorg. Thanks, -Mukesh >> static int hv_pci_irqchip_init(void) >> { >> return 0; >> @@ -598,6 +600,26 @@ static unsigned int hv_msi_get_int_vector(struct irq_data *data) >> >> #define hv_msi_prepare pci_msi_prepare >> >> +u64 hv_pci_vmbus_device_id(struct pci_dev *pdev) >> +{ >> + u64 u64val; > > This variable is redundant. Not really. It helps with debug by putting a quick print, and is harmless. >> + struct hv_pcibus_device *hbus; >> + struct pci_bus *pbus = pdev->bus; >> + >> + if (!hv_vmbus_pci_device(pbus)) >> + return 0; >> + >> + hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata); >> + u64val = (hbus->hdev->dev_instance.b[5] << 24) | >> + (hbus->hdev->dev_instance.b[4] << 16) | >> + (hbus->hdev->dev_instance.b[7] << 8) | >> + (hbus->hdev->dev_instance.b[6] & 0xf8) | >> + PCI_FUNC(pdev->devfn); >> + > > It looks like this value always fits into 32 bit, so what is the value > in returning 64 bit? The ABI has device id defined as 64bits where this is assigned. Thanks, -Mukesh > Thanks, > Stanislav > >> + return u64val; >> +} >> +EXPORT_SYMBOL_GPL(hv_pci_vmbus_device_id); >> + >> /** >> * hv_irq_retarget_interrupt() - "Unmask" the IRQ by setting its current >> * affinity. >> @@ -1404,6 +1426,13 @@ static struct pci_ops hv_pcifront_ops = { >> .write = hv_pcifront_write_config, >> }; >> >> +#ifdef CONFIG_X86 >> +static bool hv_vmbus_pci_device(struct pci_bus *pbus) >> +{ >> + return pbus->ops == &hv_pcifront_ops; >> +} >> +#endif /* CONFIG_X86 */ >> + >> /* >> * Paravirtual backchannel >> * >> -- >> 2.51.2.vfs.0.1 >>