Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?

[Sheng Yang <sheng@linux.intel.com>]

On Tuesday 05 May 2009 20:08:40 Avi Kivity wrote:
> Michael S. Tsirkin wrote:
> > On Tue, May 05, 2009 at 02:57:10PM +0300, Avi Kivity wrote:
> >> Michael S. Tsirkin wrote:
> >>> On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
> >>>> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
> >>>>> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls
> >>>>> have been merged for 2.6.30. However, I note that PCI spec allows
> >>>>> devices to support multiple vectors with MSI as well (support will be
> >>>>> in linux 2.6.30).

Well, one question: when did them merged? IIRC, MSI-X related things are still 
pending for 2.6.31... :)

> >>>>>
> >>>>> Even though qemu for now only uses a single vector with MSI, it would
> >>>>> seem that it's better to make the kernel/user interface generic
> >>>>> straight away rather than add more ioctls later. What do you think?
> >>>>> It might not be too late to fix this for 2.6.30.
> >>>>
> >>>> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per
> >>>> assigned device?
> >>>
> >>> Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
> >>
> >> MSIX_NR is the size of the table, while MSIX_ENTRY updates a single
> >> entry, if I read the code correctly.
> >
> > Right. So we'll need something like this for MSI as well.
> > Actually maybe MSIX_NR MSIX_ENTRY should be renamed to MSI_NR / MSI_ENTRY
> > and changed to do the right thing depending on the IRQ type?
>
> Works for me.  Sheng, is there a reason why it wasn't done like this?

No, I think it's fine. Also some related structure should be modified. And one 
flag field should be add to kvm_assigned_msix_nr and 
kvm_assigned_msix_entry(using padding ones) to indicate the interrupt type, 
for we can't determined the irq type by device's status at that time.

-- 
regards
Yang, Sheng