linux-kernel - Re: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-through devices

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]

Date:	Sat, 04 Dec 2010 15:54:04 +0100
From:	Jan Kiszka <jan.kiszka@....de>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Avi Kivity <avi@...hat.com>, Marcelo Tosatti <mtosatti@...hat.com>,
	linux-kernel@...r.kernel.org, kvm <kvm@...r.kernel.org>,
	Tom Lyon <pugs@...co.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH 0/5] KVM&genirq: Enable adaptive IRQ sharing for passed-through
 devices

Am 04.12.2010 15:41, Thomas Gleixner wrote:
> Jan,
> 
> On Sat, 4 Dec 2010, Jan Kiszka wrote:
> 
>> Am 04.12.2010 11:37, Thomas Gleixner wrote:
>>> On Sat, 4 Dec 2010, Jan Kiszka wrote:
>>> If interrupt is shared, then you want to keep the current behaviour:
>>>
>>>    disable at line level (IRQF_ONESHOT)
>>>    run handler thread (PCI level masking)
>>>    reenable at line level in irq_finalize_oneshot()
>>>    reenable at PCI level when guest is done
>>
>> If the interrupt is shared, we must mask at PCI level inside the primary
>> handler as we also have to support non-threaded users of the same line.
>> So we always have a transition line-level -> device-level
>> masking in a primary handler.
> 
> Sorry that left out the hard irq part. Of course it needs to do the
> PCI level masking in the primary one.
>  
>> reduce the latency. So both threaded and non-threaded cases should be
>> addressable by any approach.
> 
> The oneshot magic should work on non threaded cases as well. Needs
> some modifications, but nothing complex.
>  
>>> If interrupts are in flight accross request/free then this change
>>> takes effect when the next interrupt comes in.
>>
>> For registration, that might be too late. We need to synchronize on
>> in-flight interrupts for that line and then ensure that it gets enabled
>> independently of the registered user. That user may have applied
>> outdated information, thus would block the line for too long if user
>> space decides to do something else.
> 
> No, that's really just a corner case when going from one to two
> handlers and I don't think it matters much. If you setup a new driver
> it's not really important whether that first thing comes in a few ms
> later.

The worst case remains infinite (user space never signals end of interrupt).

> 
> Also there is a pretty simple solution for this: The core code knows,
> that there is an ONESHOT interrupt in flight, so it simply can call

It doesn't synchronize the tail part against the masking in the
handler(s), that's driver business.

> the primary handler of that device with the appropriate flag set
> (maybe an additional one to indicate the transition) and let that deal
> with it. Needs some thought vs. locking and races, but that shouldn't
> be hard.

Yes, I thought about this kind of transition (re-invoking the existing
handler) already. We do need notification of the switch (at least for
exclusive->shared) as only the driver can migrate the masking for
in-flight interrupts.

Jan


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