qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).