From: Thomas Huth <thuth@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>,
lvivier@redhat.com, paulus@samba.org, groug@kaod.org
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] spapr: Implement bug in spapr-vty device to be compatible with PowerVM
Date: Tue, 21 Nov 2017 08:27:51 +0100 [thread overview]
Message-ID: <9da2b91f-215d-654f-a05b-76a0f898e6a7@redhat.com> (raw)
In-Reply-To: <20171120071423.11693-1-david@gibson.dropbear.id.au>
On 20.11.2017 08:14, David Gibson wrote:
> The spapr-vty device implements the PAPR defined virtual console,
> which is also implemented by IBM's proprietary PowerVM hypervisor.
>
> PowerVM's implementation has a bug where it inserts an extra \0 after
> every \r going to the guest. Because of that Linux's guest side
> driver has a workaround which strips \0 characters that appear
> immediately after a \r.
Ouch.
I wonder whether it would make more sense to change the guest side
driver to apply the workaround only if it's really running under
PowerVM...? E.g. what if the PowerVM bug ever gets fixed one day?
> That means that when running under qemu, sending a binary stream from
> host to guest via spapr-vty which happens to include a \r\0 sequence
> will get corrupted by that workaround.
>
> To deal with that, this patch duplicates PowerVM's bug, inserting an
> extra \0 after each \r. Ugly, but the best option available.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> hw/char/spapr_vty.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/hw/char/spapr_vty.c b/hw/char/spapr_vty.c
> index 0fa416ca6b..a95e5e91a7 100644
> --- a/hw/char/spapr_vty.c
> +++ b/hw/char/spapr_vty.c
> @@ -58,6 +58,24 @@ static int vty_getchars(VIOsPAPRDevice *sdev, uint8_t *buf, int max)
>
> while ((n < max) && (dev->out != dev->in)) {
> buf[n++] = dev->buf[dev->out++ % VTERM_BUFSIZE];
> +
> + /* PowerVM's vty implementation has a bug where it inserts a
> + * \0 after every \r going to the guest. Existing guests have
> + * a workaround for this which removes every \0 immediately
> + * following a \r, so here we make ourselves bug-for-bug
> + * compatible, so that the guest won't drop a real \0-after-\r
> + * that happens to occur in a binary stream. */
> + if (buf[n-1] == '\r') {
> + if (n < max) {
> + buf[n++] = '\0';
> + } else {
> + /* No room for the extra \0, roll back and try again
> + * next time */
> + dev->out--;
> + n--;
> + break;
> + }
> + }
> }
>
> qemu_chr_fe_accept_input(&dev->chardev);
>
Code looks fine to me, so:
Reviewed-by: Thomas Huth <thuth@redhat.com>
next prev parent reply other threads:[~2017-11-21 7:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-20 7:14 [Qemu-devel] [PATCH] spapr: Implement bug in spapr-vty device to be compatible with PowerVM David Gibson
2017-11-20 7:18 ` no-reply
2017-11-21 0:25 ` David Gibson
2017-11-21 7:27 ` Thomas Huth [this message]
2017-11-21 9:45 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
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=9da2b91f-215d-654f-a05b-76a0f898e6a7@redhat.com \
--to=thuth@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=lvivier@redhat.com \
--cc=paulus@samba.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@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).