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;
> };
>
>>
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);
>>>
>
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
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 {
>
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
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 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.
>
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
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 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
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
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
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: req
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 up
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
20 matches
Mail list logo