linux-kernel - Re: [GIT PULL] KVM fixes for 3.5-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <500118F1.8060300@web.de>
Date:	Sat, 14 Jul 2012 09:00:01 +0200
From:	Jan Kiszka <jan.kiszka@....de>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	KVM list <kvm@...r.kernel.org>
Subject: Re: [GIT PULL] KVM fixes for 3.5-rc6

On 2012-07-14 04:25, Thomas Gleixner wrote:
> On Fri, 13 Jul 2012, Thomas Gleixner wrote:
>> On Fri, 13 Jul 2012, Linus Torvalds wrote:
>>> On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
>>> <torvalds@...ux-foundation.org> wrote:
>>> At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be
>>> improved. The fact that the KVM people think that the extra overhead
>>> of IRQF_ONESHOT is a bad thing for MSI interrupts makes me wonder if
>>> maybe this wouldn't be an area the irq layer couldn't be improved on.
>>> Maybe the MSI+IRQF_ONESHOT case could be improved. Because MSI is kind
>>> of fundamentally one-shot, since it's a message-based irq scheme.  So
>>> maybe the extra overhead is unnecessary in general, not just in this
>>> particular KVM case. Hmm?
>>>
>>> Thomas, see the commentary of a76beb14123a ("KVM: Fix device
>>> assignment threaded irq handler").
>>
>> Groan.
>>
>> We already discussed to let the irq chip (in this case MSI) tell the
>> core that it does not need the extra oneshot handling. That way the
>> code which requests an threaded irq with the NULL primary handler
>> works on both MSI and normal interrupts.
> 
> That's the kind of stuff which makes me go berserk, and just for the
> record: the most complaints I get for going berserk are coming from
> the virt folks.
> 
> I really can't understand why the virt folks think they are
> special and do not have to talk to core maintainers.
> 
> Back then when I was doing the big irq cleanup, virt crap stood out by
> far with the most idiotic^Wcreative "workarounds". Of course nobody
> complained about me being moronic enough to come up with generic
> solutions for their problems.
> 
> Though especially that commit including its changelog proves once
> again the ignorance and desinterest of the virt crowd in solving
> problems which are not only relevant to themself.
> 
> I whish you'd just refused to pull that nonsense and instead made them
> talk to those folks who had a proper solution in mind already.
> 
> In fact we could have solved that proper weeks ago, if only people
> would have raised the issue.

June 1: http://thread.gmane.org/gmane.linux.kernel/1306742

The proper solution for us will be conditional direct IRQ delivery
anyway [1], but those patches were not considered ready for 3.5.

This patch here is a workaround to unbreak devices assignment in 3.5
after the IRQ layer changes without regressing noticeable /wrt overhead.

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/92249


Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)