Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET

[Avi Kivity <avi@redhat.com>]

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