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
| ||
|
Date: Tue, 22 Dec 2009 17:05:10 -0800 (PST) From: Davide Libenzi <davidel@...ilserver.org> To: Gregory Haskins <gregory.haskins@...il.com> cc: Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>, kvm@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org, "alacrityvm-devel@...ts.sourceforge.net" <alacrityvm-devel@...ts.sourceforge.net> Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33 On Tue, 22 Dec 2009, Gregory Haskins wrote: > On 12/22/09 2:39 PM, Davide Libenzi wrote: > > On Tue, 22 Dec 2009, Gregory Haskins wrote: > > > >> On 12/22/09 1:53 PM, Avi Kivity wrote: > >>> I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did not reply. > >>> > >> > >> BTW: the ioeventfd issue just fell through the cracks, so sorry about > >> that. Note that I have no specific issue with irqfd ever since the > >> lockless IRQ injection code was added. > >> > >> ioeventfd turned out to be suboptimal for me in the fast path for two > >> reasons: > >> > >> 1) the underlying eventfd is called in atomic context. I had posted > >> patches to Davide to address that limitation, but I believe he rejected > >> them on the grounds that they are only relevant to KVM. > > > > I thought we addressed this already, in the few hundreds of email we > > exchanged back then :) > > We addressed the race conditions, but not the atomic callbacks. I can't > remember exactly what you said, but the effect was "no", so I dropped it. ;) > > This was the thread. > > http://www.archivum.info/linux-kernel@vger.kernel.org/2009-06/08548/Re:_[KVM-RFC_PATCH_1_2]_eventfd:_add_an_explicit_srcu_based_notifier_interface Didn't that ended up in schedule_work() being just fine, and no need was there for pre-emptible callbacks? > >> 2) it cannot retain the data field passed in the PIO. I wanted to have > >> one vector that could tell me what value was written, and this cannot be > >> expressed in ioeventfd. > > > > Like might have hinted in his reply, couldn't you add data support to the > > ioeventfd bits in KVM, instead of leaking them into mainline eventfd? > > > > Perhaps, or even easier I could extend xinterface. Which is what I did ;) > > The problem with the first proposal is that you would no longer actually > have an eventfd based mechanism...so any code using ioeventfd (like > Michael Tsirkin's for instance) would break. At that point, the KVM eventfd can take care of thing so that Michael bits do not break. - Davide -- 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/
Powered by blists - more mailing lists