From: Anthony Liguori <anthony@codemonkey.ws>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 4/8] qemu-char: Automatically do fe_open / fe_close on qemu_chr_add_handlers
Date: Mon, 25 Mar 2013 10:07:44 -0500 [thread overview]
Message-ID: <87boa7frgf.fsf@codemonkey.ws> (raw)
In-Reply-To: <51504E7A.8060006@redhat.com>
Hans de Goede <hdegoede@redhat.com> writes:
> Hi,
>
> On 03/25/2013 01:46 PM, Anthony Liguori wrote:
>> Hans de Goede <hdegoede@redhat.com> writes:
>>
>>> Most frontends can't really determine if the guest actually has the frontend
>>> side open. So lets automatically generate fe_open / fe_close as soon as a
>>> frontend becomes ready (as signalled by calling qemu_chr_add_handlers) /
>>> becomes non ready (as signalled by setting all handlers to NULL).
>>>
>>> And allow frontends which can actually determine if the guest is listening to
>>> opt-out of this.
>>
>> Could we change virtio-serial to delay calling add_handlers so that we
>> could not introduce this variable?
>
> Hmm, I was trying to avoid opening that can of worms. I've taken a quick look
> and there are 2 issues with doing this:
> 1) It will wreck havoc with CharDriverState.avail_connections, since that
> gets increased on a qemu_chr_add_handlers( NULL ), while it is decreased
> only once in hw/qdev-properties-system.c
>
> This can be fixed by moving the avail_connections++ to
> hw/qdev-properties-system.c: release_chr, which seems the sensible thing to
> do wrt nicely balancing out these calls anyways.
>
> 2) It will cause the virtio-console front-end to miss various events, such
> as backend open/close events.
>
> A backend open event will get "replayed" when qemu_chr_add_handlers( stuff )
> is called, causing a potential double open from the virtio-console pov
> (one before it called qemu_chr_add_handlers( NULL ), and one on the next
> add_handlers call). And a close or any other events happening while the
> frontend side is closed will be missed.
>
> I'll gladly add a patch fixing 1). to the next revision of this patchset,
> but given 2) I would prefer to stick with the explicit_fe_open flag and just
> register the handlers once.
Okay, seems reasonable.
REgards,
Anthony Liguori
>
> Regards,
>
> Hans
next prev parent reply other threads:[~2013-03-25 15:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-24 12:39 [Qemu-devel] [PATCH 1/8] RFC: chardev frontend open handling cleanup Hans de Goede
2013-03-24 12:39 ` [Qemu-devel] [PATCH 1/8] qemu-char: Rename opened to be_open Hans de Goede
2013-03-24 12:39 ` [Qemu-devel] [PATCH 2/8] qemu-char: Rename qemu_chr_generic_open to qemu_chr_be_generic_open Hans de Goede
2013-03-24 12:39 ` [Qemu-devel] [PATCH 3/8] qemu-char: Add fe_open tracking Hans de Goede
2013-03-25 12:45 ` Anthony Liguori
2013-03-25 13:07 ` Hans de Goede
2013-03-24 12:39 ` [Qemu-devel] [PATCH 4/8] qemu-char: Automatically do fe_open / fe_close on qemu_chr_add_handlers Hans de Goede
2013-03-25 12:46 ` Anthony Liguori
2013-03-25 13:17 ` Hans de Goede
2013-03-25 15:07 ` Anthony Liguori [this message]
2013-03-24 12:39 ` [Qemu-devel] [PATCH 5/8] qemu-char: Cleanup: consolidate fe_open/fe_close into fe_set_open Hans de Goede
2013-03-24 12:39 ` [Qemu-devel] [PATCH 6/8] qemu-char: Consolidate guest_close/guest_open into a set_fe_open callback Hans de Goede
2013-03-24 12:39 ` [Qemu-devel] [PATCH 7/8] virtio-serial: Consolidate guest_open/guest_close into set_guest_connected Hans de Goede
2013-03-24 12:39 ` [Qemu-devel] [PATCH 8/8] spice-qemu-char: Drop hackish vmc_register on spice_chr_write Hans de Goede
2013-03-25 9:56 ` [Qemu-devel] [PATCH 1/8] RFC: chardev frontend open handling cleanup Alon Levy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87boa7frgf.fsf@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=amit.shah@redhat.com \
--cc=hdegoede@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.