[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0912221137380.29381@makko.or.mcafeemobile.com>
Date: Tue, 22 Dec 2009 11:39:55 -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>,
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 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 :)
> 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?
- 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