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: [email protected]
For additional commands, e-mail: [email protected]
