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

[Yu Zhang]

On Mon, Sep 07, 2026 at 02:08:35PM -0700, Mukesh R wrote:
> On 9/7/26 01:41, Yu Zhang wrote:
> > <snip>
> > 
> > > > +{
> > > > +	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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

B.R.
Yu