| Message ID | 4543955.Y102znvq4W@al |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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.
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
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.
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
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.
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.
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(-)