<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/sn6pr02mb4157c3ef6617a7ba4ca9e432d4...@sn6pr02mb4157.namprd02.prod.outlook.com/
[2]
https://lore.kernel.org/all/sn6pr02mb4157bf936ebda23ad1ec5183d4...@sn6pr02mb4157.namprd02.prod.outlook.com/
B.R.
Yu
