Hi David,
I'm not sure which is the correct approach. You could either do what you
did or you could simply remove the qemu_chr_fe_claim_no_fail() from
ivshmem.c. I'm not sure how your change impacts other devices.
Sincerely,
Cam
On Tue, Feb 4, 2014 at 2:17 PM, David Marchand <david.march...@6wind.com>wrote:
> Hello,
>
> First of all, this is a pure RFC patch, I did not take too much time to
> dig into
> qemu source code to find the right solution, but since
> qemu_chr_open_eventfd()
> is only used by the code I was looking at, here is a patch.
>
>
> When trying to use a ivshmem server with qemu, ivshmem init code tries to
> create a CharDriverState object for each eventfd retrieved from the server.
> To create this object, a call to qemu_chr_open_eventfd() is done.
> Right after this, before adding a frontend, qemu_chr_fe_claim_no_fail() is
> called.
> qemu_chr_open_eventfd() does not set avail_connections to 1, so no
> frontend can
> be associated because qemu_chr_fe_claim_no_fail() makes qemu stop right
> away.
>
> I suppose this problem comes from 456d60692310e7ac25cf822cc1e98192ad636ece
> "qemu-char: Call fe_claim / fe_release when not using qdev chr properties".
>
> Fix this, by setting avail_connections to 1 in qemu_chr_open_eventfd().
>
> Signed-off-by: David Marchand <david.march...@6wind.com>
> ---
> qemu-char.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/qemu-char.c b/qemu-char.c
> index 30c5a6a..c0adb04 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -2492,7 +2492,12 @@ static gboolean tcp_chr_read(GIOChannel *chan,
> GIOCondition cond, void *opaque)
> #ifndef _WIN32
> CharDriverState *qemu_chr_open_eventfd(int eventfd)
> {
> - return qemu_chr_open_fd(eventfd, eventfd);
> + CharDriverState *chr = qemu_chr_open_fd(eventfd, eventfd);
> +
> + if (chr)
> + chr->avail_connections = 1;
> +
> + return chr;
> }
> #endif
>
> --
> David Marchand
>
>
>
