Re: [PATCH v5 4/5] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest

On Mon, Sep 07, 2026 at 02:08:35PM -0700, Mukesh R wrote:

On 9/7/26 01:41, Yu Zhang wrote:

quoted

<snip>

quoted

quoted

+{
+	u64 status;
+	u32 prefix;
+	unsigned long flags;
+	int ret;
+	struct pci_dev *pdev = to_pci_dev(dev);
+	struct hv_input_get_logical_device_property *input;
+	struct hv_output_get_logical_device_property *output;
+
+	ret = hv_pci_lookup_dev_id(pci_domain_nr(pdev->bus), &prefix);
+	if (ret)
+		return ret;
+
+	local_irq_save(flags);
+
+	input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+	output = (struct hv_output_get_logical_device_property *)(input + 1);

Any reason for not using pcpu output arg like we do in all other places?
If there is a technical reason, please document it, otherwise when revisited
in future for re-design, anyone looking at this will be confused and
waste time investigating if there is anything different about this hypercall.

Thank you, Mukesh. I had also incorrectly assumed that output required
a separate page, which is why the RFC included a separate output-page
allocation patch. Michael clarified during that review [1] that input
and output can share a page as long as their buffers do not overlap,
so I dropped that patch latter.

They can share a page, but we don't enforce the sizes combined do
not overflow a page, and that could be an issue in future. There is

The two hypercalls (HVCALL_GET_IOMMU_CAPABILITIES and
HVCALL_GET_LOGICAL_DEVICE_PROPERTY) each currently use only 40 bytes of
combined input and output. No concrete requirement has been identified
that would make either approach 4 KB. A hypothetical future expansion
is not sufficient reason to allocate another per-CPU page now. 

a tool on the hyp side i believe to check that input and output struct
sizes do not exceed page size.

Also, both the input and output pages are pre-allocated, so there is no
extra allocation (otherwise, we'd have changed all places by now). So
it's better to just follow the convention we've so far just to avoid
confusion during future redesign imo. We def need to revisit this in
near/medium future for all hypercalls.

Well, output page is NOT pre-allocated ordinary child partitions. Please
see hv_output_page_exists() in hv_common.c.
                                                                                                                                                        
My RFC included a separate allocation because I had incorrectly assumed
that output required its own page. Like I mentioned earlier, this was
already discussed during the RFC review [1], and that allocation patch
was dropped following the discussion.

Using separate pages is NOT a *convention* either: hv_pci_read_mmio()
already places input and output in non-overlapping regions of the same
page.

We can certainly reassess which hypercalls need separate output pages
in a broader review. I would keep that separate from this series,
rather than reopen the RFC discussion without a concrete issue in
the current implementation.

[1] https://lore.kernel.org/all/SN6PR02MB4157C3EF6617A7BA4CA9E432D485A@SN6PR02MB4157.namprd02.prod.outlook.com/ (local)

B.R.
Yu