Michael S. Tsirkin wrote:
On Mon, May 04, 2009 at 12:21:28PM +0300, Avi Kivity wrote:
Michael S. Tsirkin wrote:
So what I see is transports providing something like:
struct virtio_interrupt_mapping {
int virtqueue;
int interrupt;
};
map_vqs_to_interrupt(dev, struct vir
On Mon, May 04, 2009 at 12:21:28PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
So what I see is transports providing something like:
struct virtio_interrupt_mapping {
int virtqueue;
int interrupt;
};
map_vqs_to_interrupt(dev, struct virtio_inte
Michael S. Tsirkin wrote:
So what I see is transports providing something like:
struct virtio_interrupt_mapping {
int virtqueue;
int interrupt;
};
map_vqs_to_interrupt(dev, struct virtio_interrupt_mapping *, int nvirtqueues);
unmap_vqs(dev);
Isn't that the same thing?
On Tue, Apr 28, 2009 at 02:56:15PM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> So to map vq 0 to vector 0, vq 1 to vector 1 and vq 2 to vector 2 the driver
>> would do:
>>
>> struct virtio_interrupt_mapping mapping[3] = { {0, 0}, {1, 1}, {2, 2} };
>> vec = map_vqs_to_interrupt(dev
Michael S. Tsirkin wrote:
So to map vq 0 to vector 0, vq 1 to vector 1 and vq 2 to vector 2 the driver
would do:
struct virtio_interrupt_mapping mapping[3] = { {0, 0}, {1, 1}, {2, 2} };
vec = map_vqs_to_interrupt(dev, mapping, 3);
if (vec) {
error handling
}
and then find_vq as usual.
I
On Tue, Apr 28, 2009 at 08:51:08PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>> This does not work for MSIX - in linux, you must map all MSI-X entries
>> to interrupt vectors upfront.
>>
>
> What? that's very inflexible.
>
> Can you point me at the code?
See pci_enable_msix in inclu
Michael S. Tsirkin wrote:
This does not work for MSIX - in linux, you must map all MSI-X entries
to interrupt vectors upfront.
What? that's very inflexible.
Can you point me at the code?
So what I see is transports providing something like:
struct virtio_interrupt_mapping {
int
On Tue, Apr 28, 2009 at 09:47:14AM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>>> 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
Michael S. Tsirkin wrote:
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?
On Mon, Apr 27, 2009 at 09:39:06AM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> 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
On Mon, Apr 27, 2009 at 06:59:52PM +0200, Christian Borntraeger wrote:
> Am Monday 27 April 2009 17:39:36 schrieb Michael S. Tsirkin:
> > 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 tran
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 h
Am Monday 27 April 2009 17:39:36 schrieb Michael S. Tsirkin:
> 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?
This might be a stupid idea, but would something like the follow
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.
>>> Teac
Am Monday 27 April 2009 16:32:56 schrieb Michael S. Tsirkin:
> > 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?
>
> I think no, the transport can find out the max numb
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_v
Michael S. Tsirkin wrote:
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.
S
On Mon, Apr 27, 2009 at 04:00:30PM +0200, 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.
>
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
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. Tsi
20 matches
Mail list logo
