From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET Date: Wed, 20 Jul 2011 11:19:30 +0300 Message-ID: <4E268F92.5000704@redhat.com> References: <1309927078-5983-1-git-send-email-levinsasha928@gmail.com> <1309927078-5983-5-git-send-email-levinsasha928@gmail.com> <4E26407D.8040108@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sasha Levin , kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti , "Michael S. Tsirkin" , Pekka Enberg To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:3907 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750745Ab1GTITo (ORCPT ); Wed, 20 Jul 2011 04:19:44 -0400 In-Reply-To: <4E26407D.8040108@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 07/20/2011 05:42 AM, Anthony Liguori wrote: > > I suspect a normal uart is a bad use case for this. > > The THR can only hold a single value, a guest is not supposed to write > to the THR again until the THRE flag in the LSR is set which indicates > that the THR is empty. > > In fact, when THRE is raised, the device emulation should raise an > interrupt and that's what should trigger the guest to write another > value to the THR. > > So in practice, I don't see how it would work without relying on some > specific behavior of the current Linux uart guest code. > > But that said, I think this is an interesting mechanism. I'd be > curious how well it worked for VGA planar access which is what the > current coalesced I/O is most useful for. Probably the interesting use case is to forward an entire BAR to a separate process or thread, perhaps implemented in the kernel. However synchronization will be an issue - a PCI read is supposed to flush all pending PCI writes, and this is hard to enforce when the socket consumers are out of process. -- error compiling committee.c: too many arguments to function