Re: [PATCHv4 2/2] virtio: refactor find_vqs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 27, 2009 at 08:32:24PM +0930, Rusty Russell wrote:
> On Thu, 27 Aug 2009 07:19:26 pm Michael S. Tsirkin wrote:
> > On Thu, Aug 27, 2009 at 07:00:34PM +0930, Rusty Russell wrote:
> > > On Tue, 25 Aug 2009 09:34:34 pm Michael S. Tsirkin wrote:
> > > > > That's because we didn't do the request_irq's for the per_vector case, because
> > > > > we don't have the names.  This is what prevented me from doing a nice
> > > > > encapsulation.
> > > > 
> > > > Yes. But let's split free_vectors out into free_msix_vectors and
> > > > free_intx as well?
> > > 
> > > Perhaps.  Patch welcome :)
> > 
> > Could you put the end result somewhere so I can work on top of it?
> 
> Sure, it'll hit linux-next tomorrow, otherwise you can steal from
> http://ozlabs.org/~rusty/kernel/rr-latest (virtio:pci-minor-cleanups.patch
> and virtio:pci-minor-cleanups-fix.patch).
> 
> > > But vector for something which isn't always the vector
> > > is misleading, IMHO.
> > 
> > I think you mean it's isn't always used? It's always a vector ...
> 
> The non-MSI case, it's set to VIRTIO_MSI_NO_VECTOR, and we use a normal
> interrupt vector.
> 
> > BTW, let's get rid of msix_enabled completely?
> > We can always use msix_vectors ...
> 
> That would be nice.  But yes, requiring more audit.
> 
> Ideally, if msix_vectors == 0, implies intx_enabled.

It seems that since we *can* request both an intx
and msix vectors, it's better to have them independent even if we
currently don't do that. No?

> Thanks,
> Rusty.
--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux