chardev: add baud parameter for serial host device

PATCH In review Peter Wu 4 participants 10 messages Jun 8, 2013 – Jun 15, 2013

Share & tools

Peter Wu

author

2013-06-08 21:49 UTC #0 lore raw

PATCH 1/1 chardev: add baud parameter for serial host device

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 <[email protected]>

---
 qapi-schema.json | 18 ++++++++++++++++--
 qemu-char.c      | 14 ++++++++------
 qemu-options.hx  | 14 +++++++++-----
 3 files changed, 33 insertions(+), 13 deletions(-)

qapi-schema.json +16 -2

index 5ad6894..f76bc0c 100644
@@ -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',

qemu-char.c +8 -6

index d04b429..421730a 100644
@@ -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;

qemu-options.hx +9 -5

index bf94862..5f20edd 100644
@@ -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.

Signature · 1 line

1.8.3

Gerd Hoffmann

2013-06-10 05:56 UTC #1 lore raw

Quoted 6 lines · Peter Wu

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

author

2013-06-10 08:42 UTC #2 lore raw

Quoted 7 lines · On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:

Quoted 6 lines · Peter Wu
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.

Quoted 8 lines

Quoted 2 lines
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

2013-06-10 12:58 UTC #3 lore raw

Quoted 17 lines · Peter Wu

Quoted 7 lines · On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
Quoted 6 lines · Peter Wu
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.
Quoted 8 lines
Quoted 2 lines
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).

Quoted 3 lines

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?

Quoted 1 line

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

2013-06-10 13:24 UTC #4 lore raw

Am 10.06.2013 14:58, schrieb Gerd Hoffmann:

Quoted 26 lines · Peter Wu

Quoted 17 lines · On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
Quoted 7 lines · Peter Wu
Quoted 6 lines
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.
Quoted 8 lines
Quoted 2 lines
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).
Quoted 3 lines
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?

Quoted 5 lines

Quoted 1 line
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

Signature · 2 lines

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Peter Wu

author

2013-06-10 13:28 UTC #5 lore raw

In reply to Gerd Hoffmann

Quoted 22 lines · On Monday 10 June 2013 14:58:07 Gerd Hoffmann wrote:

Quoted 21 lines · Peter Wu
Quoted 17 lines · On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
Quoted 10 lines · Peter Wu
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).

Quoted 7 lines

Quoted 3 lines
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

Quoted 5 lines

Quoted 1 line
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

author

2013-06-10 13:52 UTC #6 lore raw

Quoted 49 lines · On Monday 10 June 2013 15:28:32 Peter Wu wrote:

Quoted 33 lines · On Monday 10 June 2013 14:58:07 Gerd Hoffmann wrote:
Quoted 26 lines · Peter Wu
Quoted 17 lines · On Monday 10 June 2013 07:56:01 Gerd Hoffmann wrote:
Quoted 10 lines · Peter Wu
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.
Quoted 3 lines
After this patch, I can use -serial /dev/ttyS0,baud=9600 to override the
default baud rate of 115200.
Quoted 5 lines
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).
Quoted 3 lines
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.
Quoted 3 lines
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.

Quoted 5 lines

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

2013-06-15 15:17 UTC #7 lore raw

In reply to Peter Wu

Quoted 33 lines · Peter Wu

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 <[email protected]>
---
+++ b/qapi-schema.json
qapi-schema.json +3 -1
@@ -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
+#

qapi-schema.json line 3208

Quoted 10 lines

qapi-schema.json +10 -0

+# 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...

qapi-schema.json line 3328

Quoted 11 lines

qapi-schema.json +3 -1

+
+##
 # @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.

Signature · 2 lines

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Peter Wu

author

2013-06-15 15:26 UTC #8 lore raw

Quoted 38 lines · On Saturday 15 June 2013 16:14:23 Eric Blake wrote:

Quoted 37 lines · Peter Wu
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 <[email protected]>
---
+++ b/qapi-schema.json
qapi-schema.json +1 -1
@@ -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
qapi-schema.json +0 -0
@@ -3194,6 +3194,20 @@
 
 { 'type': 'ChardevHostdev', 'data': { 'device' : 'str' } }
 
 ##
 

Quoted 14 lines

qapi-schema.json line 3208

Quoted 12 lines

qapi-schema.json +12 -0

+# @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)

Quoted 15 lines

and furthermore...
Quoted 13 lines
qapi-schema.json +2 -0
+
+##
 
# @ChardevSocket:
#
# Configuration info for (stream) socket chardevs.
qapi-schema.json +0 -0
@@ -3311,7 +3325,7 @@
 
 { 'type': 'ChardevDummy', 'data': { } }
 
 { 'union': 'ChardevBackend', 'data': { 'file'   : 'ChardevFile',
 

Quoted 7 lines

qapi-schema.json line 3328
Quoted 2 lines
qapi-schema.json +1 -1
-                                       '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

2013-06-15 15:38 UTC #9 lore raw

Quoted 20 lines · Peter Wu

Quoted 19 lines · On Saturday 15 June 2013 16:14:23 Eric Blake wrote:
Quoted 17 lines · Peter Wu
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.
qapi-schema.json +1 -1
-                                       'serial' : 'ChardevHostdev',
+                                       'serial' : 'ChardevSerial',

Quoted 7 lines

Quoted 4 lines
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.

Signature · 2 lines

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org