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

From: Yu Zhang

Date: Mon Sep 07 2026 - 04:48:48 EST


<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.

Actually, there's nothing specific to this hypercall here - it follows
the existing usage. E.g., hv_pci_read_mmio() already uses such arrangement,
as Michael noted in [2]. pvIOMMU queries fit within the existing per-CPU
page, with output placed after input, avoiding an unnecessary allocation.

[1] https://lore.kernel.org/all/SN6PR02MB4157C3EF6617A7BA4CA9E432D485A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/all/SN6PR02MB4157BF936EBDA23AD1EC5183D480A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

B.R.
Yu