Patchwork chardev: add baud parameter for serial host device

login
register
mail settings
Submitter Peter Wu
Date June 8, 2013, 9:49 p.m.
Message ID <4543955.Y102znvq4W@al>
Download mbox | patch
Permalink /patch/249983/
State New
Headers show

Comments

Peter Wu - June 8, 2013, 9:49 p.m.
When QEMU starts, it always changes the serial port parameters including baud
rate. This confused my guest which thought it was outputting at 9600 baud while
it was in fact changed to 115200.

After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override the
default baud rate of 115200. Documentation is updated as well, so that users
know about the new `baud` parameter for `-serial` and `-chardev serial` (and its
alias `-chardev tty`).

Note that the baud option is not implemented for Windows. QEMU does not change
the default baud rate on Windows anyway. If somebody is going to implement it,
do not forget to update the documentation on "COM" devices which is also of
backend serial.

Signed-off-by: Peter Wu <lekensteyn@gmail.com>
---
 qapi-schema.json | 18 ++++++++++++++++--
 qemu-char.c      | 14 ++++++++------
 qemu-options.hx  | 14 +++++++++-----
 3 files changed, 33 insertions(+), 13 deletions(-)
Gerd Hoffmann - June 10, 2013, 5:56 a.m.
On 06/08/13 23:49, Peter Wu wrote:
> When QEMU starts, it always changes the serial port parameters including baud
> rate. This confused my guest which thought it was outputting at 9600 baud while
> it was in fact changed to 115200.
> 
> After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override the
> default baud rate of 115200.

I think we should just flip the default to 9600.  IIRC this is the
power-on default baud rate of the 8250 uart family, so this should be
the qemu default too.  If a guest wants to use a higher baudrate it has
to reprogram the uart anyway (and qemu will apply the guest changes to
the host uart).

cheers,
  Gerd
Peter Wu - June 10, 2013, 8:42 a.m.
On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
> On 06/08/13 23:49, Peter Wu wrote:
> > When QEMU starts, it always changes the serial port parameters including
> > baud rate. This confused my guest which thought it was outputting at 9600
> > baud while it was in fact changed to 115200.
> >
> > 
> >
> > After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override the
> > default baud rate of 115200.
> 
> I think we should just flip the default to 9600.  IIRC this is the
> power-on default baud rate of the 8250 uart family, so this should be
> the qemu default too.  If a guest wants to use a higher baudrate it has
> to reprogram the uart anyway (and qemu will apply the guest changes to
> the host uart).

FWIW, when I tried MODE.COM in ms-dos to change the baud rate, `stty -F 
/dev/ttyS0 -a` still reported 115200 baud. This is on Linux 3.9 if that 
matters. Besides this comment, any other feedback on the patch itself?

Regards,
Peter
Gerd Hoffmann - June 10, 2013, 12:58 p.m.
On 06/10/13 10:42, Peter Wu wrote:
> On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
>> On 06/08/13 23:49, Peter Wu wrote:
>>> When QEMU starts, it always changes the serial port parameters including
>>> baud rate. This confused my guest which thought it was outputting at 9600
>>> baud while it was in fact changed to 115200.
>>>
>>>
>>>
>>> After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override the
>>> default baud rate of 115200.
>>
>> I think we should just flip the default to 9600.  IIRC this is the
>> power-on default baud rate of the 8250 uart family, so this should be
>> the qemu default too.  If a guest wants to use a higher baudrate it has
>> to reprogram the uart anyway (and qemu will apply the guest changes to
>> the host uart).
> 
> FWIW, when I tried MODE.COM in ms-dos to change the baud rate, `stty -F 
> /dev/ttyS0 -a` still reported 115200 baud. This is on Linux 3.9 if that
> matters.

Hmm, with a linux guest changing the baudrate works just fine.  Any
chance mode.com takes a shortcut in case it thinks the rate didn't
change?  Does setting the speed first to 4800, then to 9600 work?

> Besides this comment, any other feedback on the patch itself?

Style is fine.  But it appears to paper over some bug, and I'd prefer to
find+fix the bug instead of allowing/requiring the user to set the baud
rate manually to the correct value.

cheers,
  Gerd
Andreas Färber - June 10, 2013, 1:23 p.m.
Am 10.06.2013 14:58, schrieb Gerd Hoffmann:
> On 06/10/13 10:42, Peter Wu wrote:
>> On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
>>> On 06/08/13 23:49, Peter Wu wrote:
>>>> When QEMU starts, it always changes the serial port parameters including
>>>> baud rate. This confused my guest which thought it was outputting at 9600
>>>> baud while it was in fact changed to 115200.
>>>>
>>>>
>>>>
>>>> After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override the
>>>> default baud rate of 115200.
>>>
>>> I think we should just flip the default to 9600.  IIRC this is the
>>> power-on default baud rate of the 8250 uart family, so this should be
>>> the qemu default too.  If a guest wants to use a higher baudrate it has
>>> to reprogram the uart anyway (and qemu will apply the guest changes to
>>> the host uart).
>>
>> FWIW, when I tried MODE.COM in ms-dos to change the baud rate, `stty -F 
>> /dev/ttyS0 -a` still reported 115200 baud. This is on Linux 3.9 if that
>> matters.
> 
> Hmm, with a linux guest changing the baudrate works just fine.  Any
> chance mode.com takes a shortcut in case it thinks the rate didn't
> change?  Does setting the speed first to 4800, then to 9600 work?
> 
>> Besides this comment, any other feedback on the patch itself?
> 
> Style is fine.  But it appears to paper over some bug, and I'd prefer to
> find+fix the bug instead of allowing/requiring the user to set the baud
> rate manually to the correct value.

Well, there's two instances of hardcoded 115200 baudrate: in the chardev
for the host and in the device for the guest - I don't see the latter
changed here:

hw/arm/nseries.c:    stw_raw(w ++, 115200);                     /* u32
console_speed */
hw/char/serial-isa.c:    s->baudbase = 115200;
hw/char/serial-pci.c:    s->baudbase = 115200;
hw/char/serial-pci.c:        s->baudbase = 115200;
hw/display/sm501.c:                       115200, chr,
DEVICE_NATIVE_ENDIAN);
hw/lm32/lm32_hwsetup.h:    hwsetup_add_u32(hw, 115200); /* baudrate */
hw/microblaze/petalogix_ml605_mmu.c:                   irq[5], 115200,
serial_hds[0], DEVICE_LITTLE_ENDIAN);
hw/mips/mips_mipssim.c:        serial_init(0x3f8, env->irq[4], 115200,
serial_hds[0],
hw/openrisc/openrisc_sim.c:                   115200, serial_hds[0],
DEVICE_NATIVE_ENDIAN);
hw/ppc/ppc405_boards.c:        bd.bi_baudrate = 115200;
hw/ppc/virtex_ml507.c:    serial_mm_init(address_space_mem,
0x83e01003ULL, 2, irq[9], 115200,
hw/sparc64/sun4u.c:                       NULL, 115200, serial_hds[i],
DEVICE_BIG_ENDIAN);
hw/xtensa/xtensa_lx60.c:            115200, serial_hds[0],
DEVICE_NATIVE_ENDIAN);
qemu-char.c:        check_speed(115200);
qemu-char.c:#ifdef B1152000
qemu-char.c:        check_speed(1152000);
qemu-char.c:        spd = B115200;
qemu-char.c:    tty_serial_init(fd, 115200, 'N', 8, 1);
slirp/slirp.h:#define DEFAULT_BAUD 115200

(The slirp define seems unused.)

So yes, MS-DOS will get reported from hardware that it is at 115200,
whatever you set for the chardev on the host side with your changes.
Thought I pointed you to that fact on IRC already...

Regards,
Andreas
Peter Wu - June 10, 2013, 1:28 p.m.
On Monday 10 June 2013 14:58:07 Gerd Hoffmann wrote:
> On 06/10/13 10:42, Peter Wu wrote:
> > On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
> >> On 06/08/13 23:49, Peter Wu wrote:
> >>> When QEMU starts, it always changes the serial port parameters including
> >>> baud rate. This confused my guest which thought it was outputting at
> >>> 9600
> >>> baud while it was in fact changed to 115200.
> >>> 
> >>> 
> >>> 
> >>> After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override
> >>> the
> >>> default baud rate of 115200.
> >> 
> >> I think we should just flip the default to 9600.  IIRC this is the
> >> power-on default baud rate of the 8250 uart family, so this should be
> >> the qemu default too.  If a guest wants to use a higher baudrate it has
> >> to reprogram the uart anyway (and qemu will apply the guest changes to
> >> the host uart).
> >
> > 
> >
> > FWIW, when I tried MODE.COM in ms-dos to change the baud rate, `stty -F 
> > /dev/ttyS0 -a` still reported 115200 baud. This is on Linux 3.9 if that
> > matters.
> 
> Hmm, with a linux guest changing the baudrate works just fine.  Any
> chance mode.com takes a shortcut in case it thinks the rate didn't
> change?  Does setting the speed first to 4800, then to 9600 work?

I can confirm that a Linux guest can correctly control the speed. At home I 
only have a USB serial, but that shouldn't matter.
1. stty -F /dev/ttyUSB0 reports 9600
2. Start QEMU using:
qemu-system-x86_64 -enable-kvm -m 1G -serial /dev/ttyUSB0 \
-cdrom ubuntu-12.04.1-desktop-amd64.iso
3. stty -F /dev/ttyUSB0 reports 115200 before booting the live CD
4. After boot, both the guest and host report 9600 again
5. Changing it using stty -F /dev/ttyS0 from the guest is also visible on both 
sides.

On ms-dos I observe with 1.4.1 and 1.5.0 that the baud rate *is* changed 
correctly with my USB serial converter. I will have to check with the serial 
printer again whether I made a mistake before. I did actually have to use 
`stty -F /dev/ttyS0 raw 9600` to avoid characters being eaten which caused the 
serial printer to spit out empty lines or hang.

Regards,
Peter

> > Besides this comment, any other feedback on the patch itself?
> 
> Style is fine.  But it appears to paper over some bug, and I'd prefer to
> find+fix the bug instead of allowing/requiring the user to set the baud
> rate manually to the correct value.
Peter Wu - June 10, 2013, 1:51 p.m.
On Monday 10 June 2013 15:28:32 Peter Wu wrote:
> On Monday 10 June 2013 14:58:07 Gerd Hoffmann wrote:
> > On 06/10/13 10:42, Peter Wu wrote:
> > > On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
> > >> On 06/08/13 23:49, Peter Wu wrote:
> > >>> When QEMU starts, it always changes the serial port parameters
> > >>> including
> > >>> baud rate. This confused my guest which thought it was outputting at
> > >>> 9600
> > >>> baud while it was in fact changed to 115200.
> > >>>
> > >>> 
> > >>> 
> > >>> 
> > >>>
> > >>> After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override
> > >>> the
> > >>> default baud rate of 115200.
> > >>
> > >> 
> > >>
> > >> I think we should just flip the default to 9600.  IIRC this is the
> > >> power-on default baud rate of the 8250 uart family, so this should be
> > >> the qemu default too.  If a guest wants to use a higher baudrate it has
> > >> to reprogram the uart anyway (and qemu will apply the guest changes to
> > >> the host uart).
> > >
> > > 
> > >
> > > FWIW, when I tried MODE.COM in ms-dos to change the baud rate, `stty -F 
> > > /dev/ttyS0 -a` still reported 115200 baud. This is on Linux 3.9 if that
> > > matters.
> >
> > 
> >
> > Hmm, with a linux guest changing the baudrate works just fine.  Any
> > chance mode.com takes a shortcut in case it thinks the rate didn't
> > change?  Does setting the speed first to 4800, then to 9600 work?
> 
> I can confirm that a Linux guest can correctly control the speed. At home I 
> only have a USB serial, but that shouldn't matter.
> 1. stty -F /dev/ttyUSB0 reports 9600
> 2. Start QEMU using:
> qemu-system-x86_64 -enable-kvm -m 1G -serial /dev/ttyUSB0 \
> -cdrom ubuntu-12.04.1-desktop-amd64.iso
> 3. stty -F /dev/ttyUSB0 reports 115200 before booting the live CD
> 4. After boot, both the guest and host report 9600 again
> 5. Changing it using stty -F /dev/ttyS0 from the guest is also visible on
> both  sides.
> 
> On ms-dos I observe with 1.4.1 and 1.5.0 that the baud rate *is* changed 
> correctly with my USB serial converter. I will have to check with the
> serial  printer again whether I made a mistake before. I did actually have
> to use `stty -F /dev/ttyS0 raw 9600` to avoid characters being eaten which
> caused the serial printer to spit out empty lines or hang.

Aha, I just checked that machine again and realised something. The serial 
cable has only four pins connected to a printer (DB9-DB25), namely RX, TX, DTR 
and RTS. The remaining cables are cut (originally it was a null modem cable, 
but that did not work with the printer).

So, what is the likely issue here? Having a printer instead of a serial 
console or the hardware (cables) missing some lines? FYI, when I set the speed 
and options manually after starting QEMU, the printer(s) work(s) as expected, 
otherwise I get garbage out.

Regards,
Peter
Eric Blake - June 15, 2013, 3:14 p.m.
On 06/08/2013 10:49 PM, Peter Wu wrote:
> When QEMU starts, it always changes the serial port parameters including baud
> rate. This confused my guest which thought it was outputting at 9600 baud while
> it was in fact changed to 115200.
> 
> After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override the
> default baud rate of 115200. Documentation is updated as well, so that users
> know about the new `baud` parameter for `-serial` and `-chardev serial` (and its
> alias `-chardev tty`).
> 
> Note that the baud option is not implemented for Windows. QEMU does not change
> the default baud rate on Windows anyway. If somebody is going to implement it,
> do not forget to update the documentation on "COM" devices which is also of
> backend serial.
> 
> Signed-off-by: Peter Wu <lekensteyn@gmail.com>
> ---

> +++ b/qapi-schema.json
> @@ -3186,7 +3186,7 @@
>  # Configuration info for device and pipe chardevs.
>  #
>  # @device: The name of the special file for the device,
> -#          i.e. /dev/ttyS0 on Unix or COM1: on Windows
> +#          i.e. /dev/parport0 on Unix.
>  # @type: What kind of device this is.
>  #
>  # Since: 1.4
> @@ -3194,6 +3194,20 @@
>  { 'type': 'ChardevHostdev', 'data': { 'device' : 'str' } }
>  
>  ##
> +# @ChardevSerial
> +#
> +# Configuration info for serial chardevs.
> +#
> +# @device: The name of the special file for the device,
> +#          i.e. /dev/ttyS0 on Unix or COM1: on Windows
> +# @baud: #optional baud rate to set for host device. (default 115200)
> +#
> +# Since: 1.5
> +##
> +{ 'type': 'ChardevSerial', 'data': { 'device' : 'str',
> +                                     '*baud': 'int' } }

Slick trick.  However, 1.5 is already released, so it is now since 1.6,
and furthermore...

> +
> +##
>  # @ChardevSocket:
>  #
>  # Configuration info for (stream) socket chardevs.
> @@ -3311,7 +3325,7 @@
>  { 'type': 'ChardevDummy', 'data': { } }
>  
>  { 'union': 'ChardevBackend', 'data': { 'file'   : 'ChardevFile',
> -                                       'serial' : 'ChardevHostdev',
> +                                       'serial' : 'ChardevSerial',

without introspection, libvirt has no idea whether 'baud' is supported
in the qemu it is talking to, other than trying and failing when talking
to older qemu.  This patch forms yet another reason why libvirt wants to
learn when we add optional parameters to a pre-existing QMP command.
Peter Wu - June 15, 2013, 3:25 p.m.
On Saturday 15 June 2013 16:14:23 Eric Blake wrote:
> On 06/08/2013 10:49 PM, Peter Wu wrote:
> > When QEMU starts, it always changes the serial port parameters including
> > baud rate. This confused my guest which thought it was outputting at 9600
> > baud while it was in fact changed to 115200.
> > 
> > After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override the
> > default baud rate of 115200. Documentation is updated as well, so that
> > users know about the new `baud` parameter for `-serial` and `-chardev
> > serial` (and its alias `-chardev tty`).
> > 
> > Note that the baud option is not implemented for Windows. QEMU does not
> > change the default baud rate on Windows anyway. If somebody is going to
> > implement it, do not forget to update the documentation on "COM" devices
> > which is also of backend serial.
> > 
> > Signed-off-by: Peter Wu <lekensteyn@gmail.com>
> > ---
> > 
> > +++ b/qapi-schema.json
> > @@ -3186,7 +3186,7 @@
> > 
> >  # Configuration info for device and pipe chardevs.
> >  #
> >  # @device: The name of the special file for the device,
> > 
> > -#          i.e. /dev/ttyS0 on Unix or COM1: on Windows
> > +#          i.e. /dev/parport0 on Unix.
> > 
> >  # @type: What kind of device this is.
> >  #
> >  # Since: 1.4
> > 
> > @@ -3194,6 +3194,20 @@
> > 
> >  { 'type': 'ChardevHostdev', 'data': { 'device' : 'str' } }
> >  
> >  ##
> > 
> > +# @ChardevSerial
> > +#
> > +# Configuration info for serial chardevs.
> > +#
> > +# @device: The name of the special file for the device,
> > +#          i.e. /dev/ttyS0 on Unix or COM1: on Windows
> > +# @baud: #optional baud rate to set for host device. (default 115200)
> > +#
> > +# Since: 1.5
> > +##
> > +{ 'type': 'ChardevSerial', 'data': { 'device' : 'str',
> > +                                     '*baud': 'int' } }
> 
> Slick trick.  However, 1.5 is already released, so it is now since 1.6,
Well, it was worth trying :-P Anyway, I do not mind if the patch is edited to 
have 1.6 instead 1.5. Do you want me to send a new patch just for this tiny 
change or will you edit it before applying? (perhaps after adding a note to 
the commit message)

> and furthermore...
> 
> > +
> > +##
> > 
> >  # @ChardevSocket:
> >  #
> >  # Configuration info for (stream) socket chardevs.
> > 
> > @@ -3311,7 +3325,7 @@
> > 
> >  { 'type': 'ChardevDummy', 'data': { } }
> >  
> >  { 'union': 'ChardevBackend', 'data': { 'file'   : 'ChardevFile',
> > 
> > -                                       'serial' : 'ChardevHostdev',
> > +                                       'serial' : 'ChardevSerial',
> 
> without introspection, libvirt has no idea whether 'baud' is supported
> in the qemu it is talking to, other than trying and failing when talking
> to older qemu.  This patch forms yet another reason why libvirt wants to
> learn when we add optional parameters to a pre-existing QMP command.

I have do not use libvirt, do you want me to do further things for this patch 
to get accepted? Or is it more a side-note?

Regards,
Peter
Eric Blake - June 15, 2013, 3:38 p.m.
On 06/15/2013 04:25 PM, Peter Wu wrote:
> On Saturday 15 June 2013 16:14:23 Eric Blake wrote:
>> On 06/08/2013 10:49 PM, Peter Wu wrote:
>>> When QEMU starts, it always changes the serial port parameters including
>>> baud rate. This confused my guest which thought it was outputting at 9600
>>> baud while it was in fact changed to 115200.
>>>
>>> After this patch, I can use `-serial /dev/ttyS0,baud=9600` to override the
>>> default baud rate of 115200. Documentation is updated as well, so that
>>> users know about the new `baud` parameter for `-serial` and `-chardev
>>> serial` (and its alias `-chardev tty`).
>>>
>>> Note that the baud option is not implemented for Windows. QEMU does not
>>> change the default baud rate on Windows anyway. If somebody is going to
>>> implement it, do not forget to update the documentation on "COM" devices
>>> which is also of backend serial.
>>>

>>> -                                       'serial' : 'ChardevHostdev',
>>> +                                       'serial' : 'ChardevSerial',
>>
>> without introspection, libvirt has no idea whether 'baud' is supported
>> in the qemu it is talking to, other than trying and failing when talking
>> to older qemu.  This patch forms yet another reason why libvirt wants to
>> learn when we add optional parameters to a pre-existing QMP command.
> 
> I have do not use libvirt, do you want me to do further things for this patch 
> to get accepted? Or is it more a side-note?

I'm wondering if there is an alternative that we can come up with that
doesn't require the addition of an optional parameter, and therefore
something that libvirt could reliably use without needing Amos'
introspection support to go in first.  Besides, weren't some of the
other review comments in this thread questioning whether we should even
allow users to set baud rate at creation, or should we be fixing the
real underlying bug of not matching bare-metal hardware that always
initializes to a fixed rate of 9600?  That is, I think there are still
unanswered questions that must be resolved before we can even decide
whether an amended version of this patch is even worth including.

Patch

diff --git a/qapi-schema.json b/qapi-schema.json
index 5ad6894..f76bc0c 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3186,7 +3186,7 @@ 
 # Configuration info for device and pipe chardevs.
 #
 # @device: The name of the special file for the device,
-#          i.e. /dev/ttyS0 on Unix or COM1: on Windows
+#          i.e. /dev/parport0 on Unix.
 # @type: What kind of device this is.
 #
 # Since: 1.4
@@ -3194,6 +3194,20 @@ 
 { 'type': 'ChardevHostdev', 'data': { 'device' : 'str' } }
 
 ##
+# @ChardevSerial
+#
+# Configuration info for serial chardevs.
+#
+# @device: The name of the special file for the device,
+#          i.e. /dev/ttyS0 on Unix or COM1: on Windows
+# @baud: #optional baud rate to set for host device. (default 115200)
+#
+# Since: 1.5
+##
+{ 'type': 'ChardevSerial', 'data': { 'device' : 'str',
+                                     '*baud': 'int' } }
+
+##
 # @ChardevSocket:
 #
 # Configuration info for (stream) socket chardevs.
@@ -3311,7 +3325,7 @@ 
 { 'type': 'ChardevDummy', 'data': { } }
 
 { 'union': 'ChardevBackend', 'data': { 'file'   : 'ChardevFile',
-                                       'serial' : 'ChardevHostdev',
+                                       'serial' : 'ChardevSerial',
                                        'parallel': 'ChardevHostdev',
                                        'pipe'   : 'ChardevHostdev',
                                        'socket' : 'ChardevSocket',
diff --git a/qemu-char.c b/qemu-char.c
index d04b429..421730a 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1450,11 +1450,11 @@  static void qemu_chr_close_tty(CharDriverState *chr)
     }
 }
 
-static CharDriverState *qemu_chr_open_tty_fd(int fd)
+static CharDriverState *qemu_chr_open_tty_fd(int fd, int baud)
 {
     CharDriverState *chr;
 
-    tty_serial_init(fd, 115200, 'N', 8, 1);
+    tty_serial_init(fd, baud, 'N', 8, 1);
     chr = qemu_chr_open_fd(fd, fd);
     chr->chr_ioctl = tty_serial_ioctl;
     chr->chr_close = qemu_chr_close_tty;
@@ -3155,13 +3155,15 @@  static void qemu_chr_parse_serial(QemuOpts *opts, ChardevBackend *backend,
                                   Error **errp)
 {
     const char *device = qemu_opt_get(opts, "path");
+    const int baud = qemu_opt_get_number(opts, "baud", 115200);
 
     if (device == NULL) {
         error_setg(errp, "chardev: serial/tty: no device path given");
         return;
     }
-    backend->serial = g_new0(ChardevHostdev, 1);
+    backend->serial = g_new0(ChardevSerial, 1);
     backend->serial->device = g_strdup(device);
+    backend->serial->baud = baud;
 }
 
 static void qemu_chr_parse_parallel(QemuOpts *opts, ChardevBackend *backend,
@@ -3590,7 +3592,7 @@  static CharDriverState *qmp_chardev_open_file(ChardevFile *file, Error **errp)
     return qemu_chr_open_win_file(out);
 }
 
-static CharDriverState *qmp_chardev_open_serial(ChardevHostdev *serial,
+static CharDriverState *qmp_chardev_open_serial(ChardevSerial *serial,
                                                 Error **errp)
 {
     return qemu_chr_open_win_path(serial->device);
@@ -3639,7 +3641,7 @@  static CharDriverState *qmp_chardev_open_file(ChardevFile *file, Error **errp)
     return qemu_chr_open_fd(in, out);
 }
 
-static CharDriverState *qmp_chardev_open_serial(ChardevHostdev *serial,
+static CharDriverState *qmp_chardev_open_serial(ChardevSerial *serial,
                                                 Error **errp)
 {
 #ifdef HAVE_CHARDEV_TTY
@@ -3650,7 +3652,7 @@  static CharDriverState *qmp_chardev_open_serial(ChardevHostdev *serial,
         return NULL;
     }
     qemu_set_nonblock(fd);
-    return qemu_chr_open_tty_fd(fd);
+    return qemu_chr_open_tty_fd(fd, serial->baud);
 #else
     error_setg(errp, "character device backend type 'serial' not supported");
     return NULL;
diff --git a/qemu-options.hx b/qemu-options.hx
index bf94862..5f20edd 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1794,8 +1794,8 @@  DEF("chardev", HAS_ARG, QEMU_OPTION_chardev,
 #endif
 #if defined(__linux__) || defined(__sun__) || defined(__FreeBSD__) \
         || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__)
-    "-chardev serial,id=id,path=path[,mux=on|off]\n"
-    "-chardev tty,id=id,path=path[,mux=on|off]\n"
+    "-chardev serial,id=id,path=path[,mux=on|off][,baud=baud]\n"
+    "-chardev tty,id=id,path=path[,mux=on|off][,baud=baud]\n"
 #endif
 #if defined(__linux__) || defined(__FreeBSD__) || defined(__DragonFly__)
     "-chardev parallel,id=id,path=path[,mux=on|off]\n"
@@ -1963,7 +1963,7 @@  take any options.
 
 @option{console} is only available on Windows hosts.
 
-@item -chardev serial ,id=@var{id} ,path=@option{path}
+@item -chardev serial ,id=@var{id} ,path=@option{path} [,baud=@option{baud}]
 
 Send traffic from the guest to a serial device on the host.
 
@@ -1972,6 +1972,9 @@  not only serial lines.
 
 @option{path} specifies the name of the serial device to open.
 
+On Unix hosts, the @option{baud} specifies the baud rate for the host serial
+device. It is optional and defaults to 115200.
+
 @item -chardev pty ,id=@var{id}
 
 Create a new pseudo-terminal on the host and connect to it. @option{pty} does
@@ -2404,9 +2407,10 @@  vc:80Cx24C
 No device is allocated.
 @item null
 void device
-@item /dev/XXX
+@item /dev/XXX[,baud=@var{baud}]
 [Linux only] Use host tty, e.g. @file{/dev/ttyS0}. The host serial port
-parameters are set according to the emulated ones.
+parameters are set according to the emulated ones. The optional @var{baud}
+option allows for overriding the default host baud rate of 115200.
 @item /dev/parport@var{N}
 [Linux only, parallel port only] Use host parallel port
 @var{N}. Currently SPP and EPP parallel port features can be used.