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 <jan.kis...@siemens.com> >>>>> >>>>> 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
signature.asc
Description: OpenPGP digital signature
