[vfio-users] Interrupt Handling: Regression or config change?

Tue Jan 10 22:47:59 UTC 2017

Thanks again. I've made a very rough check with diff -y bewteen configs 
and they look quite similar.

Not too surprising. I'll be using the 4.6 config for most part, so I 
should be safe

Did that to rule out any change on the side of the arch release. 
However, I may as well have overseen something, of course.

As for the supposedly relevant parts:

# cat .config-4.5.4 | grep -i vfio
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_VFIO_PCI=m
CONFIG_VFIO_PCI_VGA=y
CONFIG_VFIO_PCI_MMAP=y
CONFIG_VFIO_PCI_INTX=y
CONFIG_KVM_VFIO=y

# cat .config-4.6.5 | grep -i vfio
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_VFIO_PCI=m
CONFIG_VFIO_PCI_VGA=y
CONFIG_VFIO_PCI_MMAP=y
CONFIG_VFIO_PCI_INTX=y
CONFIG_VFIO_PCI_IGD=y
CONFIG_KVM_VFIO=y

# cat .config-4.5.4 | grep -i mmu
CONFIG_MMU=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_IOMMU_HELPER=y
CONFIG_MMU_NOTIFIER=y
# Near Field Communication (NFC) devices
CONFIG_VFIO_IOMMU_TYPE1=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
# Generic IOMMU Pagetable Support
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
# CONFIG_AMD_IOMMU_STATS is not set
CONFIG_AMD_IOMMU_V2=m
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_SVM=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_KVM_MMU_AUDIT=y

# cat .config-4.6.5 | grep -i mmu
CONFIG_MMU=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_IOMMU_HELPER=y
CONFIG_MMU_NOTIFIER=y
# Near Field Communication (NFC) devices
CONFIG_VFIO_IOMMU_TYPE1=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
# Generic IOMMU Pagetable Support
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
# CONFIG_AMD_IOMMU_STATS is not set
CONFIG_AMD_IOMMU_V2=m
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_SVM=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_KVM_MMU_AUDIT=y

Am 10.01.2017 um 22:48 schrieb Manuel Ullmann:
> Hello Ede,
>
> you’re welcome. :) Had to look up that for myself.
>
> git tag
>
> shows you the available tags and it is v4.6.
>
> Wouldn’t use olddefconfig on a production kernel, but for bisecting I
> considered it sufficient. Probably you should check, that VM relevant
> options are still in place on major version jumps, but yeah, it’s
> equivalent to running oldconfig and holding return.
>
> Most important is obviously VFIO_PCI_VGA, which has a lot of
> dependencies, so check for that on major version jumps:
>
> cat .config | grep VFIO_PCI_VGA
>
> Best regards,
> Manuel
>> Hello Manuel,
>>
>> big, BIG, B I G thanks for your time and the excellent
>> instructions. Highly appreciated.
>> Meanwhile, without dissecting, I have narrowed it further down to the
>> obvious, that is, the last Kernel of 4.5, which is 4.5.7, is working,
>> while 4.6 is not. In fact, the general guest behaviour with 4.6 is
>> horrible, barely usable at all, even without involving the parallel
>> port.
>> Further, my parallel device is not even recogniced at all and the
>> mouse is rather jumpy.
>>
>> Before the dissecting starts, which will take quite some time, please
>> allow one more question: The proper tag for Kernel 4.6, is it
>>
>> git fetch linux-stable refs/tags/v4.5.7:refs/tags/v4.6
>> or
>> git fetch linux-stable refs/tags/v4.5.7:refs/tags/v4.6.0
>>
>> ? As I have both variations. The modules are called 4.6.0, the archive
>> iself just 4.6.
>>
>> And of course, thanks to you Daimon for the correction as well.
>>
>> Ede
>>
>> P.S.: As a side note: Learned something new, did not know about
>> olddefconfig. Saves a lot of work compared to make oldconfig, when
>> making larger verion jumps.
>>
>>
>>
>>
>>
>> Am 07.01.2017 um 18:38 schrieb Manuel Ullmann:
>>> Hello Ede,
>>>
>>> you do not need to be a programmer for bisecting. It is just required,
>>> that you can follow a step-by-step guide and adapt examples for your
>>> case. Git documentation is quite good and the first time I bisected
>>> something, I didn’t even know about it, but knew the git command for
>>> jumping through the commit history, which was also sufficient, but more
>>> time intensive. So:
>>>
>>> mkdir /path/to/your/new/source
>>> cd /path/to/your/new/source
>>> git init
>>> git remote add linux-stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>>> The following will just fetch the tags inbetween the versions you have
>>> found, sparing you a lot disk space and download bandwidth.
>>> git fetch linux-stable refs/tags/v4.5.4:refs/tags/v4.6.1
>>>
>>> https://wiki.archlinux.org/index.php/Kernels/Traditional_compilation
>>> Cherrypicked the Archwiki for the following:
>>>
>>> Install build requirements:
>>> pacman -S base-devel xmlto docbook-xsl kmod inetutils bc
>>>
>>> Copy your current kernel configuration:
>>> zcat /proc/config.gz > .config
>>>
>>> Back to business: You should now have build tools and a configuration
>>> available.
>>>
>>> git bisect start
>>> git bisect bad v4.5.4
>>> git bisect good v4.6.1
>>>
>>> git will now checkout a commit inbetween this range, which requires that
>>> you repeat the following steps:
>>>
>>> make olddefconfig
>>> make -j<number-of-processor-cores> -l<number-of-processor-cores>.0
>>> make modules_install
>>> mount /boot (if required)
>>> make install
>>>
>>> Check which version you are now:
>>> git --describe tags
>>>
>>> mkinitcpio -g /boot/initramfs-<kernel major and minor versions>.img -k <kernel version without v>
>>> (Example for 4.5.4:
>>> mkinitcpio -g /boot/initramfs-45.img -k 4.5.4)
>>>
>>> grub-mkconfig -o /boot/grub/grub.cfg
>>> sudo systemctl reboot (or su -c 'systemctl reboot' if sudo is not installed)
>>>
>>> If the version works, cd to the kernel source again and do
>>> git bisect good
>>> otherwise
>>> git bisect bad
>>>
>>> Repeat the above steps from make olddefconfig.
>>> Bisect will print how much steps are left. Once it is finished it will
>>> print out the commit.
>>>
>>> Best regards,
>>> Manuel
>>>> Hello Alex,
>>>>
>>>>
>>>> thanks very much for showing some interest. I have found an archive of
>>>> older arch kernels and can confirm, the last working kernel is:
>>>>
>>>> Linux kvmother 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST
>>>> 2016 x86_64 GNU/Linux
>>>>
>>>> the next kernel release from the arch team would be according to the
>>>> archive:
>>>>
>>>> Linux kvmother 4.6.1-1-ARCH #1 SMP PREEMPT Thu Jun 2 07:17:31 CEST
>>>> 2016 x86_64 GNU/Linux
>>>>
>>>> and this already does not work any more. Also crosschecked to 4.6.5-1,
>>>> no change and of course none with 4.8.x either.
>>>>
>>>> Installed and reinstalled both (4.5 and 4.6) multiple times, including
>>>> power off and hard reset between kernels, and the results are
>>>> absolutelty consistent.
>>>>
>>>> Suggests, that either some bug or some required configuration change I
>>>> am not aware of has been introduced with Kernel 4.6.
>>>>
>>>> Unfortunately I do not know enough about programming at all to bring
>>>> it down to a certain commit (not to look for that), but if there is
>>>> anything I could do, just let me know. please.
>>>>
>>>>
>>>> Thanks again
>>>>
>>>> Ede
>>>>
>>>>
>>>> Am 06.01.2017 um 00:30 schrieb Alex Williamson:
>>>>> On Thu, 5 Jan 2017 19:14:29 +0100
>>>>> Ede Wolf <listac at nebelschwaden.de> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Running arch, I am having a windows XP guest, to which I am passing
>>>>>> through a PCIe Parallel Card, that again talks to a device that
>>>>>> unfortunately is very picky about interrupts and more so the interrupt
>>>>>> setting within Windows XP for that parallel port.
>>>>>>
>>>>>> For a short explanation: Windows XP offers 3 ways to operate the
>>>>>> parallel port:
>>>>>> "never use an interrupt"
>>>>>> "try not to use an interrupt"
>>>>>> "Use any interrupt assigned to that port"
>>>>>>
>>>>>> My device requires the last option, otherwise communication does simply
>>>>>> not work, albeit the device itself is detected. So it seems, that
>>>>>> whatever setting I choose within windows xp, it is now ignored and does
>>>>>> not make any difference any more.
>>>>>>
>>>>>> However, it used to work perfectly fine up to Kernel 4.5. or 4.6, I do
>>>>>> not remember exactly, but does not work any more with 4.8. Skipped 4.7
>>>>>> for sure.
>>>>>>
>>>>>> Booting into the 4.4-lts kernel makes things work as expected, booting
>>>>>> into 4.8.x and communication is broken again. Can be repeated at will
>>>>>> with consistently the same results and holds true now for several
>>>>>> incarnations of the 4.8 kernel the archlinux team has provided so far.
>>>>>>
>>>>>> Now I am wondering: Is there any compelling configuration change that I
>>>>>> am not aware of or is this simply a bug? And if, is this related to vfio
>>>>>> or other parts of the kernel and this the wrong place?
>>>>>>
>>>>>> Thanks for any help
>>>>>
>>>>> Any chance you could narrow down where this broke a little further,
>>>>> perhaps even bisecting the kernel to a specific commit?  Thanks,
>>>>>
>>>>> Alex
>>>>>
>>>>
>>>> _______________________________________________
>>>> vfio-users mailing list
>>>> vfio-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
>> _______________________________________________
>> vfio-users mailing list
>> vfio-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users