Re: [Qemu-devel] [PATCH v2 8/9] msix: Align MSI-X constants to libpci definitions and extend them

[Michael S. Tsirkin]

On Wed, Jun 08, 2011 at 11:11:37PM +0200, Jan Kiszka wrote:
> On 2011-06-08 23:09, Michael S. Tsirkin wrote:
> > On Wed, Jun 08, 2011 at 11:02:44PM +0200, Jan Kiszka wrote:
> >> On 2011-06-08 23:00, Michael S. Tsirkin wrote:
> >>> On Wed, Jun 08, 2011 at 10:48:10PM +0200, Jan Kiszka wrote:
> >>>> On 2011-06-08 21:53, Michael S. Tsirkin wrote:
> >>>>> On Wed, Jun 08, 2011 at 06:21:51PM +0200, Jan Kiszka wrote:
> >>>>>> Add PCI_MSIX_TABLE and PCI_MSIX_PBA, align other MSIX related constant
> >>>>>> names to libpci style. Will be used for device assignment code in
> >>>>>> qemu-kvm.
> >>>>>>
> >>>>>> Signed-off-by: Jan Kiszka <address@hidden>
> >>>>>
> >>>>> Besides keeping pci_regs.h aligned with the original,
> >>>>> I also think ideally pci register banging should stay
> >>>>> within the pci subsystem.
> >>>>>
> >>>>> Could we add high-level APIs to help with that,
> >>>>> instead of having kvm look at config space directly?
> >>>>
> >>>> We could move the related static inlines from msi/msix.c to the headers
> >>>> in order to test for bits etc. Still, kvm needs to interpret the config
> >>>> space of the assigned device, so the abstraction will remain rather low.
> >>>>
> >>>> Jan
> >>>>
> >>>
> >>> Hmm, at least for MSI/MSIX I thought this is done by kvm in kernel?
> >>>
> >>
> >> At least for the "traditional" assignment interface (VFIO may offload
> >> something), no. User space does the cap analysis, filtering, and in the
> >> MSI/MSI-X case the translation to QEMU msi/msix services. The latter is
> >> even WIP in my tree. Surrent assignment open-codes this, missing many
> >> corner cases.
> >>
> >> Jan
> >>
> > 
> > Anyway, if some defines need to be in a header, and aren't upstream
> > yet, let's create pci_ext_regs.h and add a comment there that we
> > should work on upstreaming them.
> 
> Sounds good. But what is supposed to be upstream for us, the kernel or
> pci-utils/libpci?
> 
> Jan
> 

It's currently the kernel, I don't really see a reason to change that.

-- 
MST