[virtio-dev] Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ

[Parav Pandit <parav@nvidia.com>]

On 5/7/2023 5:04 AM, Michael S. Tsirkin wrote:
> 
> one things I still don't see addressed here is support for
> legacy interrupts. legacy driver can disable msix and
> interrupts will be then sent.
> how about a special command that is used when device would
> normally send INT#x? it can also return ISR to reduce latency.

I am not sure if this is a real issue. Because even the legacy guests 
have msix enabled by default. In theory yes, it can fall back to intx.

There are few options.
1. A hypervisor driver can be conservative and steal an msix of the VF 
for transporting intx.
Pros: Does not need special things in device
Cons:
a. Fairly intrusive in hypervisor vf driver.
b. May not be ever used as guest is unlikely to fail on msix

2. Since multiple VFs intx to be serviced, one command per VF in AQ is 
too much overhead that device needs to map a request to,

A better way is to have an eventq of depth = num_vfs, like many other 
virtio devices have it.

An eventq can hold per VF interrupt entry including the isr value that 
you suggest above.

Something like,

union eventq_entry {
	u8 raw_data[16];
	struct intx_entry {
		u8 event_opcode;
		u8 group_type;
		u8 reserved[6];
		le64 group_identifier;
		u8 isr_status;
	};
};

This eventq resides on the owner parent PF.
isr_status is read on clear like today.

May be such eventq can be useful in future for wider case.
We may have to find a different name for it as other devices has device 
specific eventq.

I am inclined to differ this to a later point if one can identify the 
real failure with msix for the guest VM.

So far we don't see this ever happening.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org