Conversation
src/transport/pci.rs
Outdated
| field_shared!(self.common_cfg, queue_msix_vector).read() | ||
| } | ||
|
|
||
| /// Set the MSI-X vector for queue. |
There was a problem hiding this comment.
Before setting MSI-X vectors, the driver will need to check whether the device has the MSI-X capability, and check its MSI-X table size. I guess you either need separate methods for this on the transport, or some method to handle MSI-X setup generally.
I guess the ack_interrupt implementation will also need to change to support MSI-X interrupts when it is being used.
There was a problem hiding this comment.
yes code has to read the capability and such. i didn't add code for this because the code in my os for this is done outside of the virtio library, as i support non-virtio devices as well.
the interrupt ack register seems to only be used for "legacy" interrupts, according to the virtio spec.
There was a problem hiding this comment.
The isr_status register is only for legacy interrupts, but the Transport::ack_interrupt method should work either way. What I'm saying is that PciTransport should have some logic for negotiating whether MSI-X is being used or not, and if it is used then the behaviour of ack_interrupt should change.
| /// Get the underlying transport. | ||
| pub fn transport_mut(&mut self) -> &mut T { | ||
| &mut self.transport | ||
| } |
There was a problem hiding this comment.
Why are these methods needed on every device? I would have thought that the MSI-X configuration would happen during the initial setup of the device, either before passing the transport to the device driver or inside the driver. How do you expect them to be used?
There was a problem hiding this comment.
it worked better in my code to set up the interrupt later, after everything else is configured. so i added methods to expose the transport. this seems useful either way?
2 participants
Expose functions to configure MSI-X interrupt vectors.