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

Avi Kivity
2011-07-20T08:19:44Z

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