VFIO support on hyperv (vfio_pci_core_ioctl())

VFIO support on hyperv (vfio_pci_core_ioctl())

[Mukesh R]

Hi Alex et al:

I've been looking at making pci passthru irq setup/remap work on hyperv
for the latest (6.19) version using vfio core. Unfortunately, it's just
not fitting well because in case of hyperv the irq remap is done by
the hypervisor. Specifically, for a robust and proper solution, we need
to override vfio_pci_set_msi_trigger(). As such, for the best way forward
I am trying to figure how much flexibility there is to modify
vfio_pci_intrs.c with "if (running_on_hyperv())" branches (putting hyperv
code in separate file).

If none, then the alternative would be to create vfio-hyperv.c with
vfio_device_ops.ioctl = hyperv_vfio_pci_core_ioctl(). But, then I'd
be replicating code for other sub ioctls like vfio_pci_ioctl_get_info(),
vfio_pci_ioctl_get_irq_info(), etc. Would it be acceptable to make them
non static in this case?

Please let me know your thoughts or if you have other suggestions.

Thanks,
-Mukesh

Re: VFIO support on hyperv (vfio_pci_core_ioctl())

[Alex Williamson]

On Wed, 25 Feb 2026 14:04:49 -0800
Mukesh R <mrathor@linux.microsoft.com> wrote:

> Hi Alex et al:
> 
> I've been looking at making pci passthru irq setup/remap work on hyperv
> for the latest (6.19) version using vfio core. Unfortunately, it's just
> not fitting well because in case of hyperv the irq remap is done by
> the hypervisor. Specifically, for a robust and proper solution, we need
> to override vfio_pci_set_msi_trigger(). As such, for the best way forward
> I am trying to figure how much flexibility there is to modify
> vfio_pci_intrs.c with "if (running_on_hyperv())" branches (putting hyperv
> code in separate file).
> 
> If none, then the alternative would be to create vfio-hyperv.c with
> vfio_device_ops.ioctl = hyperv_vfio_pci_core_ioctl(). But, then I'd
> be replicating code for other sub ioctls like vfio_pci_ioctl_get_info(),
> vfio_pci_ioctl_get_irq_info(), etc. Would it be acceptable to make them
> non static in this case?
> 
> Please let me know your thoughts or if you have other suggestions.

Hi Mukesh,

In general, littering the code with running_on_hyperv() tests is not
acceptable, but the presented alternative isn't really accurate either.
If you want to substitute in your own ioctl callback, you can still
call vfio_pci_core_ioctl() for all the unhandled ioctls, without extra
exports.  We can also look at whether vfio_pci_device_ops could have a
callback specifically addressing an alternative set_msi_trigger
handler.  Thanks,

Alex

Re: VFIO support on hyperv (vfio_pci_core_ioctl())

[Mukesh R]

On 2/27/26 11:29, Alex Williamson wrote:
> On Wed, 25 Feb 2026 14:04:49 -0800
> Mukesh R <mrathor@linux.microsoft.com> wrote:
> 
>> Hi Alex et al:
>>
>> I've been looking at making pci passthru irq setup/remap work on hyperv
>> for the latest (6.19) version using vfio core. Unfortunately, it's just
>> not fitting well because in case of hyperv the irq remap is done by
>> the hypervisor. Specifically, for a robust and proper solution, we need
>> to override vfio_pci_set_msi_trigger(). As such, for the best way forward
>> I am trying to figure how much flexibility there is to modify
>> vfio_pci_intrs.c with "if (running_on_hyperv())" branches (putting hyperv
>> code in separate file).
>>
>> If none, then the alternative would be to create vfio-hyperv.c with
>> vfio_device_ops.ioctl = hyperv_vfio_pci_core_ioctl(). But, then I'd
>> be replicating code for other sub ioctls like vfio_pci_ioctl_get_info(),
>> vfio_pci_ioctl_get_irq_info(), etc. Would it be acceptable to make them
>> non static in this case?
>>
>> Please let me know your thoughts or if you have other suggestions.
> 
> Hi Mukesh,
> 
> In general, littering the code with running_on_hyperv() tests is not
> acceptable, but the presented alternative isn't really accurate either.
> If you want to substitute in your own ioctl callback, you can still
> call vfio_pci_core_ioctl() for all the unhandled ioctls, without extra

Yes, I realized that after looking at how other callers were using it.

> exports.  We can also look at whether vfio_pci_device_ops could have a
> callback specifically addressing an alternative set_msi_trigger
> handler.  Thanks,

Sounds good. thanks as always,
-Mukesh


> Alex