On Mon, Apr 27, 2009 at 06:06:48PM +0300, Avi Kivity wrote: > Christian Borntraeger wrote: >> Am Monday 27 April 2009 14:31:36 schrieb Michael S. Tsirkin: >> >>> Add optional MSI-X support: use a vector per virtqueue with >>> fallback to a common vector and finally to regular interrupt. >>> Teach all drivers to use it. >>> >>> I added 2 new virtio operations: request_vqs/free_vqs because MSI >>> needs to know the total number of vectors upfront. >>> >>> Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx> >>> >> >> I dont know, if that is feasible for MSI, but the transport(virtio_pci) should >> already know the number of virtqueues, which should match the number of >> vectors, no? >> >> In fact, the transport has to have a way of getting the number of virtqeues >> because find_vq returns ENOENT on invalid index numbers. >> > > One thing I thought was to decouple the virtqueue count from the MSI > entry count, and let the guest choose how many MSI entries it wants to > use. This is useful if it wants several queues to share an interrupt, > perhaps it wants both rx and tx rings on one cpu to share a single > vector. > > So the device could expose a large, constant number of MSI entries, and > in addition expose a table mapping ring number to msi entry number. The > guest could point all rings to one entry, or have each ring use a > private entry, or anything in between. Sounds good ... and it might not be a lot of code I think. > That saves us the new API (at the expense of a lot more code, but with > added flexibility). So we'll probably need to rename request_vqs to request_vectors, but we probably still need the driver to pass the number of vectors it wants to the transport. Right? -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
