qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 8/9] msix: Align MSI-X constants to libpci de


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v2 8/9] msix: Align MSI-X constants to libpci definitions and extend them
Date: Wed, 08 Jun 2011 23:11:37 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]