On Mon, Apr 27, 2009 at 05:37:25PM +0200, Christian Borntraeger wrote: > > As number of virtqueues <= number of vectors, > > we could pre-allocate all vectors that host supports, but this seems > > a bit drastic as an MSI-X device could support up to 2K vectors. > > > > > In fact, the transport has to have a way of getting the number of virtqeues > > > because find_vq returns ENOENT on invalid index numbers. > > > > > > Christian > > > > So again, I think this is an upper bound supported by host. Right? > > Not the upper bound, but the real available virtqueues. (With current qemu > 3 for virtio-net, 2 for virtio-console etc.) Here's what I mean by upper bound: guest and host number of virtqueues might be different: the host might support control virtqueue like in virtio-net, but guest might be an older version and not use it. > Since I use a different transport (drivers/s390/kvm/kvm_virtio.c), my > motiviation is to keep the virtio interface as generic as possible. I > dont really like the new interface, but I cannot give you silver > bullet technical reasons - its more a gut feeling. The interface would > work with lguest and s390. > > Anyway. Avis suggestion to decouple MSI count and virtqueue count looks > like a promising approach. So generally, we add request_vectors which gives us the number of available MSI vectors and then find_vq gets a vector #? Does this sound better? -- 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
