Message ID | 1391548666-5513-1-git-send-email-david.marchand@6wind.com |
---|---|
State | New |
Headers | show |
Hello, Can someone take a look at my previous email and tell me if my patch is just wrong ? Thank you.
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.marchand@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.marchand@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 > > >
Hello Cam, On Thu, Feb 13, 2014 at 7:58 PM, Cam Macdonell <cam@cs.ualberta.ca> wrote: > 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. > > Actually, the first thing I tried, when I encountered the problem, was to remove qemu_chr_fe_claim_no_fail(), and it worked. In HEAD, ivshmem seems to be the only place where qemu_chr_open_eventfd() is used : $ git grep qemu_chr_open_eventfd hw/misc/ivshmem.c: chr = qemu_chr_open_eventfd(eventfd); include/sysemu/char.h:CharDriverState *qemu_chr_open_eventfd(int eventfd); qemu-char.c:CharDriverState *qemu_chr_open_eventfd(int eventfd) I suppose my change is not that impacting :-) Regards,
Hello all, On Fri, Feb 14, 2014 at 1:16 PM, David Marchand <david.marchand@6wind.com>wrote: > > In HEAD, ivshmem seems to be the only place where qemu_chr_open_eventfd() > is used : > $ git grep qemu_chr_open_eventfd > hw/misc/ivshmem.c: chr = qemu_chr_open_eventfd(eventfd); > include/sysemu/char.h:CharDriverState *qemu_chr_open_eventfd(int eventfd); > qemu-char.c:CharDriverState *qemu_chr_open_eventfd(int eventfd) > > I suppose my change is not that impacting :-) > Since this change has no impact, can it be pulled in current git tree ? Thanks.
On Mon, Feb 17, 2014 at 12:52 PM, David Marchand <david.marchand@6wind.com>wrote: > > Since this change has no impact, can it be pulled in current git tree ? > > ping http://patchwork.ozlabs.org/patch/316785/
On 02/21/2014 05:10 PM, David Marchand wrote: > On Mon, Feb 17, 2014 at 12:52 PM, David Marchand > <david.marchand@6wind.com <mailto:david.marchand@6wind.com>> wrote: > > > Since this change has no impact, can it be pulled in current git tree ? > > > ping > > http://patchwork.ozlabs.org/patch/316785/ ping
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
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.marchand@6wind.com> --- qemu-char.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)