linux-kernel - RE: [kvm-devel] [RFC] Deferred interrupt handling.

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:	Wed, 18 Jul 2007 09:36:39 -0700
From:	"Dor Laor" <dor.laor@...ranet.com>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>, "Or Sagi" <ors@...is.com>
Cc:	<kvm-devel@...ts.sourceforge.net>, <linux-kernel@...r.kernel.org>
Subject: RE: [kvm-devel] [RFC] Deferred interrupt handling.

>> In particular, this requires interrupt handling to be done by the
>guest --
>> The host shouldn't load the corresponding device driver or otherwise
>access
>> the device. Since the host kernel is not aware of the device
semantics
>it
>> cannot acknowledge the interrupt at the device level.
>
>Tricky indeed.
>
>> As far as the host kernel is concerned the VM is a user level
process.
>We
>> require the ability to forward interrupt handling to such entities.
>The
>> current kernel interrupt handling path doesn't allow deferring
>interrupt
>> handling _and_ acknowledgement.
>
>We don't support this model at all, and it doesn't appear to work
>anyway.
>
>> 0. Adding an IRQ_DEFERRED mechanism to the interrupt handling path.
>ISRs
>> returning IRQ_DEFERRED will keep the interrupt masked until future
>> acknowledge.
>
>Deadlock. If you get an IRQ for a guest and you block the IRQ until the
>guest handles it you may (eg if the IRQ is shared) get priority
>inversion
>with another interrupt source on the same line the guest requires first
>(eg disks and other I/O)

What if we will force the specific device to the end of the list. Once
IRQ_NONE was returned by the other devices, we will mask the irq,
forward the irq to the guest, issue a timer for 1msec. Motivation:
1msec is long enough for the guest to ack the irq + host unmask the irq
+
cancell the timer. (ping round-trip for a guest is about 100msec)
If the timer poped, it will unmask irqs + run over the device list to
check
whether one of them has a pending irq.

This will solve the deadlock possiblity in a small price of potential
latency.

...

>> Any ideas ? Thoughts ?
>
>Mask the interrupt in the main kernel, pass an event of some kind to
the
>guest. You can describe most devices from guest to kernel in a safe
form
>as
>
>device, bar, offset, register size, mask, bits to set, bits to clear
>
>(or bits to test when deciding if it is the irq source)
>

The problem is that each device has its own bits and it cannot be a
general solution.
Except that the device driver inside the guest should be changed because
the host already
disabled the irq/status for them.

I know the above solution in not neat but we do want to contribute it.
Any other ideas are welcome,
10x, Dor.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/