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

Sat Jan 14 22:18:52 UTC 2017

Hi Feng Wu,

Please see the device assignment interrupt regression described in this
thread:

https://www.redhat.com/archives/vfio-users/2017-January/msg00004.html

As seen below, Ede has bisected back to commit 520040146a0a as
introducing this regression.

Ede, thanks for performing the bisect.  For further validation, this
commit introduced the "vector_hashing" module option to KVM which
appears to disable the new behavior.  Can you try loading the kvm
module with vector_hashing=0, ex.

modprobe.d/local.conf:
options kvm vector_hashing=0

(followed by reboot) to verify?  Thanks,

Alex

On Sat, 14 Jan 2017 21:52:45 +0100
Ede Wolf <listac at nebelschwaden.de> wrote:

> Hello,
> 
> it seems, we have a result! Hooray. Unless I've done something wrong, 
> which is not unlikely at all. Which ever way, what will be next?
> 
> But before the late braking news, thanks to Laszlo for further detailed 
> information and of course for the heads up on the spelling. After 
> writing "dissecting" correctly, google was much more friendly. 
> Surprisingly... a bit embarassing that I cannot read properly, but once 
> you've made up your mind, one tends to read what he thinks has been 
> written.
> 
> Other issues: git fetch did not work for me, as it downloads a binary 
> repository, that of course cannot be configured or compiled.
> So I choose git clone, but have not been able to limit the tags. If 
> somebody knows how to do that, I am all ear.
> Also the required Mergebase took some time to get along with. Not sure 
> that I've dealt correctly with it (at the beginning of the full log, in 
> case someone wants to verify).
> 
> Back on topic, the last two entries, that by description fit just 
> perfectly. Very sorry for having forgotten to set the language to "C" 
> beforehand. I hope it's still clear. Otherwise I'll translate.
> The upper cases are only for this mail.
> 
> 
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-12-g23a1c2579b57
> #[root at archbuild linux-stable]# git bisect GOOD v4.5-rc3-12-g23a1c2579b57
> #binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt)
> #[6228a0da805792c2f25b32e9b926d0810a6648ab] KVM: x86: Add 
> lowest-priority support for vt-d posted-interrupts
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-14-g6228a0da8057
> #[root at archbuild linux-stable]# git bisect BAD v4.5-rc3-14-g6228a0da8057
> #binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 0 Schritte)
> #[520040146a0af36f7875ec06b58f44b19a0edf53] KVM: x86: Use vector-hashing 
> to deliver lowest-priority interrupts
> #[root at archbuild linux-stable]#
> 
> 
> In short, while Vector Linux is quite cool, vector hashing seems not to 
> be. Maybe Mr. Wu did not imagine someone still is using an AMD CPU, as I 
> do.
> 
> # -----------------
> 
> [root at archbuild linux-stable]# git describe --tag
> v4.5-rc3-13-g520040146a0a
> [root at archbuild linux-stable]# git bisect bad v4.5-rc3-13-g520040146a0a
> 520040146a0af36f7875ec06b58f44b19a0edf53 is the first bad commit
> commit 520040146a0af36f7875ec06b58f44b19a0edf53
> Author: Feng Wu <feng.wu at intel.com>
> Date:   Mon Jan 25 16:53:33 2016 +0800
> 
>      KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
> 
>      Use vector-hashing to deliver lowest-priority interrupts, As an
>      example, modern Intel CPUs in server platform use this method to
>      handle lowest-priority interrupts.
> 
>      Signed-off-by: Feng Wu <feng.wu at intel.com>
>      Reviewed-by: Radim Krčmář <rkrcmar at redhat.com>
>      Signed-off-by: Paolo Bonzini <pbonzini at redhat.com>
> 
> :040000 040000 f1d833ca902832009798f3aacdf1ddd4159e4202 
> 3130cfbde26ed6c4f0b2fae55c9670223e0ff87d M      arch
> 
> # -----------------
> 
> 
> And finally the somewhat (some early, all bad sects are missing) 
> complete log. Again thanks very much for all that helped so far:
> 
> #[root at archbuild src]# git init
> #[root at archbuild src]# git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> #[root at archbuild src]# cd linux-stable/
> #[root at archbuild linux-stable]# git bisect start
> #[root at archbuild linux-stable]# git bisect good v4.5.7
> #[root at archbuild linux-stable]# git bisect bad v4.6
> #binäre Suche: eine Merge-Basis muss geprüft werden
> #[b562e44f507e863c6792946e4e1b1449fbbac85d] Linux 4.5
> #[root at archbuild linux-stable]# git bisect good 
> b562e44f507e863c6792946e4e1b1449fbbac85d
> #binäre Suche: danach noch 8131 Commits zum Testen übrig (ungefähr 13 
> Schritte)
> #[6b5f04b6cf8ebab9a65d9c0026c650bb2538fd0f] Merge branch 'for-4.6' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
> #[root at archbuild linux-stable]# git bisect good v4.5.7
> #binäre Suche: danach noch 8131 Commits zum Testen übrig (ungefähr 13 
> Schritte)
> #[6b5f04b6cf8ebab9a65d9c0026c650bb2538fd0f] Merge branch 'for-4.6' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
> #[root at archbuild linux-stable]#
> 
> # ...
> 
> #============================
> #[root at archbuild linux-stable]# git bisect bad v4.5-3326-g96b9b1c95660
> #binäre Suche: danach noch 1605 Commits zum Testen übrig (ungefähr 11 
> Schritte)
> #[277edbabf6fece057b14fb6db5e3a34e00f42f42] Merge tag 
> 'pm+acpi-4.6-rc1-1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> #============================
> #linux-stable]# git describe --tag
> #v4.5-1720-g277edbabf6fe
> #[root at archbuild linux-stable]# git bisect bad v4.5-1720-g277edbabf6fe
> #binäre Suche: danach noch 879 Commits zum Testen übrig (ungefähr 10 
> Schritte)
> #[5ca5446ec5ba5e79a6f271cd026bb153d6850fcc] Merge tag 'pinctrl-v4.6-1' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-840-g5ca5446ec5ba
> #[root at archbuild linux-stable]# git bisect good v4.5-840-g5ca5446ec5ba
> #binäre Suche: danach noch 356 Commits zum Testen übrig (ungefähr 9 
> Schritte)
> #[10dc3747661bea9215417b659449bb7b8ed3df2c] Merge tag 'for-linus' of 
> git://git.kernel.org/pub/scm/virt/kvm/kvm
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-1363-g10dc3747661b
> #[root at archbuild linux-stable]# git bisect bad v4.5-1363-g10dc3747661b
> #binäre Suche: danach noch 255 Commits zum Testen übrig (ungefähr 8 
> Schritte)
> #[13f6f62f61b4d3d5f45bed889128bb7ff3fda5ed] Merge tag 'rtc-4.6' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-1107-g13f6f62f61b4
> #[root at archbuild linux-stable]# git bisect good v4.5-1107-g13f6f62f61b4
> #binäre Suche: danach noch 142 Commits zum Testen übrig (ungefähr 7 
> Schritte)
> #[bb9eadf0c35f2e7eb5ca6468f46ebb7473b85537] KVM: MMU: micro-optimize 
> gpte_access
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-123-gbb9eadf0c35f
> #[root at archbuild linux-stable]# git bisect bad v4.5-rc3-123-gbb9eadf0c35f
> #binäre Suche: danach noch 66 Commits zum Testen übrig (ungefähr 6 Schritte)
> #[433da86023f866820e9bcd7f0889d944005d311c] KVM: async_pf: use 
> list_first_entry
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-56-g433da86023f8
> #[root at archbuild linux-stable]# git bisect bad v4.5-rc3-56-g433da86023f8
> #binäre Suche: danach noch 22 Commits zum Testen übrig (ungefähr 5 Schritte)
> #[8a08b9c7379dc881ff5f00c086877353888a982f] KVM: s390: usage hint for 
> adapter mappings
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-33-g8a08b9c7379d
> #[root at archbuild linux-stable]# git bisect bad v4.5-rc3-33-g8a08b9c7379d
> #binäre Suche: danach noch 11 Commits zum Testen übrig (ungefähr 4 Schritte)
> #[0e8bc06a2fbb4d6b688baa8e2416cd07f9453595] KVM: s390: PSW forwarding / 
> rewinding / ilc rework
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-21-g0e8bc06a2fbb
> #[root at archbuild linux-stable]# git bisect bad v4.5-rc3-21-g0e8bc06a2fbb
> #binäre Suche: danach noch 5 Commits zum Testen übrig (ungefähr 3 Schritte)
> #[b6ce978067e75187d3c30f59b60d390a29374fab] KVM/VMX: Add host irq 
> information in trace event when updating IRTE for posted interrupts
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-15-gb6ce978067e7
> #[root at archbuild linux-stable]# git bisect bad v4.5-rc3-15-gb6ce978067e7
> #binäre Suche: danach noch 2 Commits zum Testen übrig (ungefähr 1 Schritt)
> #[23a1c2579b575b228a6c685dfe93f296d3d5e0e1] KVM: Recover IRTE to 
> remapped mode if the interrupt is not single-destination
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-12-g23a1c2579b57
> #[root at archbuild linux-stable]# git bisect good v4.5-rc3-12-g23a1c2579b57
> #binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt)
> #[6228a0da805792c2f25b32e9b926d0810a6648ab] KVM: x86: Add 
> lowest-priority support for vt-d posted-interrupts
> #[root at archbuild linux-stable]#
> #============================
> #[root at archbuild linux-stable]# git describe --tag
> #v4.5-rc3-14-g6228a0da8057
> #[root at archbuild linux-stable]# git bisect bad v4.5-rc3-14-g6228a0da8057
> #binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 0 Schritte)
> #[520040146a0af36f7875ec06b58f44b19a0edf53] KVM: x86: Use vector-hashing 
> to deliver lowest-priority interrupts
> #[root at archbuild linux-stable]#
> 
> 
> 
> 
> 
> Am 12.01.2017 um 19:49 schrieb Laszlo Ersek:
> > On 01/12/17 19:21, Ede Wolf wrote:  
> >> Besides my fighting with git, is it correct, that the working kernel is
> >> labeld "bad", while the non working one "good"? May very well possible
> >> for the workflow of dissect, just want to confirm, please
> >>  
> >>> git bisect start
> >>> git bisect bad v4.5.4
> >>> git bisect good v4.6.1  
> >
> > No. git-bisect always locates a regression, that is, the first commit
> > that introduces a bug. Where things go from right to wrong. If this
> > matches your situation (old version works, new version breaks), simply
> > use the "good" and "bad" command line arguments verbatim.
> >
> > Now, if you are looking for a commit that fixes a known bug, i.e., old
> > version is broken, new version works, but you don't exactly know what
> > fixed it, then you have to invert the meanings. Whenever the commit
> > under testing works, you have to say "bad", and whenever it breaks, you
> > have to say "good". More modern git versions help automate this (for
> > less boggling of the mind) with "git bisect terms". (See the manual.)
> > With older git versions, git command aliases, shell aliases, or small
> > wrapper scripts can hide the confusion.
> >
> > Given that you are facing a real regression, you should use the good/bad
> > terms verbatim. From your earlier email, "4.5.7" works, "4.6" breaks,
> > hence you should qualify the former with "good", and the latter with "bad".
> >
> > Also, the word is "bisect", not "dissect".
> >
> > https://en.wiktionary.org/wiki/bisect
> > https://en.wiktionary.org/wiki/dissect
> >
> > git-bisect performs a binary search, halving commit ranges. Hence the
> > "bi" in "bisect".
> >
> > Laszlo
> >  
> 
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users