KVM: Directly inject interrupts via irqfd
in [Kernel]
|
Prev: [PATCH] mfd: fix check on unsigned in twl4030_configure_resource()
Next: [PATCH 03/12] Staging: rt28x0: remove private RTPRIV_IOCTL_SET ioctl
From: Gregory Haskins on 22 Oct 2009 11:20 Avi Kivity wrote: > On 10/21/2009 05:42 PM, Gregory Haskins wrote: >> I believe Avi, Michael, et. al. were in agreement with me on that design >> choice. I believe the reason is that there is no good way to do EOI/ACK >> feedback within the constraints of an eventfd pipe which would be >> required for the legacy pin-type interrupts. Therefore, we won't even >> bother trying. High-performance subsystems will use irqfd/msi, and >> legacy emulation can use the existing injection code (which includes the >> necessary feedback for ack/eoi). >> >> > > Right. But we don't actually prevent anyone using non-msi with irqfd, > which can trigger the bad lock usage from irq context, with a nice boom > afterwards. So we need to either prevent it during registration, or to > gracefully handle it afterwards. > Yeah, I was thinking about that after I initially responded to Gleb. I am thinking something along these lines: Provide a function that lets you query a GSI for whether it supports LOCKLESS or not. Then we can either do one of two things: 1) Check for the LOCKLESS attribute at irqfd registration, fail if not present 2) Cache the LOCKLESS attribute in the irqfd structure, and either go direct or defer to a workqueue depending on the flag. Thoughts? -Greg
From: Avi Kivity on 22 Oct 2009 11:30 On 10/22/2009 05:14 PM, Gregory Haskins wrote: > Yeah, I was thinking about that after I initially responded to Gleb. > > I am thinking something along these lines: > > Provide a function that lets you query a GSI for whether it supports > LOCKLESS or not. Then we can either do one of two things: > > 1) Check for the LOCKLESS attribute at irqfd registration, fail if not > present > This is the most practical path and leads to the smallest code. However it has the deficiency of exposing internal implementation details to userspace. In theory userspace could use msi and edge-triggered pic/ioapic interrupts equally well, it shouldn't have to know that we didn't bother to lockfree ioapic/pic. > 2) Cache the LOCKLESS attribute in the irqfd structure, and either go > direct or defer to a workqueue depending on the flag. > While this leads to larger code, it is more consistent. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Gregory Haskins on 22 Oct 2009 11:40
Avi Kivity wrote: > On 10/22/2009 05:14 PM, Gregory Haskins wrote: >> Yeah, I was thinking about that after I initially responded to Gleb. >> >> I am thinking something along these lines: >> >> Provide a function that lets you query a GSI for whether it supports >> LOCKLESS or not. Then we can either do one of two things: >> >> 1) Check for the LOCKLESS attribute at irqfd registration, fail if not >> present >> > > This is the most practical path and leads to the smallest code. However > it has the deficiency of exposing internal implementation details to > userspace. In theory userspace could use msi and edge-triggered > pic/ioapic interrupts equally well, it shouldn't have to know that we > didn't bother to lockfree ioapic/pic. > >> 2) Cache the LOCKLESS attribute in the irqfd structure, and either go >> direct or defer to a workqueue depending on the flag. >> > > While this leads to larger code, it is more consistent. > Yeah, I think you are right. Consider these two patches retracted, and I will rewrite it with this concept in place. Kind Regards, -Greg |