2008-10-31 18:49:55 +00:00
|
|
|
/*
|
|
|
|
* QEMU System Emulator
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2008 Fabrice Bellard
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2018-02-01 11:18:31 +00:00
|
|
|
|
2016-01-29 17:50:05 +00:00
|
|
|
#include "qemu/osdep.h"
|
2016-03-20 17:16:19 +00:00
|
|
|
#include "qemu/cutils.h"
|
2012-12-17 17:19:49 +00:00
|
|
|
#include "monitor/monitor.h"
|
2012-12-17 17:20:04 +00:00
|
|
|
#include "sysemu/sysemu.h"
|
2016-12-12 17:22:24 +00:00
|
|
|
#include "qemu/config-file.h"
|
2015-03-17 17:29:20 +00:00
|
|
|
#include "qemu/error-report.h"
|
2017-01-26 13:19:46 +00:00
|
|
|
#include "chardev/char.h"
|
2018-02-01 11:18:31 +00:00
|
|
|
#include "qapi/error.h"
|
2018-02-11 09:36:01 +00:00
|
|
|
#include "qapi/qapi-commands-char.h"
|
2018-02-11 09:35:39 +00:00
|
|
|
#include "qapi/qmp/qerror.h"
|
2016-03-14 07:44:36 +00:00
|
|
|
#include "sysemu/replay.h"
|
2016-08-16 17:13:52 +00:00
|
|
|
#include "qemu/help_option.h"
|
2018-02-01 11:18:46 +00:00
|
|
|
#include "qemu/option.h"
|
2008-10-31 18:49:55 +00:00
|
|
|
|
2017-01-26 13:19:46 +00:00
|
|
|
#include "chardev/char-mux.h"
|
2016-12-12 12:06:14 +00:00
|
|
|
|
2008-10-31 18:49:55 +00:00
|
|
|
/***********************************************************/
|
|
|
|
/* character device */
|
|
|
|
|
2016-12-14 12:23:36 +00:00
|
|
|
static Object *get_chardevs_root(void)
|
|
|
|
{
|
|
|
|
return container_get(object_get_root(), "/chardevs");
|
|
|
|
}
|
2009-03-05 22:59:58 +00:00
|
|
|
|
2017-11-03 15:28:23 +00:00
|
|
|
static void chr_be_event(Chardev *s, int event)
|
2008-10-31 18:49:55 +00:00
|
|
|
{
|
2016-10-22 09:53:01 +00:00
|
|
|
CharBackend *be = s->be;
|
|
|
|
|
2017-11-03 15:28:23 +00:00
|
|
|
if (!be || !be->chr_event) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
be->chr_event(be->opaque, event);
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_chr_be_event(Chardev *s, int event)
|
|
|
|
{
|
2010-04-01 16:42:39 +00:00
|
|
|
/* Keep track if the char device is open */
|
|
|
|
switch (event) {
|
|
|
|
case CHR_EVENT_OPENED:
|
2013-03-26 10:07:53 +00:00
|
|
|
s->be_open = 1;
|
2010-04-01 16:42:39 +00:00
|
|
|
break;
|
|
|
|
case CHR_EVENT_CLOSED:
|
2013-03-26 10:07:53 +00:00
|
|
|
s->be_open = 0;
|
2010-04-01 16:42:39 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-11-03 15:28:23 +00:00
|
|
|
CHARDEV_GET_CLASS(s)->chr_be_event(s, event);
|
2008-10-31 18:49:55 +00:00
|
|
|
}
|
|
|
|
|
qemu-char: add logfile facility to all chardev backends
Typically a UNIX guest OS will log boot messages to a serial
port in addition to any graphical console. An admin user
may also wish to use the serial port for an interactive
console. A virtualization management system may wish to
collect system boot messages by logging the serial port,
but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app
to either provide 2 separate serial ports, one for
logging boot messages and one for interactive console
login, or to proxy all output via a separate service
that can multiplex the two needs onto one serial port.
While both are valid approaches, they each have their
own downsides. The former causes confusion and extra
setup work for VM admins creating disk images. The latter
places an extra burden to re-implement much of the QEMU
chardev backends logic in libvirt or even higher level
mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use
cases is to allow the QEMU chardev backends to have a
"logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\
server=on,nowait,id-charserial0,\
logfile=/var/log/libvirt/qemu/test-serial0.log
-device isa-serial,chardev=charserial0,id=serial0
This patch introduces a 'ChardevCommon' struct which
is setup as a base for all the ChardevBackend types.
Ideally this would be registered directly as a base
against ChardevBackend, rather than each type, but
the QAPI generator doesn't allow that since the
ChardevBackend is a non-discriminated union. The
ChardevCommon struct provides the optional 'logfile'
parameter, as well as 'logappend' which controls
whether QEMU truncates or appends (default truncate).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
[Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 12:44:41 +00:00
|
|
|
/* Not reporting errors from writing to logfile, as logs are
|
|
|
|
* defined to be "best effort" only */
|
2017-01-26 19:38:22 +00:00
|
|
|
static void qemu_chr_write_log(Chardev *s, const uint8_t *buf, size_t len)
|
qemu-char: add logfile facility to all chardev backends
Typically a UNIX guest OS will log boot messages to a serial
port in addition to any graphical console. An admin user
may also wish to use the serial port for an interactive
console. A virtualization management system may wish to
collect system boot messages by logging the serial port,
but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app
to either provide 2 separate serial ports, one for
logging boot messages and one for interactive console
login, or to proxy all output via a separate service
that can multiplex the two needs onto one serial port.
While both are valid approaches, they each have their
own downsides. The former causes confusion and extra
setup work for VM admins creating disk images. The latter
places an extra burden to re-implement much of the QEMU
chardev backends logic in libvirt or even higher level
mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use
cases is to allow the QEMU chardev backends to have a
"logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\
server=on,nowait,id-charserial0,\
logfile=/var/log/libvirt/qemu/test-serial0.log
-device isa-serial,chardev=charserial0,id=serial0
This patch introduces a 'ChardevCommon' struct which
is setup as a base for all the ChardevBackend types.
Ideally this would be registered directly as a base
against ChardevBackend, rather than each type, but
the QAPI generator doesn't allow that since the
ChardevBackend is a non-discriminated union. The
ChardevCommon struct provides the optional 'logfile'
parameter, as well as 'logappend' which controls
whether QEMU truncates or appends (default truncate).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
[Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 12:44:41 +00:00
|
|
|
{
|
|
|
|
size_t done = 0;
|
|
|
|
ssize_t ret;
|
|
|
|
|
|
|
|
if (s->logfd < 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (done < len) {
|
2016-03-31 15:29:27 +00:00
|
|
|
retry:
|
|
|
|
ret = write(s->logfd, buf + done, len - done);
|
|
|
|
if (ret == -1 && errno == EAGAIN) {
|
|
|
|
g_usleep(100);
|
|
|
|
goto retry;
|
|
|
|
}
|
qemu-char: add logfile facility to all chardev backends
Typically a UNIX guest OS will log boot messages to a serial
port in addition to any graphical console. An admin user
may also wish to use the serial port for an interactive
console. A virtualization management system may wish to
collect system boot messages by logging the serial port,
but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app
to either provide 2 separate serial ports, one for
logging boot messages and one for interactive console
login, or to proxy all output via a separate service
that can multiplex the two needs onto one serial port.
While both are valid approaches, they each have their
own downsides. The former causes confusion and extra
setup work for VM admins creating disk images. The latter
places an extra burden to re-implement much of the QEMU
chardev backends logic in libvirt or even higher level
mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use
cases is to allow the QEMU chardev backends to have a
"logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\
server=on,nowait,id-charserial0,\
logfile=/var/log/libvirt/qemu/test-serial0.log
-device isa-serial,chardev=charserial0,id=serial0
This patch introduces a 'ChardevCommon' struct which
is setup as a base for all the ChardevBackend types.
Ideally this would be registered directly as a base
against ChardevBackend, rather than each type, but
the QAPI generator doesn't allow that since the
ChardevBackend is a non-discriminated union. The
ChardevCommon struct provides the optional 'logfile'
parameter, as well as 'logappend' which controls
whether QEMU truncates or appends (default truncate).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
[Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 12:44:41 +00:00
|
|
|
|
|
|
|
if (ret <= 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
done += ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-26 19:38:22 +00:00
|
|
|
static int qemu_chr_write_buffer(Chardev *s,
|
|
|
|
const uint8_t *buf, int len,
|
|
|
|
int *offset, bool write_all)
|
2016-03-14 07:44:36 +00:00
|
|
|
{
|
2016-12-07 15:39:10 +00:00
|
|
|
ChardevClass *cc = CHARDEV_GET_CLASS(s);
|
2016-03-14 07:44:36 +00:00
|
|
|
int res = 0;
|
|
|
|
*offset = 0;
|
|
|
|
|
|
|
|
qemu_mutex_lock(&s->chr_write_lock);
|
|
|
|
while (*offset < len) {
|
2016-03-31 15:29:27 +00:00
|
|
|
retry:
|
2016-12-07 15:39:10 +00:00
|
|
|
res = cc->chr_write(s, buf + *offset, len - *offset);
|
2017-01-26 18:48:37 +00:00
|
|
|
if (res < 0 && errno == EAGAIN && write_all) {
|
2016-03-31 15:29:27 +00:00
|
|
|
g_usleep(100);
|
|
|
|
goto retry;
|
|
|
|
}
|
2016-03-14 07:44:36 +00:00
|
|
|
|
|
|
|
if (res <= 0) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
*offset += res;
|
2017-01-26 18:48:37 +00:00
|
|
|
if (!write_all) {
|
|
|
|
break;
|
|
|
|
}
|
2016-03-14 07:44:36 +00:00
|
|
|
}
|
|
|
|
if (*offset > 0) {
|
2017-01-26 19:38:22 +00:00
|
|
|
qemu_chr_write_log(s, buf, *offset);
|
2016-03-14 07:44:36 +00:00
|
|
|
}
|
|
|
|
qemu_mutex_unlock(&s->chr_write_lock);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2017-01-26 14:26:44 +00:00
|
|
|
int qemu_chr_write(Chardev *s, const uint8_t *buf, int len, bool write_all)
|
2013-03-26 15:04:17 +00:00
|
|
|
{
|
2017-01-26 18:48:37 +00:00
|
|
|
int offset = 0;
|
2016-03-14 07:44:36 +00:00
|
|
|
int res;
|
2013-03-26 15:04:17 +00:00
|
|
|
|
2016-10-21 19:58:45 +00:00
|
|
|
if (qemu_chr_replay(s) && replay_mode == REPLAY_MODE_PLAY) {
|
2016-03-14 07:44:36 +00:00
|
|
|
replay_char_write_event_load(&res, &offset);
|
|
|
|
assert(offset <= len);
|
2017-01-26 19:38:22 +00:00
|
|
|
qemu_chr_write_buffer(s, buf, offset, &offset, true);
|
2016-03-14 07:44:36 +00:00
|
|
|
return res;
|
|
|
|
}
|
2013-03-26 15:04:17 +00:00
|
|
|
|
2017-01-26 19:38:22 +00:00
|
|
|
res = qemu_chr_write_buffer(s, buf, len, &offset, write_all);
|
2013-03-26 15:04:17 +00:00
|
|
|
|
2016-10-21 19:58:45 +00:00
|
|
|
if (qemu_chr_replay(s) && replay_mode == REPLAY_MODE_RECORD) {
|
2016-03-14 07:44:36 +00:00
|
|
|
replay_char_write_event_save(res, offset);
|
2013-03-26 15:04:17 +00:00
|
|
|
}
|
|
|
|
|
2014-06-18 06:43:58 +00:00
|
|
|
if (res < 0) {
|
|
|
|
return res;
|
|
|
|
}
|
2013-03-26 15:04:17 +00:00
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
2016-12-07 13:20:22 +00:00
|
|
|
int qemu_chr_be_can_write(Chardev *s)
|
2008-10-31 18:49:55 +00:00
|
|
|
{
|
2016-10-22 09:53:01 +00:00
|
|
|
CharBackend *be = s->be;
|
|
|
|
|
|
|
|
if (!be || !be->chr_can_read) {
|
2008-10-31 18:49:55 +00:00
|
|
|
return 0;
|
2016-10-22 09:53:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return be->chr_can_read(be->opaque);
|
2008-10-31 18:49:55 +00:00
|
|
|
}
|
|
|
|
|
2016-12-07 13:20:22 +00:00
|
|
|
void qemu_chr_be_write_impl(Chardev *s, uint8_t *buf, int len)
|
2008-10-31 18:49:55 +00:00
|
|
|
{
|
2016-10-22 09:53:01 +00:00
|
|
|
CharBackend *be = s->be;
|
|
|
|
|
|
|
|
if (be && be->chr_read) {
|
|
|
|
be->chr_read(be->opaque, buf, len);
|
2012-04-19 20:27:14 +00:00
|
|
|
}
|
2008-10-31 18:49:55 +00:00
|
|
|
}
|
|
|
|
|
2016-12-07 13:20:22 +00:00
|
|
|
void qemu_chr_be_write(Chardev *s, uint8_t *buf, int len)
|
2016-03-14 07:44:36 +00:00
|
|
|
{
|
2016-10-21 19:58:45 +00:00
|
|
|
if (qemu_chr_replay(s)) {
|
2016-03-14 07:44:36 +00:00
|
|
|
if (replay_mode == REPLAY_MODE_PLAY) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
replay_chr_be_write(s, buf, len);
|
|
|
|
} else {
|
|
|
|
qemu_chr_be_write_impl(s, buf, len);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-21 06:35:51 +00:00
|
|
|
void qemu_chr_be_update_read_handlers(Chardev *s,
|
|
|
|
GMainContext *context)
|
|
|
|
{
|
|
|
|
ChardevClass *cc = CHARDEV_GET_CLASS(s);
|
|
|
|
|
2018-12-05 20:37:33 +00:00
|
|
|
assert(qemu_chr_has_feature(s, QEMU_CHAR_FEATURE_GCONTEXT)
|
|
|
|
|| !context);
|
2017-09-21 06:35:52 +00:00
|
|
|
s->gcontext = context;
|
2017-09-21 06:35:51 +00:00
|
|
|
if (cc->chr_update_read_handler) {
|
2017-09-21 06:35:54 +00:00
|
|
|
cc->chr_update_read_handler(s);
|
2017-09-21 06:35:51 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-07 13:20:22 +00:00
|
|
|
int qemu_chr_add_client(Chardev *s, int fd)
|
Introduce a 'client_add' monitor command accepting an open FD
Allow client connections for VNC and socket based character
devices to be passed in over the monitor using SCM_RIGHTS.
One intended usage scenario is to start QEMU with VNC on a
UNIX domain socket. An unprivileged user which cannot access
the UNIX domain socket, can then connect to QEMU's VNC server
by passing an open FD to libvirt, which passes it onto QEMU.
{ "execute": "get_fd", "arguments": { "fdname": "myclient" } }
{ "return": {} }
{ "execute": "add_client", "arguments": { "protocol": "vnc",
"fdname": "myclient",
"skipauth": true } }
{ "return": {} }
In this case 'protocol' can be 'vnc' or 'spice', or the name
of a character device (eg from -chardev id=XXXX)
The 'skipauth' parameter can be used to skip any configured
VNC authentication scheme, which is useful if the mgmt layer
talking to the monitor has already authenticated the client
in another way.
* console.h: Define 'vnc_display_add_client' method
* monitor.c: Implement 'client_add' command
* qemu-char.c, qemu-char.h: Add 'qemu_char_add_client' method
* qerror.c, qerror.h: Add QERR_ADD_CLIENT_FAILED
* qmp-commands.hx: Declare 'client_add' command
* ui/vnc.c: Implement 'vnc_display_add_client' method
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-06-23 12:31:42 +00:00
|
|
|
{
|
2016-12-07 15:39:10 +00:00
|
|
|
return CHARDEV_GET_CLASS(s)->chr_add_client ?
|
|
|
|
CHARDEV_GET_CLASS(s)->chr_add_client(s, fd) : -1;
|
Introduce a 'client_add' monitor command accepting an open FD
Allow client connections for VNC and socket based character
devices to be passed in over the monitor using SCM_RIGHTS.
One intended usage scenario is to start QEMU with VNC on a
UNIX domain socket. An unprivileged user which cannot access
the UNIX domain socket, can then connect to QEMU's VNC server
by passing an open FD to libvirt, which passes it onto QEMU.
{ "execute": "get_fd", "arguments": { "fdname": "myclient" } }
{ "return": {} }
{ "execute": "add_client", "arguments": { "protocol": "vnc",
"fdname": "myclient",
"skipauth": true } }
{ "return": {} }
In this case 'protocol' can be 'vnc' or 'spice', or the name
of a character device (eg from -chardev id=XXXX)
The 'skipauth' parameter can be used to skip any configured
VNC authentication scheme, which is useful if the mgmt layer
talking to the monitor has already authenticated the client
in another way.
* console.h: Define 'vnc_display_add_client' method
* monitor.c: Implement 'client_add' command
* qemu-char.c, qemu-char.h: Add 'qemu_char_add_client' method
* qerror.c, qerror.h: Add QERR_ADD_CLIENT_FAILED
* qmp-commands.hx: Declare 'client_add' command
* ui/vnc.c: Implement 'vnc_display_add_client' method
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-06-23 12:31:42 +00:00
|
|
|
}
|
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
static void qemu_char_open(Chardev *chr, ChardevBackend *backend,
|
|
|
|
bool *be_opened, Error **errp)
|
2008-10-31 18:49:55 +00:00
|
|
|
{
|
2016-12-07 15:39:10 +00:00
|
|
|
ChardevClass *cc = CHARDEV_GET_CLASS(chr);
|
|
|
|
/* Any ChardevCommon member would work */
|
|
|
|
ChardevCommon *common = backend ? backend->u.null.data : NULL;
|
|
|
|
|
|
|
|
if (common && common->has_logfile) {
|
|
|
|
int flags = O_WRONLY | O_CREAT;
|
|
|
|
if (common->has_logappend &&
|
|
|
|
common->logappend) {
|
|
|
|
flags |= O_APPEND;
|
|
|
|
} else {
|
|
|
|
flags |= O_TRUNC;
|
|
|
|
}
|
|
|
|
chr->logfd = qemu_open(common->logfile, flags, 0666);
|
|
|
|
if (chr->logfd < 0) {
|
|
|
|
error_setg_errno(errp, errno,
|
|
|
|
"Unable to open logfile %s",
|
|
|
|
common->logfile);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cc->open) {
|
|
|
|
cc->open(chr, backend, be_opened, errp);
|
|
|
|
}
|
2008-10-31 18:49:55 +00:00
|
|
|
}
|
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
static void char_init(Object *obj)
|
2008-10-31 18:49:55 +00:00
|
|
|
{
|
2016-12-07 15:39:10 +00:00
|
|
|
Chardev *chr = CHARDEV(obj);
|
2008-10-31 18:49:55 +00:00
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
chr->logfd = -1;
|
|
|
|
qemu_mutex_init(&chr->chr_write_lock);
|
2018-12-05 20:37:33 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Assume if chr_update_read_handler is implemented it will
|
|
|
|
* take the updated gcontext into account.
|
|
|
|
*/
|
|
|
|
if (CHARDEV_GET_CLASS(chr)->chr_update_read_handler) {
|
|
|
|
qemu_chr_set_feature(chr, QEMU_CHAR_FEATURE_GCONTEXT);
|
|
|
|
}
|
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
}
|
|
|
|
|
2016-12-12 10:41:40 +00:00
|
|
|
static int null_chr_write(Chardev *chr, const uint8_t *buf, int len)
|
|
|
|
{
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void char_class_init(ObjectClass *oc, void *data)
|
|
|
|
{
|
|
|
|
ChardevClass *cc = CHARDEV_CLASS(oc);
|
|
|
|
|
|
|
|
cc->chr_write = null_chr_write;
|
2017-11-03 15:28:23 +00:00
|
|
|
cc->chr_be_event = chr_be_event;
|
2016-12-12 10:41:40 +00:00
|
|
|
}
|
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
static void char_finalize(Object *obj)
|
|
|
|
{
|
|
|
|
Chardev *chr = CHARDEV(obj);
|
|
|
|
|
|
|
|
if (chr->be) {
|
|
|
|
chr->be->chr = NULL;
|
|
|
|
}
|
|
|
|
g_free(chr->filename);
|
|
|
|
g_free(chr->label);
|
|
|
|
if (chr->logfd != -1) {
|
|
|
|
close(chr->logfd);
|
qemu-char: add logfile facility to all chardev backends
Typically a UNIX guest OS will log boot messages to a serial
port in addition to any graphical console. An admin user
may also wish to use the serial port for an interactive
console. A virtualization management system may wish to
collect system boot messages by logging the serial port,
but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app
to either provide 2 separate serial ports, one for
logging boot messages and one for interactive console
login, or to proxy all output via a separate service
that can multiplex the two needs onto one serial port.
While both are valid approaches, they each have their
own downsides. The former causes confusion and extra
setup work for VM admins creating disk images. The latter
places an extra burden to re-implement much of the QEMU
chardev backends logic in libvirt or even higher level
mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use
cases is to allow the QEMU chardev backends to have a
"logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\
server=on,nowait,id-charserial0,\
logfile=/var/log/libvirt/qemu/test-serial0.log
-device isa-serial,chardev=charserial0,id=serial0
This patch introduces a 'ChardevCommon' struct which
is setup as a base for all the ChardevBackend types.
Ideally this would be registered directly as a base
against ChardevBackend, rather than each type, but
the QAPI generator doesn't allow that since the
ChardevBackend is a non-discriminated union. The
ChardevCommon struct provides the optional 'logfile'
parameter, as well as 'logappend' which controls
whether QEMU truncates or appends (default truncate).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
[Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 12:44:41 +00:00
|
|
|
}
|
2016-12-07 15:39:10 +00:00
|
|
|
qemu_mutex_destroy(&chr->chr_write_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo char_type_info = {
|
|
|
|
.name = TYPE_CHARDEV,
|
|
|
|
.parent = TYPE_OBJECT,
|
|
|
|
.instance_size = sizeof(Chardev),
|
|
|
|
.instance_init = char_init,
|
|
|
|
.instance_finalize = char_finalize,
|
|
|
|
.abstract = true,
|
|
|
|
.class_size = sizeof(ChardevClass),
|
2016-12-12 10:41:40 +00:00
|
|
|
.class_init = char_class_init,
|
2016-12-07 15:39:10 +00:00
|
|
|
};
|
|
|
|
|
2018-03-06 05:33:16 +00:00
|
|
|
static int chardev_machine_done_notify_one(Object *child, void *opaque)
|
chardev: fix CHR_EVENT_OPENED events for mux chardevs
As of bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec, chardevs no longer use
bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
semantics, we instead defer the CHR_EVENT_OPENED events toward the end
of chardev initialization.
For muxes, this isn't good enough, since a range of FEs must be able
to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
each FE will immediately print it's initial output (prompts, banners,
etc.) just prior to us switching to the next FE as part of
initialization.
The is new and confusing behavior for users, as they'll see output for
things like the HMP monitor, even though their the current mux focus
may be a guest serial port with potentially no output.
We fix this by further deferring CHR_EVENT_OPENED events for FEs
associated with muxes until after machine init by flagging mux chardevs
with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
events until we explicitly set the mux as opened later.
Currently, we must defer till after machine init since we potentially
associate FEs with muxes as part of realize (for instance,
serial_isa_realizefn).
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-30 18:04:22 +00:00
|
|
|
{
|
2018-03-06 05:33:16 +00:00
|
|
|
Chardev *chr = (Chardev *)child;
|
|
|
|
ChardevClass *class = CHARDEV_GET_CLASS(chr);
|
|
|
|
|
|
|
|
if (class->chr_machine_done) {
|
|
|
|
return class->chr_machine_done(chr);
|
2016-12-14 13:44:19 +00:00
|
|
|
}
|
chardev: fix CHR_EVENT_OPENED events for mux chardevs
As of bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec, chardevs no longer use
bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
semantics, we instead defer the CHR_EVENT_OPENED events toward the end
of chardev initialization.
For muxes, this isn't good enough, since a range of FEs must be able
to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
each FE will immediately print it's initial output (prompts, banners,
etc.) just prior to us switching to the next FE as part of
initialization.
The is new and confusing behavior for users, as they'll see output for
things like the HMP monitor, even though their the current mux focus
may be a guest serial port with potentially no output.
We fix this by further deferring CHR_EVENT_OPENED events for FEs
associated with muxes until after machine init by flagging mux chardevs
with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
events until we explicitly set the mux as opened later.
Currently, we must defer till after machine init since we potentially
associate FEs with muxes as part of realize (for instance,
serial_isa_realizefn).
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-30 18:04:22 +00:00
|
|
|
|
2016-12-14 13:44:19 +00:00
|
|
|
return 0;
|
|
|
|
}
|
chardev: fix CHR_EVENT_OPENED events for mux chardevs
As of bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec, chardevs no longer use
bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
semantics, we instead defer the CHR_EVENT_OPENED events toward the end
of chardev initialization.
For muxes, this isn't good enough, since a range of FEs must be able
to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
each FE will immediately print it's initial output (prompts, banners,
etc.) just prior to us switching to the next FE as part of
initialization.
The is new and confusing behavior for users, as they'll see output for
things like the HMP monitor, even though their the current mux focus
may be a guest serial port with potentially no output.
We fix this by further deferring CHR_EVENT_OPENED events for FEs
associated with muxes until after machine init by flagging mux chardevs
with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
events until we explicitly set the mux as opened later.
Currently, we must defer till after machine init since we potentially
associate FEs with muxes as part of realize (for instance,
serial_isa_realizefn).
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-30 18:04:22 +00:00
|
|
|
|
2018-03-06 05:33:16 +00:00
|
|
|
static void chardev_machine_done_hook(Notifier *notifier, void *unused)
|
2016-12-14 13:44:19 +00:00
|
|
|
{
|
2018-03-06 05:33:16 +00:00
|
|
|
int ret = object_child_foreach(get_chardevs_root(),
|
|
|
|
chardev_machine_done_notify_one, NULL);
|
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
error_report("Failed to call chardev machine_done hooks");
|
|
|
|
exit(1);
|
|
|
|
}
|
chardev: fix CHR_EVENT_OPENED events for mux chardevs
As of bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec, chardevs no longer use
bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
semantics, we instead defer the CHR_EVENT_OPENED events toward the end
of chardev initialization.
For muxes, this isn't good enough, since a range of FEs must be able
to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
each FE will immediately print it's initial output (prompts, banners,
etc.) just prior to us switching to the next FE as part of
initialization.
The is new and confusing behavior for users, as they'll see output for
things like the HMP monitor, even though their the current mux focus
may be a guest serial port with potentially no output.
We fix this by further deferring CHR_EVENT_OPENED events for FEs
associated with muxes until after machine init by flagging mux chardevs
with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
events until we explicitly set the mux as opened later.
Currently, we must defer till after machine init since we potentially
associate FEs with muxes as part of realize (for instance,
serial_isa_realizefn).
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-30 18:04:22 +00:00
|
|
|
}
|
|
|
|
|
2018-03-06 05:33:16 +00:00
|
|
|
static Notifier chardev_machine_done_notify = {
|
|
|
|
.notify = chardev_machine_done_hook,
|
chardev: fix CHR_EVENT_OPENED events for mux chardevs
As of bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec, chardevs no longer use
bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
semantics, we instead defer the CHR_EVENT_OPENED events toward the end
of chardev initialization.
For muxes, this isn't good enough, since a range of FEs must be able
to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
each FE will immediately print it's initial output (prompts, banners,
etc.) just prior to us switching to the next FE as part of
initialization.
The is new and confusing behavior for users, as they'll see output for
things like the HMP monitor, even though their the current mux focus
may be a guest serial port with potentially no output.
We fix this by further deferring CHR_EVENT_OPENED events for FEs
associated with muxes until after machine init by flagging mux chardevs
with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
events until we explicitly set the mux as opened later.
Currently, we must defer till after machine init since we potentially
associate FEs with muxes as part of realize (for instance,
serial_isa_realizefn).
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-30 18:04:22 +00:00
|
|
|
};
|
|
|
|
|
2016-12-07 13:20:22 +00:00
|
|
|
static bool qemu_chr_is_busy(Chardev *s)
|
2016-10-22 09:53:01 +00:00
|
|
|
{
|
2016-12-07 15:39:10 +00:00
|
|
|
if (CHARDEV_IS_MUX(s)) {
|
|
|
|
MuxChardev *d = MUX_CHARDEV(s);
|
2016-10-22 09:53:01 +00:00
|
|
|
return d->mux_cnt >= 0;
|
|
|
|
} else {
|
|
|
|
return s->be != NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-12 15:41:00 +00:00
|
|
|
int qemu_chr_wait_connected(Chardev *chr, Error **errp)
|
2016-07-26 21:15:17 +00:00
|
|
|
{
|
2016-12-07 15:39:10 +00:00
|
|
|
ChardevClass *cc = CHARDEV_GET_CLASS(chr);
|
|
|
|
|
|
|
|
if (cc->chr_wait_connected) {
|
|
|
|
return cc->chr_wait_connected(chr, errp);
|
2016-07-26 21:15:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename,
|
|
|
|
bool permit_mux_mon)
|
2009-09-10 08:58:35 +00:00
|
|
|
{
|
2009-09-10 08:58:49 +00:00
|
|
|
char host[65], port[33], width[8], height[8];
|
2009-09-10 08:58:42 +00:00
|
|
|
int pos;
|
2009-09-10 08:58:36 +00:00
|
|
|
const char *p;
|
2009-09-10 08:58:35 +00:00
|
|
|
QemuOpts *opts;
|
2012-03-20 18:51:57 +00:00
|
|
|
Error *local_err = NULL;
|
2009-09-10 08:58:35 +00:00
|
|
|
|
2012-03-20 18:51:57 +00:00
|
|
|
opts = qemu_opts_create(qemu_find_opts("chardev"), label, 1, &local_err);
|
2014-01-30 14:07:28 +00:00
|
|
|
if (local_err) {
|
2015-02-10 14:21:26 +00:00
|
|
|
error_report_err(local_err);
|
2009-09-10 08:58:35 +00:00
|
|
|
return NULL;
|
2012-03-20 18:51:57 +00:00
|
|
|
}
|
2009-09-10 08:58:35 +00:00
|
|
|
|
2009-09-10 08:58:50 +00:00
|
|
|
if (strstart(filename, "mon:", &p)) {
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
if (!permit_mux_mon) {
|
|
|
|
error_report("mon: isn't supported in this context");
|
|
|
|
return NULL;
|
|
|
|
}
|
2009-09-10 08:58:50 +00:00
|
|
|
filename = p;
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "mux", "on", &error_abort);
|
2013-07-03 16:29:45 +00:00
|
|
|
if (strcmp(filename, "stdio") == 0) {
|
|
|
|
/* Monitor is muxed to stdio: do not exit on Ctrl+C by default
|
|
|
|
* but pass it to the guest. Handle this only for compat syntax,
|
|
|
|
* for -chardev syntax we have special option for this.
|
|
|
|
* This is what -nographic did, redirecting+muxing serial+monitor
|
|
|
|
* to stdio causing Ctrl+C to be passed to guest. */
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "signal", "off", &error_abort);
|
2013-07-03 16:29:45 +00:00
|
|
|
}
|
2009-09-10 08:58:50 +00:00
|
|
|
}
|
|
|
|
|
2009-09-10 08:58:45 +00:00
|
|
|
if (strcmp(filename, "null") == 0 ||
|
|
|
|
strcmp(filename, "pty") == 0 ||
|
|
|
|
strcmp(filename, "msmouse") == 0 ||
|
2017-02-06 14:23:27 +00:00
|
|
|
strcmp(filename, "wctablet") == 0 ||
|
2009-09-10 08:58:46 +00:00
|
|
|
strcmp(filename, "braille") == 0 ||
|
backends: Introduce chr-testdev
From: Paolo Bonzini <pbonzini@redhat.com>
chr-testdev enables a virtio serial channel to be used for guest
initiated qemu exits. hw/misc/debugexit already enables guest
initiated qemu exits, but only for PC targets. chr-testdev supports
any virtio-capable target. kvm-unit-tests/arm is already making use
of this backend.
Currently there is a single command implemented, "q". It takes a
(prefix) argument for the exit code, thus an exit is implemented by
writing, e.g. "1q", to the virtio-serial port.
It can be used as:
$QEMU ... \
-device virtio-serial-device \
-device virtserialport,chardev=ctd -chardev testdev,id=ctd
or, use:
$QEMU ... \
-device virtio-serial-device \
-device virtconsole,chardev=ctd -chardev testdev,id=ctd
to bind it to virtio-serial port0.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-07-11 07:44:26 +00:00
|
|
|
strcmp(filename, "testdev") == 0 ||
|
2009-09-10 08:58:45 +00:00
|
|
|
strcmp(filename, "stdio") == 0) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", filename, &error_abort);
|
2009-09-10 08:58:35 +00:00
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:49 +00:00
|
|
|
if (strstart(filename, "vc", &p)) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", "vc", &error_abort);
|
2009-09-10 08:58:49 +00:00
|
|
|
if (*p == ':') {
|
2013-09-30 21:04:49 +00:00
|
|
|
if (sscanf(p+1, "%7[0-9]x%7[0-9]", width, height) == 2) {
|
2009-09-10 08:58:49 +00:00
|
|
|
/* pixels */
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "width", width, &error_abort);
|
|
|
|
qemu_opt_set(opts, "height", height, &error_abort);
|
2013-09-30 21:04:49 +00:00
|
|
|
} else if (sscanf(p+1, "%7[0-9]Cx%7[0-9]C", width, height) == 2) {
|
2009-09-10 08:58:49 +00:00
|
|
|
/* chars */
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "cols", width, &error_abort);
|
|
|
|
qemu_opt_set(opts, "rows", height, &error_abort);
|
2009-09-10 08:58:49 +00:00
|
|
|
} else {
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:47 +00:00
|
|
|
if (strcmp(filename, "con:") == 0) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", "console", &error_abort);
|
2009-09-10 08:58:47 +00:00
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:48 +00:00
|
|
|
if (strstart(filename, "COM", NULL)) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", "serial", &error_abort);
|
|
|
|
qemu_opt_set(opts, "path", filename, &error_abort);
|
2009-09-10 08:58:48 +00:00
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:36 +00:00
|
|
|
if (strstart(filename, "file:", &p)) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", "file", &error_abort);
|
|
|
|
qemu_opt_set(opts, "path", p, &error_abort);
|
2009-09-10 08:58:36 +00:00
|
|
|
return opts;
|
|
|
|
}
|
|
|
|
if (strstart(filename, "pipe:", &p)) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", "pipe", &error_abort);
|
|
|
|
qemu_opt_set(opts, "path", p, &error_abort);
|
2009-09-10 08:58:36 +00:00
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:42 +00:00
|
|
|
if (strstart(filename, "tcp:", &p) ||
|
2016-09-23 06:06:11 +00:00
|
|
|
strstart(filename, "telnet:", &p) ||
|
2018-10-18 22:35:00 +00:00
|
|
|
strstart(filename, "tn3270:", &p) ||
|
|
|
|
strstart(filename, "websocket:", &p)) {
|
2009-09-10 08:58:42 +00:00
|
|
|
if (sscanf(p, "%64[^:]:%32[^,]%n", host, port, &pos) < 2) {
|
|
|
|
host[0] = 0;
|
|
|
|
if (sscanf(p, ":%32[^,]%n", port, &pos) < 1)
|
|
|
|
goto fail;
|
|
|
|
}
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", "socket", &error_abort);
|
|
|
|
qemu_opt_set(opts, "host", host, &error_abort);
|
|
|
|
qemu_opt_set(opts, "port", port, &error_abort);
|
2009-09-10 08:58:42 +00:00
|
|
|
if (p[pos] == ',') {
|
2015-02-12 17:37:11 +00:00
|
|
|
qemu_opts_do_parse(opts, p+pos+1, NULL, &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_report_err(local_err);
|
2009-09-10 08:58:42 +00:00
|
|
|
goto fail;
|
2015-02-12 17:37:11 +00:00
|
|
|
}
|
2009-09-10 08:58:42 +00:00
|
|
|
}
|
2016-09-23 06:06:11 +00:00
|
|
|
if (strstart(filename, "telnet:", &p)) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "telnet", "on", &error_abort);
|
2016-09-23 06:06:11 +00:00
|
|
|
} else if (strstart(filename, "tn3270:", &p)) {
|
|
|
|
qemu_opt_set(opts, "tn3270", "on", &error_abort);
|
2018-10-18 22:35:00 +00:00
|
|
|
} else if (strstart(filename, "websocket:", &p)) {
|
|
|
|
qemu_opt_set(opts, "websocket", "on", &error_abort);
|
2016-09-23 06:06:11 +00:00
|
|
|
}
|
2009-09-10 08:58:42 +00:00
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:51 +00:00
|
|
|
if (strstart(filename, "udp:", &p)) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", "udp", &error_abort);
|
2009-09-10 08:58:51 +00:00
|
|
|
if (sscanf(p, "%64[^:]:%32[^@,]%n", host, port, &pos) < 2) {
|
|
|
|
host[0] = 0;
|
2010-03-07 10:28:48 +00:00
|
|
|
if (sscanf(p, ":%32[^@,]%n", port, &pos) < 1) {
|
2009-09-10 08:58:51 +00:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
}
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "host", host, &error_abort);
|
|
|
|
qemu_opt_set(opts, "port", port, &error_abort);
|
2009-09-10 08:58:51 +00:00
|
|
|
if (p[pos] == '@') {
|
|
|
|
p += pos + 1;
|
|
|
|
if (sscanf(p, "%64[^:]:%32[^,]%n", host, port, &pos) < 2) {
|
|
|
|
host[0] = 0;
|
|
|
|
if (sscanf(p, ":%32[^,]%n", port, &pos) < 1) {
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
}
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "localaddr", host, &error_abort);
|
|
|
|
qemu_opt_set(opts, "localport", port, &error_abort);
|
2009-09-10 08:58:51 +00:00
|
|
|
}
|
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:42 +00:00
|
|
|
if (strstart(filename, "unix:", &p)) {
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "backend", "socket", &error_abort);
|
2015-02-12 17:37:11 +00:00
|
|
|
qemu_opts_do_parse(opts, p, "path", &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_report_err(local_err);
|
2009-09-10 08:58:42 +00:00
|
|
|
goto fail;
|
2015-02-12 17:37:11 +00:00
|
|
|
}
|
2009-09-10 08:58:42 +00:00
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:48 +00:00
|
|
|
if (strstart(filename, "/dev/parport", NULL) ||
|
|
|
|
strstart(filename, "/dev/ppi", NULL)) {
|
2017-06-07 17:41:15 +00:00
|
|
|
qemu_opt_set(opts, "backend", "parallel", &error_abort);
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "path", filename, &error_abort);
|
2009-09-10 08:58:48 +00:00
|
|
|
return opts;
|
|
|
|
}
|
|
|
|
if (strstart(filename, "/dev/", NULL)) {
|
2017-06-07 17:41:15 +00:00
|
|
|
qemu_opt_set(opts, "backend", "serial", &error_abort);
|
2015-02-12 16:52:20 +00:00
|
|
|
qemu_opt_set(opts, "path", filename, &error_abort);
|
2009-09-10 08:58:48 +00:00
|
|
|
return opts;
|
|
|
|
}
|
2009-09-10 08:58:35 +00:00
|
|
|
|
2019-02-11 18:24:33 +00:00
|
|
|
error_report("'%s' is not a valid char driver", filename);
|
|
|
|
|
2009-09-10 08:58:42 +00:00
|
|
|
fail:
|
2009-09-10 08:58:35 +00:00
|
|
|
qemu_opts_del(opts);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-02-20 00:19:31 +00:00
|
|
|
void qemu_chr_parse_common(QemuOpts *opts, ChardevCommon *backend)
|
qemu-char: add logfile facility to all chardev backends
Typically a UNIX guest OS will log boot messages to a serial
port in addition to any graphical console. An admin user
may also wish to use the serial port for an interactive
console. A virtualization management system may wish to
collect system boot messages by logging the serial port,
but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app
to either provide 2 separate serial ports, one for
logging boot messages and one for interactive console
login, or to proxy all output via a separate service
that can multiplex the two needs onto one serial port.
While both are valid approaches, they each have their
own downsides. The former causes confusion and extra
setup work for VM admins creating disk images. The latter
places an extra burden to re-implement much of the QEMU
chardev backends logic in libvirt or even higher level
mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use
cases is to allow the QEMU chardev backends to have a
"logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\
server=on,nowait,id-charserial0,\
logfile=/var/log/libvirt/qemu/test-serial0.log
-device isa-serial,chardev=charserial0,id=serial0
This patch introduces a 'ChardevCommon' struct which
is setup as a base for all the ChardevBackend types.
Ideally this would be registered directly as a base
against ChardevBackend, rather than each type, but
the QAPI generator doesn't allow that since the
ChardevBackend is a non-discriminated union. The
ChardevCommon struct provides the optional 'logfile'
parameter, as well as 'logappend' which controls
whether QEMU truncates or appends (default truncate).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
[Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 12:44:41 +00:00
|
|
|
{
|
|
|
|
const char *logfile = qemu_opt_get(opts, "logfile");
|
|
|
|
|
|
|
|
backend->has_logfile = logfile != NULL;
|
2016-12-14 20:15:44 +00:00
|
|
|
backend->logfile = g_strdup(logfile);
|
qemu-char: add logfile facility to all chardev backends
Typically a UNIX guest OS will log boot messages to a serial
port in addition to any graphical console. An admin user
may also wish to use the serial port for an interactive
console. A virtualization management system may wish to
collect system boot messages by logging the serial port,
but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app
to either provide 2 separate serial ports, one for
logging boot messages and one for interactive console
login, or to proxy all output via a separate service
that can multiplex the two needs onto one serial port.
While both are valid approaches, they each have their
own downsides. The former causes confusion and extra
setup work for VM admins creating disk images. The latter
places an extra burden to re-implement much of the QEMU
chardev backends logic in libvirt or even higher level
mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use
cases is to allow the QEMU chardev backends to have a
"logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\
server=on,nowait,id-charserial0,\
logfile=/var/log/libvirt/qemu/test-serial0.log
-device isa-serial,chardev=charserial0,id=serial0
This patch introduces a 'ChardevCommon' struct which
is setup as a base for all the ChardevBackend types.
Ideally this would be registered directly as a base
against ChardevBackend, rather than each type, but
the QAPI generator doesn't allow that since the
ChardevBackend is a non-discriminated union. The
ChardevCommon struct provides the optional 'logfile'
parameter, as well as 'logappend' which controls
whether QEMU truncates or appends (default truncate).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
[Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 12:44:41 +00:00
|
|
|
|
|
|
|
backend->has_logappend = true;
|
|
|
|
backend->logappend = qemu_opt_get_bool(opts, "logappend", false);
|
|
|
|
}
|
|
|
|
|
2016-12-08 21:50:12 +00:00
|
|
|
static const ChardevClass *char_get_class(const char *driver, Error **errp)
|
|
|
|
{
|
|
|
|
ObjectClass *oc;
|
|
|
|
const ChardevClass *cc;
|
|
|
|
char *typename = g_strdup_printf("chardev-%s", driver);
|
|
|
|
|
|
|
|
oc = object_class_by_name(typename);
|
|
|
|
g_free(typename);
|
|
|
|
|
|
|
|
if (!object_class_dynamic_cast(oc, TYPE_CHARDEV)) {
|
|
|
|
error_setg(errp, "'%s' is not a valid char driver name", driver);
|
|
|
|
return NULL;
|
|
|
|
}
|
2013-03-05 17:51:28 +00:00
|
|
|
|
2016-12-08 21:50:12 +00:00
|
|
|
if (object_class_is_abstract(oc)) {
|
|
|
|
error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "driver",
|
|
|
|
"abstract device type");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
cc = CHARDEV_CLASS(oc);
|
|
|
|
if (cc->internal) {
|
|
|
|
error_setg(errp, "'%s' is not a valid char driver name", driver);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return cc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct ChardevAlias {
|
|
|
|
const char *typename;
|
|
|
|
const char *alias;
|
|
|
|
} chardev_alias_table[] = {
|
|
|
|
#ifdef HAVE_CHARDEV_PARPORT
|
|
|
|
{ "parallel", "parport" },
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_CHARDEV_SERIAL
|
|
|
|
{ "serial", "tty" },
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef struct ChadevClassFE {
|
|
|
|
void (*fn)(const char *name, void *opaque);
|
|
|
|
void *opaque;
|
|
|
|
} ChadevClassFE;
|
|
|
|
|
|
|
|
static void
|
|
|
|
chardev_class_foreach(ObjectClass *klass, void *opaque)
|
2013-02-21 10:39:12 +00:00
|
|
|
{
|
2016-12-08 21:50:12 +00:00
|
|
|
ChadevClassFE *fe = opaque;
|
|
|
|
|
|
|
|
assert(g_str_has_prefix(object_class_get_name(klass), "chardev-"));
|
|
|
|
if (CHARDEV_CLASS(klass)->internal) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
fe->fn(object_class_get_name(klass) + 8, fe->opaque);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
chardev_name_foreach(void (*fn)(const char *name, void *opaque), void *opaque)
|
|
|
|
{
|
|
|
|
ChadevClassFE fe = { .fn = fn, .opaque = opaque };
|
|
|
|
int i;
|
|
|
|
|
|
|
|
object_class_foreach(chardev_class_foreach, TYPE_CHARDEV, false, &fe);
|
|
|
|
|
2017-05-30 12:09:19 +00:00
|
|
|
for (i = 0; i < (int)ARRAY_SIZE(chardev_alias_table); i++) {
|
2016-12-08 21:50:12 +00:00
|
|
|
fn(chardev_alias_table[i].alias, opaque);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
help_string_append(const char *name, void *opaque)
|
|
|
|
{
|
|
|
|
GString *str = opaque;
|
|
|
|
|
2018-10-19 16:49:26 +00:00
|
|
|
g_string_append_printf(str, "\n %s", name);
|
2013-02-21 10:39:12 +00:00
|
|
|
}
|
|
|
|
|
2017-07-06 12:08:48 +00:00
|
|
|
static const char *chardev_alias_translate(const char *name)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < (int)ARRAY_SIZE(chardev_alias_table); i++) {
|
|
|
|
if (g_strcmp0(chardev_alias_table[i].alias, name) == 0) {
|
|
|
|
return chardev_alias_table[i].typename;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return name;
|
|
|
|
}
|
|
|
|
|
2017-07-06 12:08:57 +00:00
|
|
|
ChardevBackend *qemu_chr_parse_opts(QemuOpts *opts, Error **errp)
|
2009-09-10 08:58:35 +00:00
|
|
|
{
|
2014-05-19 16:57:35 +00:00
|
|
|
Error *local_err = NULL;
|
2016-12-08 21:50:12 +00:00
|
|
|
const ChardevClass *cc;
|
2016-12-09 08:04:51 +00:00
|
|
|
ChardevBackend *backend = NULL;
|
2017-07-06 12:08:48 +00:00
|
|
|
const char *name = chardev_alias_translate(qemu_opt_get(opts, "backend"));
|
2009-09-10 08:58:35 +00:00
|
|
|
|
2016-10-21 13:07:45 +00:00
|
|
|
if (name == NULL) {
|
error: Strip trailing '\n' from error string arguments (again)
Commit 6daf194d and be62a2eb got rid of a bunch, but they keep coming
back. Tracked down with this Coccinelle semantic patch:
@r@
expression err, eno, cls, fmt;
position p;
@@
(
error_report(fmt, ...)@p
|
error_set(err, cls, fmt, ...)@p
|
error_set_errno(err, eno, cls, fmt, ...)@p
|
error_setg(err, fmt, ...)@p
|
error_setg_errno(err, eno, fmt, ...)@p
)
@script:python@
fmt << r.fmt;
p << r.p;
@@
if "\\n" in str(fmt):
print "%s:%s:%s:%s" % (p[0].file, p[0].line, p[0].column, fmt)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 1360354939-10994-4-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-08 20:22:16 +00:00
|
|
|
error_setg(errp, "chardev: \"%s\" missing backend",
|
2012-10-15 07:28:05 +00:00
|
|
|
qemu_opts_id(opts));
|
2016-12-09 08:04:51 +00:00
|
|
|
return NULL;
|
2011-01-22 13:07:26 +00:00
|
|
|
}
|
2016-08-16 17:13:52 +00:00
|
|
|
|
2017-07-06 12:08:48 +00:00
|
|
|
cc = char_get_class(name, errp);
|
|
|
|
if (cc == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
backend = g_new0(ChardevBackend, 1);
|
|
|
|
backend->type = CHARDEV_BACKEND_KIND_NULL;
|
|
|
|
|
|
|
|
if (cc->parse) {
|
|
|
|
cc->parse(opts, backend, &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_propagate(errp, local_err);
|
|
|
|
qapi_free_ChardevBackend(backend);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ChardevCommon *ccom = g_new0(ChardevCommon, 1);
|
|
|
|
qemu_chr_parse_common(opts, ccom);
|
|
|
|
backend->u.null.data = ccom; /* Any ChardevCommon member would work */
|
|
|
|
}
|
|
|
|
|
|
|
|
return backend;
|
|
|
|
}
|
|
|
|
|
2019-02-13 13:18:13 +00:00
|
|
|
Chardev *qemu_chr_new_from_opts(QemuOpts *opts, GMainContext *context,
|
|
|
|
Error **errp)
|
2017-07-06 12:08:48 +00:00
|
|
|
{
|
|
|
|
const ChardevClass *cc;
|
|
|
|
Chardev *chr = NULL;
|
|
|
|
ChardevBackend *backend = NULL;
|
|
|
|
const char *name = chardev_alias_translate(qemu_opt_get(opts, "backend"));
|
|
|
|
const char *id = qemu_opts_id(opts);
|
|
|
|
char *bid = NULL;
|
|
|
|
|
|
|
|
if (name && is_help_option(name)) {
|
2016-11-30 18:57:24 +00:00
|
|
|
GString *str = g_string_new("");
|
2016-12-08 21:50:12 +00:00
|
|
|
|
|
|
|
chardev_name_foreach(help_string_append, str);
|
2016-11-30 18:57:24 +00:00
|
|
|
|
2018-10-17 08:26:31 +00:00
|
|
|
error_printf("Available chardev backend types: %s\n", str->str);
|
2016-11-30 18:57:24 +00:00
|
|
|
g_string_free(str, true);
|
2017-07-25 10:04:41 +00:00
|
|
|
return NULL;
|
2016-08-16 17:13:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (id == NULL) {
|
|
|
|
error_setg(errp, "chardev: no id specified");
|
2016-12-09 08:04:51 +00:00
|
|
|
return NULL;
|
2016-08-16 17:13:52 +00:00
|
|
|
}
|
|
|
|
|
2017-07-06 12:08:48 +00:00
|
|
|
backend = qemu_chr_parse_opts(opts, errp);
|
|
|
|
if (backend == NULL) {
|
|
|
|
return NULL;
|
2009-09-10 08:58:35 +00:00
|
|
|
}
|
2016-12-08 21:50:12 +00:00
|
|
|
|
|
|
|
cc = char_get_class(name, errp);
|
|
|
|
if (cc == NULL) {
|
2017-07-06 12:08:48 +00:00
|
|
|
goto out;
|
2009-09-10 08:58:35 +00:00
|
|
|
}
|
|
|
|
|
2014-09-02 10:24:16 +00:00
|
|
|
if (qemu_opt_get_bool(opts, "mux", 0)) {
|
|
|
|
bid = g_strdup_printf("%s-base", id);
|
|
|
|
}
|
2013-02-21 10:39:12 +00:00
|
|
|
|
2016-12-14 17:58:50 +00:00
|
|
|
chr = qemu_chardev_new(bid ? bid : id,
|
2016-12-09 08:04:51 +00:00
|
|
|
object_class_get_name(OBJECT_CLASS(cc)),
|
2019-02-13 13:18:13 +00:00
|
|
|
backend, context, errp);
|
2016-12-14 17:58:50 +00:00
|
|
|
|
2016-12-09 08:04:51 +00:00
|
|
|
if (chr == NULL) {
|
|
|
|
goto out;
|
2009-09-10 08:58:35 +00:00
|
|
|
}
|
|
|
|
|
2014-09-02 10:24:16 +00:00
|
|
|
if (bid) {
|
2016-12-09 08:04:51 +00:00
|
|
|
Chardev *mux;
|
2014-09-02 10:24:16 +00:00
|
|
|
qapi_free_ChardevBackend(backend);
|
|
|
|
backend = g_new0(ChardevBackend, 1);
|
2015-10-26 22:34:57 +00:00
|
|
|
backend->type = CHARDEV_BACKEND_KIND_MUX;
|
2016-12-09 08:04:51 +00:00
|
|
|
backend->u.mux.data = g_new0(ChardevMux, 1);
|
qapi: Don't special-case simple union wrappers
Simple unions were carrying a special case that hid their 'data'
QMP member from the resulting C struct, via the hack method
QAPISchemaObjectTypeVariant.simple_union_type(). But by using
the work we started by unboxing flat union and alternate
branches, coupled with the ability to visit the members of an
implicit type, we can now expose the simple union's implicit
type in qapi-types.h:
| struct q_obj_ImageInfoSpecificQCow2_wrapper {
| ImageInfoSpecificQCow2 *data;
| };
|
| struct q_obj_ImageInfoSpecificVmdk_wrapper {
| ImageInfoSpecificVmdk *data;
| };
...
| struct ImageInfoSpecific {
| ImageInfoSpecificKind type;
| union { /* union tag is @type */
| void *data;
|- ImageInfoSpecificQCow2 *qcow2;
|- ImageInfoSpecificVmdk *vmdk;
|+ q_obj_ImageInfoSpecificQCow2_wrapper qcow2;
|+ q_obj_ImageInfoSpecificVmdk_wrapper vmdk;
| } u;
| };
Doing this removes asymmetry between QAPI's QMP side and its
C side (both sides now expose 'data'), and means that the
treatment of a simple union as sugar for a flat union is now
equivalent in both languages (previously the two approaches used
a different layer of dereferencing, where the simple union could
be converted to a flat union with equivalent C layout but
different {} on the wire, or to an equivalent QMP wire form
but with different C representation). Using the implicit type
also lets us get rid of the simple_union_type() hack.
Of course, now all clients of simple unions have to adjust from
using su->u.member to using su->u.member.data; while this touches
a number of files in the tree, some earlier cleanup patches
helped minimize the change to the initialization of a temporary
variable rather than every single member access. The generated
qapi-visit.c code is also affected by the layout change:
|@@ -7393,10 +7393,10 @@ void visit_type_ImageInfoSpecific_member
| }
| switch (obj->type) {
| case IMAGE_INFO_SPECIFIC_KIND_QCOW2:
|- visit_type_ImageInfoSpecificQCow2(v, "data", &obj->u.qcow2, &err);
|+ visit_type_q_obj_ImageInfoSpecificQCow2_wrapper_members(v, &obj->u.qcow2, &err);
| break;
| case IMAGE_INFO_SPECIFIC_KIND_VMDK:
|- visit_type_ImageInfoSpecificVmdk(v, "data", &obj->u.vmdk, &err);
|+ visit_type_q_obj_ImageInfoSpecificVmdk_wrapper_members(v, &obj->u.vmdk, &err);
| break;
| default:
| abort();
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1458254921-17042-13-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-03-17 22:48:37 +00:00
|
|
|
backend->u.mux.data->chardev = g_strdup(bid);
|
2019-02-13 13:18:13 +00:00
|
|
|
mux = qemu_chardev_new(id, TYPE_CHARDEV_MUX, backend, context, errp);
|
2016-12-09 08:04:51 +00:00
|
|
|
if (mux == NULL) {
|
2016-12-14 12:23:36 +00:00
|
|
|
object_unparent(OBJECT(chr));
|
2014-09-02 10:24:16 +00:00
|
|
|
chr = NULL;
|
2016-12-09 08:04:51 +00:00
|
|
|
goto out;
|
2014-09-02 10:24:16 +00:00
|
|
|
}
|
2016-12-09 08:04:51 +00:00
|
|
|
chr = mux;
|
qemu-char: don't issue CHR_EVENT_OPEN in a BH
When CHR_EVENT_OPENED was initially added, it was CHR_EVENT_RESET,
and it was issued as a bottom-half:
86e94dea5b740dad65446c857f6959eae43e0ba6
Which we basically used to print out a greeting/prompt for the
monitor.
AFAICT the only reason this was ever done in a BH was because in
some cases we'd modify the chr_write handler for a new chardev
backend *after* the site where we issued the reset (see:
86e94d:qemu_chr_open_stdio())
At some point this event was renamed to CHR_EVENT_OPENED, and we've
maintained the use of this BH ever since.
However, due to 9f939df955a4152aad69a19a77e0898631bb2c18, we schedule
the BH via g_idle_add(), which is causing events to sometimes be
delivered after we've already begun processing data from backends,
leading to:
known bugs:
QMP:
session negotation resets with OPENED event, in some cases this
is causing new sessions to get sporadically reset
potential bugs:
hw/usb/redirect.c:
can_read handler checks for dev->parser != NULL, which may be
true if CLOSED BH has not been executed yet. In the past, OPENED
quiesced outstanding CLOSED events prior to us reading client
data. If it's delayed, our check may allow reads to occur even
though we haven't processed the OPENED event yet, and when we
do finally get the OPENED event, our state may get reset.
qtest.c:
can begin session before OPENED event is processed, leading to
a spurious reset of the system and irq_levels
gdbstub.c:
may start a gdb session prior to the machine being paused
To fix these, let's just drop the BH.
Since the initial reasoning for using it still applies to an extent,
work around that by deferring the delivery of CHR_EVENT_OPENED until
after the chardevs have been fully initialized, toward the end of
qmp_chardev_add() (or some cases, qemu_chr_new_from_opts()). This
defers delivery long enough that we can be assured a CharDriverState
is fully initialized before CHR_EVENT_OPENED is sent.
Also, rather than requiring each chardev to do an explicit open, do it
automatically, and allow the small few who don't desire such behavior to
suppress the OPENED-on-init behavior by setting a 'explicit_be_open'
flag.
We additionally add missing OPENED events for stdio backends on w32,
which were previously not being issued, causing us to not recieve the
banner and initial prompts for qmp/hmp.
Reported-by: Stefan Priebe <s.priebe@profihost.ag>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1370636393-21044-1-git-send-email-mdroth@linux.vnet.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-06-07 20:19:53 +00:00
|
|
|
}
|
2009-09-10 08:58:50 +00:00
|
|
|
|
2016-12-09 08:04:51 +00:00
|
|
|
out:
|
2014-09-02 10:24:16 +00:00
|
|
|
qapi_free_ChardevBackend(backend);
|
|
|
|
g_free(bid);
|
2009-09-10 08:58:35 +00:00
|
|
|
return chr;
|
|
|
|
}
|
|
|
|
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
Chardev *qemu_chr_new_noreplay(const char *label, const char *filename,
|
2019-02-13 13:18:13 +00:00
|
|
|
bool permit_mux_mon, GMainContext *context)
|
2008-10-31 18:49:55 +00:00
|
|
|
{
|
|
|
|
const char *p;
|
2016-12-07 13:20:22 +00:00
|
|
|
Chardev *chr;
|
2009-09-10 08:58:35 +00:00
|
|
|
QemuOpts *opts;
|
2012-10-15 07:28:05 +00:00
|
|
|
Error *err = NULL;
|
2009-09-10 08:58:35 +00:00
|
|
|
|
2009-09-10 08:58:52 +00:00
|
|
|
if (strstart(filename, "chardev:", &p)) {
|
|
|
|
return qemu_chr_find(p);
|
|
|
|
}
|
|
|
|
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
opts = qemu_chr_parse_compat(label, filename, permit_mux_mon);
|
2009-09-10 08:58:51 +00:00
|
|
|
if (!opts)
|
|
|
|
return NULL;
|
2008-10-31 18:49:55 +00:00
|
|
|
|
2019-02-13 13:18:13 +00:00
|
|
|
chr = qemu_chr_new_from_opts(opts, context, &err);
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
if (!chr) {
|
2015-02-12 12:55:05 +00:00
|
|
|
error_report_err(err);
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
goto out;
|
2012-10-15 07:28:05 +00:00
|
|
|
}
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
|
|
|
|
if (qemu_opt_get_bool(opts, "mux", 0)) {
|
|
|
|
assert(permit_mux_mon);
|
2009-09-10 08:58:51 +00:00
|
|
|
monitor_init(chr, MONITOR_USE_READLINE);
|
2008-10-31 18:49:55 +00:00
|
|
|
}
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
|
|
|
|
out:
|
net: don't poke at chardev internal QemuOpts
The vhost-user & colo code is poking at the QemuOpts instance
in the CharDriverState struct, not realizing that it is valid
for this to be NULL. e.g. the following crash shows a codepath
where it will be NULL:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650 <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at util/qemu-option.c:617
617 QTAILQ_FOREACH(opt, &opts->head, next) {
[Current thread is 1 (Thread 0x7f1d4970bb40 (LWP 6603))]
(gdb) bt
#0 0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650 <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at util/qemu-option.c:617
#1 0x000055baf696b7da in net_vhost_parse_chardev (opts=0x55baf8ff9260, errp=0x7ffc51368e48) at net/vhost-user.c:314
#2 0x000055baf696b985 in net_init_vhost_user (netdev=0x55baf8ff9250, name=0x55baf879d270 "hostnet2", peer=0x0, errp=0x7ffc51368e48) at net/vhost-user.c:360
#3 0x000055baf6960216 in net_client_init1 (object=0x55baf8ff9250, is_netdev=true, errp=0x7ffc51368e48) at net/net.c:1051
#4 0x000055baf6960518 in net_client_init (opts=0x55baf776e7e0, is_netdev=true, errp=0x7ffc51368f00) at net/net.c:1108
#5 0x000055baf696083f in netdev_add (opts=0x55baf776e7e0, errp=0x7ffc51368f00) at net/net.c:1186
#6 0x000055baf69608c7 in qmp_netdev_add (qdict=0x55baf7afaf60, ret=0x7ffc51368f50, errp=0x7ffc51368f48) at net/net.c:1205
#7 0x000055baf6622135 in handle_qmp_command (parser=0x55baf77fb590, tokens=0x7f1d24011960) at /path/to/qemu.git/monitor.c:3978
#8 0x000055baf6a9d099 in json_message_process_token (lexer=0x55baf77fb598, input=0x55baf75acd20, type=JSON_RCURLY, x=113, y=19) at qobject/json-streamer.c:105
#9 0x000055baf6abf7aa in json_lexer_feed_char (lexer=0x55baf77fb598, ch=125 '}', flush=false) at qobject/json-lexer.c:319
#10 0x000055baf6abf8f2 in json_lexer_feed (lexer=0x55baf77fb598, buffer=0x7ffc51369170 "}R\204\367\272U", size=1) at qobject/json-lexer.c:369
#11 0x000055baf6a9d13c in json_message_parser_feed (parser=0x55baf77fb590, buffer=0x7ffc51369170 "}R\204\367\272U", size=1) at qobject/json-streamer.c:124
#12 0x000055baf66221f7 in monitor_qmp_read (opaque=0x55baf77fb530, buf=0x7ffc51369170 "}R\204\367\272U", size=1) at /path/to/qemu.git/monitor.c:3994
#13 0x000055baf6757014 in qemu_chr_be_write_impl (s=0x55baf7610a40, buf=0x7ffc51369170 "}R\204\367\272U", len=1) at qemu-char.c:387
#14 0x000055baf6757076 in qemu_chr_be_write (s=0x55baf7610a40, buf=0x7ffc51369170 "}R\204\367\272U", len=1) at qemu-char.c:399
#15 0x000055baf675b3b0 in tcp_chr_read (chan=0x55baf90244b0, cond=G_IO_IN, opaque=0x55baf7610a40) at qemu-char.c:2927
#16 0x000055baf6a5d655 in qio_channel_fd_source_dispatch (source=0x55baf7610df0, callback=0x55baf675b25a <tcp_chr_read>, user_data=0x55baf7610a40) at io/channel-watch.c:84
#17 0x00007f1d3e80cbbd in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#18 0x000055baf69d3720 in glib_pollfds_poll () at main-loop.c:213
#19 0x000055baf69d37fd in os_host_main_loop_wait (timeout=126000000) at main-loop.c:258
#20 0x000055baf69d38ad in main_loop_wait (nonblocking=0) at main-loop.c:506
#21 0x000055baf676587b in main_loop () at vl.c:1908
#22 0x000055baf676d3bf in main (argc=101, argv=0x7ffc5136a6c8, envp=0x7ffc5136a9f8) at vl.c:4604
(gdb) p opts
$1 = (QemuOpts *) 0x0
The crash occurred when attaching vhost-user net via QMP:
{
"execute": "chardev-add",
"arguments": {
"id": "charnet2",
"backend": {
"type": "socket",
"data": {
"addr": {
"type": "unix",
"data": {
"path": "/var/run/openvswitch/vhost-user1"
}
},
"wait": false,
"server": false
}
}
},
"id": "libvirt-19"
}
{
"return": {
},
"id": "libvirt-19"
}
{
"execute": "netdev_add",
"arguments": {
"type": "vhost-user",
"chardev": "charnet2",
"id": "hostnet2"
},
"id": "libvirt-20"
}
Code using chardevs should not be poking at the internals of the
CharDriverState struct. What vhost-user wants is a chardev that is
operating as reconnectable network service, along with the ability
to do FD passing over the connection. The colo code simply wants
a network service. Add a feature concept to the char drivers so
that chardev users can query the actual features they wish to have
supported. The QemuOpts member is removed to prevent future mistakes
in this area.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-07 12:18:34 +00:00
|
|
|
qemu_opts_del(opts);
|
2008-10-31 18:49:55 +00:00
|
|
|
return chr;
|
|
|
|
}
|
|
|
|
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
static Chardev *qemu_chr_new_permit_mux_mon(const char *label,
|
|
|
|
const char *filename,
|
2019-02-13 13:18:13 +00:00
|
|
|
bool permit_mux_mon,
|
|
|
|
GMainContext *context)
|
2016-03-14 07:44:36 +00:00
|
|
|
{
|
2016-12-07 13:20:22 +00:00
|
|
|
Chardev *chr;
|
2019-02-13 13:18:13 +00:00
|
|
|
chr = qemu_chr_new_noreplay(label, filename, permit_mux_mon, context);
|
2016-03-14 07:44:36 +00:00
|
|
|
if (chr) {
|
2016-10-21 19:58:45 +00:00
|
|
|
if (replay_mode != REPLAY_MODE_NONE) {
|
|
|
|
qemu_chr_set_feature(chr, QEMU_CHAR_FEATURE_REPLAY);
|
|
|
|
}
|
2016-12-07 15:39:10 +00:00
|
|
|
if (qemu_chr_replay(chr) && CHARDEV_GET_CLASS(chr)->chr_ioctl) {
|
2016-11-30 18:57:24 +00:00
|
|
|
error_report("Replay: ioctl is not supported "
|
|
|
|
"for serial devices yet");
|
2016-03-14 07:44:36 +00:00
|
|
|
}
|
|
|
|
replay_register_char_driver(chr);
|
|
|
|
}
|
|
|
|
return chr;
|
|
|
|
}
|
|
|
|
|
2019-02-13 13:18:13 +00:00
|
|
|
Chardev *qemu_chr_new(const char *label, const char *filename,
|
|
|
|
GMainContext *context)
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
{
|
2019-02-13 13:18:13 +00:00
|
|
|
return qemu_chr_new_permit_mux_mon(label, filename, false, context);
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
}
|
|
|
|
|
2019-02-13 13:18:13 +00:00
|
|
|
Chardev *qemu_chr_new_mux_mon(const char *label, const char *filename,
|
|
|
|
GMainContext *context)
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
{
|
2019-02-13 13:18:13 +00:00
|
|
|
return qemu_chr_new_permit_mux_mon(label, filename, true, context);
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 17:19:42 +00:00
|
|
|
}
|
|
|
|
|
2016-12-14 13:44:19 +00:00
|
|
|
static int qmp_query_chardev_foreach(Object *obj, void *data)
|
2015-06-22 16:20:18 +00:00
|
|
|
{
|
2016-12-14 13:44:19 +00:00
|
|
|
Chardev *chr = CHARDEV(obj);
|
|
|
|
ChardevInfoList **list = data;
|
|
|
|
ChardevInfoList *info = g_malloc0(sizeof(*info));
|
|
|
|
|
|
|
|
info->value = g_malloc0(sizeof(*info->value));
|
|
|
|
info->value->label = g_strdup(chr->label);
|
|
|
|
info->value->filename = g_strdup(chr->filename);
|
|
|
|
info->value->frontend_open = chr->be && chr->be->fe_open;
|
|
|
|
|
|
|
|
info->next = *list;
|
|
|
|
*list = info;
|
|
|
|
|
|
|
|
return 0;
|
2015-06-22 16:20:18 +00:00
|
|
|
}
|
|
|
|
|
2011-09-14 19:05:49 +00:00
|
|
|
ChardevInfoList *qmp_query_chardev(Error **errp)
|
2008-10-31 18:49:55 +00:00
|
|
|
{
|
2011-09-14 19:05:49 +00:00
|
|
|
ChardevInfoList *chr_list = NULL;
|
2008-10-31 18:49:55 +00:00
|
|
|
|
2016-12-14 13:44:19 +00:00
|
|
|
object_child_foreach(get_chardevs_root(),
|
|
|
|
qmp_query_chardev_foreach, &chr_list);
|
2009-12-10 19:16:08 +00:00
|
|
|
|
2011-09-14 19:05:49 +00:00
|
|
|
return chr_list;
|
2008-10-31 18:49:55 +00:00
|
|
|
}
|
2009-09-10 08:58:52 +00:00
|
|
|
|
2016-12-08 21:50:12 +00:00
|
|
|
static void
|
|
|
|
qmp_prepend_backend(const char *name, void *opaque)
|
2016-10-21 13:07:45 +00:00
|
|
|
{
|
2016-12-08 21:50:12 +00:00
|
|
|
ChardevBackendInfoList **list = opaque;
|
2016-10-21 13:07:45 +00:00
|
|
|
ChardevBackendInfoList *info = g_malloc0(sizeof(*info));
|
2016-12-08 21:50:12 +00:00
|
|
|
|
2016-10-21 13:07:45 +00:00
|
|
|
info->value = g_malloc0(sizeof(*info->value));
|
|
|
|
info->value->name = g_strdup(name);
|
2016-12-08 21:50:12 +00:00
|
|
|
info->next = *list;
|
|
|
|
*list = info;
|
2016-10-21 13:07:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-01 11:52:42 +00:00
|
|
|
ChardevBackendInfoList *qmp_query_chardev_backends(Error **errp)
|
|
|
|
{
|
|
|
|
ChardevBackendInfoList *backend_list = NULL;
|
2016-10-21 13:30:29 +00:00
|
|
|
|
2016-12-08 21:50:12 +00:00
|
|
|
chardev_name_foreach(qmp_prepend_backend, &backend_list);
|
2014-02-01 11:52:42 +00:00
|
|
|
|
|
|
|
return backend_list;
|
|
|
|
}
|
|
|
|
|
2016-12-07 13:20:22 +00:00
|
|
|
Chardev *qemu_chr_find(const char *name)
|
2009-09-10 08:58:52 +00:00
|
|
|
{
|
2016-12-14 13:44:19 +00:00
|
|
|
Object *obj = object_resolve_path_component(get_chardevs_root(), name);
|
2009-09-10 08:58:52 +00:00
|
|
|
|
2016-12-14 13:44:19 +00:00
|
|
|
return obj ? CHARDEV(obj) : NULL;
|
2009-09-10 08:58:52 +00:00
|
|
|
}
|
2011-12-22 21:29:25 +00:00
|
|
|
|
2012-11-26 15:03:42 +00:00
|
|
|
QemuOptsList qemu_chardev_opts = {
|
|
|
|
.name = "chardev",
|
|
|
|
.implied_opt_name = "backend",
|
|
|
|
.head = QTAILQ_HEAD_INITIALIZER(qemu_chardev_opts.head),
|
|
|
|
.desc = {
|
|
|
|
{
|
|
|
|
.name = "backend",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "path",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "host",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "port",
|
|
|
|
.type = QEMU_OPT_STRING,
|
char: allow passing pre-opened socket file descriptor at startup
When starting QEMU management apps will usually setup a monitor socket, and
then open it immediately after startup. If not using QEMU's own -daemonize
arg, this process can be troublesome to handle correctly. The mgmt app will
need to repeatedly call connect() until it succeeds, because it does not
know when QEMU has created the listener socket. If can't retry connect()
forever though, because an error might have caused QEMU to exit before it
even creates the monitor.
The obvious way to fix this kind of problem is to just pass in a pre-opened
socket file descriptor for the QEMU monitor to listen on. The management
app can now immediately call connect() just once. If connect() fails it
knows that QEMU has exited with an error.
The SocketAddress(Legacy) structs allow for FD passing via the monitor, and
now via inherited file descriptors from the process that spawned QEMU. The
final missing piece is adding a 'fd' parameter in the socket chardev
options.
This allows both HMP usage, pass any FD number with SCM_RIGHTS, then
running HMP commands:
getfd myfd
chardev-add socket,fd=myfd
Note that numeric FDs cannot be referenced directly in HMP, only named FDs.
And also CLI usage, by leak FD 3 from parent by clearing O_CLOEXEC, then
spawning QEMU with
-chardev socket,fd=3,id=mon
-mon chardev=mon,mode=control
Note that named FDs cannot be referenced in CLI args, only numeric FDs.
We do not wire this up in the legacy chardev syntax, so you cannot use FD
passing with '-qmp', you must use the modern '-mon' + '-chardev' pair.
When passing pre-opened FDs there is a restriction on use of TLS encryption.
It can be used on a server socket chardev, but cannot be used for a client
socket chardev. This is because when validating a server's certificate, the
client needs to have a hostname available to match against the certificate
identity.
An illustrative example of usage is:
#!/usr/bin/perl
use IO::Socket::UNIX;
use Fcntl;
unlink "/tmp/qmp";
my $srv = IO::Socket::UNIX->new(
Type => SOCK_STREAM(),
Local => "/tmp/qmp",
Listen => 1,
);
my $flags = fcntl $srv, F_GETFD, 0;
fcntl $srv, F_SETFD, $flags & ~FD_CLOEXEC;
my $fd = $srv->fileno();
exec "qemu-system-x86_64", \
"-chardev", "socket,fd=$fd,server,nowait,id=mon", \
"-mon", "chardev=mon,mode=control";
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-12-21 12:57:54 +00:00
|
|
|
},{
|
|
|
|
.name = "fd",
|
|
|
|
.type = QEMU_OPT_STRING,
|
2012-11-26 15:03:42 +00:00
|
|
|
},{
|
|
|
|
.name = "localaddr",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "localport",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "to",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
},{
|
|
|
|
.name = "ipv4",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "ipv6",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "wait",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "server",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "delay",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2014-10-02 16:17:37 +00:00
|
|
|
},{
|
|
|
|
.name = "reconnect",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
2012-11-26 15:03:42 +00:00
|
|
|
},{
|
|
|
|
.name = "telnet",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2016-09-23 06:06:11 +00:00
|
|
|
},{
|
|
|
|
.name = "tn3270",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
char: introduce support for TLS encrypted TCP chardev backend
This integrates support for QIOChannelTLS object in the TCP
chardev backend. If the 'tls-creds=NAME' option is passed with
the '-chardev tcp' argument, then it will setup the chardev
such that the client is required to establish a TLS handshake
when connecting. There is no support for checking the client
certificate against ACLs in this initial patch. This is pending
work to QOM-ify the ACL object code.
A complete invocation to run QEMU as the server for a TLS
encrypted serial dev might be
$ qemu-system-x86_64 \
-nodefconfig -nodefaults -device sga -display none \
-chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0,server \
-device isa-serial,chardev=s0 \
-object tls-creds-x509,id=tls0,endpoint=server,verify-peer=off,\
dir=/home/berrange/security/qemutls
To test with the gnutls-cli tool as the client:
$ gnutls-cli --priority=NORMAL -p 9000 \
--x509cafile=/home/berrange/security/qemutls/ca-cert.pem \
127.0.0.1
If QEMU was told to use 'anon' credential type, then use the
priority string 'NORMAL:+ANON-DH' with gnutls-cli
Alternatively, if setting up a chardev to operate as a client,
then the TLS credentials registered must be for the client
endpoint. First a TLS server must be setup, which can be done
with the gnutls-serv tool
$ gnutls-serv --priority=NORMAL -p 9000 --echo \
--x509cafile=/home/berrange/security/qemutls/ca-cert.pem \
--x509certfile=/home/berrange/security/qemutls/server-cert.pem \
--x509keyfile=/home/berrange/security/qemutls/server-key.pem
Then QEMU can connect with
$ qemu-system-x86_64 \
-nodefconfig -nodefaults -device sga -display none \
-chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0 \
-device isa-serial,chardev=s0 \
-object tls-creds-x509,id=tls0,endpoint=client,\
dir=/home/berrange/security/qemutls
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1453202071-10289-5-git-send-email-berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-19 11:14:31 +00:00
|
|
|
},{
|
|
|
|
.name = "tls-creds",
|
|
|
|
.type = QEMU_OPT_STRING,
|
2018-10-18 22:35:00 +00:00
|
|
|
},{
|
|
|
|
.name = "websocket",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2012-11-26 15:03:42 +00:00
|
|
|
},{
|
|
|
|
.name = "width",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
},{
|
|
|
|
.name = "height",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
},{
|
|
|
|
.name = "cols",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
},{
|
|
|
|
.name = "rows",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
},{
|
|
|
|
.name = "mux",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "signal",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "name",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "debug",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
2013-01-24 16:03:19 +00:00
|
|
|
},{
|
qemu-char: Saner naming of memchar stuff & doc fixes
New device, has never been released, so we can still improve things
without worrying about compatibility.
Naming is a mess. The code calls the device driver CirMemCharDriver,
the public API calls it "memory", "memchardev", or "memchar", and the
special commands are named like "memchar-FOO". "memory" is a
particularly unfortunate choice, because there's another character
device driver called MemoryDriver. Moreover, the device's distinctive
property is that it's a ring buffer, not that's in memory. Therefore:
* Rename CirMemCharDriver to RingBufCharDriver, and call the thing a
"ringbuf" in the API.
* Rename QMP and HMP commands from memchar-FOO to ringbuf-FOO.
* Rename device parameter from maxcapacity to size (simple words are
good for you).
* Clearly mark the parameter as optional in documentation.
* Fix error reporting so that chardev-add reports to current monitor,
not stderr.
* Replace cirmem in C identifiers by ringbuf.
* Rework documentation. Document the impact of our crappy UTF-8
handling on reading.
* QMP examples that even work.
I could split this up into multiple commits, but they'd change the
same documentation lines multiple times. Not worth it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-06 20:27:24 +00:00
|
|
|
.name = "size",
|
2013-02-06 20:27:25 +00:00
|
|
|
.type = QEMU_OPT_SIZE,
|
2013-06-24 06:39:54 +00:00
|
|
|
},{
|
|
|
|
.name = "chardev",
|
|
|
|
.type = QEMU_OPT_STRING,
|
2015-12-04 06:42:04 +00:00
|
|
|
},{
|
|
|
|
.name = "append",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
qemu-char: add logfile facility to all chardev backends
Typically a UNIX guest OS will log boot messages to a serial
port in addition to any graphical console. An admin user
may also wish to use the serial port for an interactive
console. A virtualization management system may wish to
collect system boot messages by logging the serial port,
but also wish to allow admins interactive access.
Currently providing such a feature forces the mgmt app
to either provide 2 separate serial ports, one for
logging boot messages and one for interactive console
login, or to proxy all output via a separate service
that can multiplex the two needs onto one serial port.
While both are valid approaches, they each have their
own downsides. The former causes confusion and extra
setup work for VM admins creating disk images. The latter
places an extra burden to re-implement much of the QEMU
chardev backends logic in libvirt or even higher level
mgmt apps and adds extra hops in the data transfer path.
A simpler approach that is satisfactory for many use
cases is to allow the QEMU chardev backends to have a
"logfile" property associated with them.
$QEMU -chardev socket,host=localhost,port=9000,\
server=on,nowait,id-charserial0,\
logfile=/var/log/libvirt/qemu/test-serial0.log
-device isa-serial,chardev=charserial0,id=serial0
This patch introduces a 'ChardevCommon' struct which
is setup as a base for all the ChardevBackend types.
Ideally this would be registered directly as a base
against ChardevBackend, rather than each type, but
the QAPI generator doesn't allow that since the
ChardevBackend is a non-discriminated union. The
ChardevCommon struct provides the optional 'logfile'
parameter, as well as 'logappend' which controls
whether QEMU truncates or appends (default truncate).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
[Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 12:44:41 +00:00
|
|
|
},{
|
|
|
|
.name = "logfile",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "logappend",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2012-11-26 15:03:42 +00:00
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
},
|
|
|
|
};
|
2012-12-19 09:33:56 +00:00
|
|
|
|
2016-12-07 13:20:22 +00:00
|
|
|
bool qemu_chr_has_feature(Chardev *chr,
|
2016-12-14 10:27:58 +00:00
|
|
|
ChardevFeature feature)
|
net: don't poke at chardev internal QemuOpts
The vhost-user & colo code is poking at the QemuOpts instance
in the CharDriverState struct, not realizing that it is valid
for this to be NULL. e.g. the following crash shows a codepath
where it will be NULL:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650 <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at util/qemu-option.c:617
617 QTAILQ_FOREACH(opt, &opts->head, next) {
[Current thread is 1 (Thread 0x7f1d4970bb40 (LWP 6603))]
(gdb) bt
#0 0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650 <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at util/qemu-option.c:617
#1 0x000055baf696b7da in net_vhost_parse_chardev (opts=0x55baf8ff9260, errp=0x7ffc51368e48) at net/vhost-user.c:314
#2 0x000055baf696b985 in net_init_vhost_user (netdev=0x55baf8ff9250, name=0x55baf879d270 "hostnet2", peer=0x0, errp=0x7ffc51368e48) at net/vhost-user.c:360
#3 0x000055baf6960216 in net_client_init1 (object=0x55baf8ff9250, is_netdev=true, errp=0x7ffc51368e48) at net/net.c:1051
#4 0x000055baf6960518 in net_client_init (opts=0x55baf776e7e0, is_netdev=true, errp=0x7ffc51368f00) at net/net.c:1108
#5 0x000055baf696083f in netdev_add (opts=0x55baf776e7e0, errp=0x7ffc51368f00) at net/net.c:1186
#6 0x000055baf69608c7 in qmp_netdev_add (qdict=0x55baf7afaf60, ret=0x7ffc51368f50, errp=0x7ffc51368f48) at net/net.c:1205
#7 0x000055baf6622135 in handle_qmp_command (parser=0x55baf77fb590, tokens=0x7f1d24011960) at /path/to/qemu.git/monitor.c:3978
#8 0x000055baf6a9d099 in json_message_process_token (lexer=0x55baf77fb598, input=0x55baf75acd20, type=JSON_RCURLY, x=113, y=19) at qobject/json-streamer.c:105
#9 0x000055baf6abf7aa in json_lexer_feed_char (lexer=0x55baf77fb598, ch=125 '}', flush=false) at qobject/json-lexer.c:319
#10 0x000055baf6abf8f2 in json_lexer_feed (lexer=0x55baf77fb598, buffer=0x7ffc51369170 "}R\204\367\272U", size=1) at qobject/json-lexer.c:369
#11 0x000055baf6a9d13c in json_message_parser_feed (parser=0x55baf77fb590, buffer=0x7ffc51369170 "}R\204\367\272U", size=1) at qobject/json-streamer.c:124
#12 0x000055baf66221f7 in monitor_qmp_read (opaque=0x55baf77fb530, buf=0x7ffc51369170 "}R\204\367\272U", size=1) at /path/to/qemu.git/monitor.c:3994
#13 0x000055baf6757014 in qemu_chr_be_write_impl (s=0x55baf7610a40, buf=0x7ffc51369170 "}R\204\367\272U", len=1) at qemu-char.c:387
#14 0x000055baf6757076 in qemu_chr_be_write (s=0x55baf7610a40, buf=0x7ffc51369170 "}R\204\367\272U", len=1) at qemu-char.c:399
#15 0x000055baf675b3b0 in tcp_chr_read (chan=0x55baf90244b0, cond=G_IO_IN, opaque=0x55baf7610a40) at qemu-char.c:2927
#16 0x000055baf6a5d655 in qio_channel_fd_source_dispatch (source=0x55baf7610df0, callback=0x55baf675b25a <tcp_chr_read>, user_data=0x55baf7610a40) at io/channel-watch.c:84
#17 0x00007f1d3e80cbbd in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#18 0x000055baf69d3720 in glib_pollfds_poll () at main-loop.c:213
#19 0x000055baf69d37fd in os_host_main_loop_wait (timeout=126000000) at main-loop.c:258
#20 0x000055baf69d38ad in main_loop_wait (nonblocking=0) at main-loop.c:506
#21 0x000055baf676587b in main_loop () at vl.c:1908
#22 0x000055baf676d3bf in main (argc=101, argv=0x7ffc5136a6c8, envp=0x7ffc5136a9f8) at vl.c:4604
(gdb) p opts
$1 = (QemuOpts *) 0x0
The crash occurred when attaching vhost-user net via QMP:
{
"execute": "chardev-add",
"arguments": {
"id": "charnet2",
"backend": {
"type": "socket",
"data": {
"addr": {
"type": "unix",
"data": {
"path": "/var/run/openvswitch/vhost-user1"
}
},
"wait": false,
"server": false
}
}
},
"id": "libvirt-19"
}
{
"return": {
},
"id": "libvirt-19"
}
{
"execute": "netdev_add",
"arguments": {
"type": "vhost-user",
"chardev": "charnet2",
"id": "hostnet2"
},
"id": "libvirt-20"
}
Code using chardevs should not be poking at the internals of the
CharDriverState struct. What vhost-user wants is a chardev that is
operating as reconnectable network service, along with the ability
to do FD passing over the connection. The colo code simply wants
a network service. Add a feature concept to the char drivers so
that chardev users can query the actual features they wish to have
supported. The QemuOpts member is removed to prevent future mistakes
in this area.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-07 12:18:34 +00:00
|
|
|
{
|
|
|
|
return test_bit(feature, chr->features);
|
|
|
|
}
|
|
|
|
|
2016-12-07 13:20:22 +00:00
|
|
|
void qemu_chr_set_feature(Chardev *chr,
|
2016-12-14 10:27:58 +00:00
|
|
|
ChardevFeature feature)
|
net: don't poke at chardev internal QemuOpts
The vhost-user & colo code is poking at the QemuOpts instance
in the CharDriverState struct, not realizing that it is valid
for this to be NULL. e.g. the following crash shows a codepath
where it will be NULL:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650 <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at util/qemu-option.c:617
617 QTAILQ_FOREACH(opt, &opts->head, next) {
[Current thread is 1 (Thread 0x7f1d4970bb40 (LWP 6603))]
(gdb) bt
#0 0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650 <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at util/qemu-option.c:617
#1 0x000055baf696b7da in net_vhost_parse_chardev (opts=0x55baf8ff9260, errp=0x7ffc51368e48) at net/vhost-user.c:314
#2 0x000055baf696b985 in net_init_vhost_user (netdev=0x55baf8ff9250, name=0x55baf879d270 "hostnet2", peer=0x0, errp=0x7ffc51368e48) at net/vhost-user.c:360
#3 0x000055baf6960216 in net_client_init1 (object=0x55baf8ff9250, is_netdev=true, errp=0x7ffc51368e48) at net/net.c:1051
#4 0x000055baf6960518 in net_client_init (opts=0x55baf776e7e0, is_netdev=true, errp=0x7ffc51368f00) at net/net.c:1108
#5 0x000055baf696083f in netdev_add (opts=0x55baf776e7e0, errp=0x7ffc51368f00) at net/net.c:1186
#6 0x000055baf69608c7 in qmp_netdev_add (qdict=0x55baf7afaf60, ret=0x7ffc51368f50, errp=0x7ffc51368f48) at net/net.c:1205
#7 0x000055baf6622135 in handle_qmp_command (parser=0x55baf77fb590, tokens=0x7f1d24011960) at /path/to/qemu.git/monitor.c:3978
#8 0x000055baf6a9d099 in json_message_process_token (lexer=0x55baf77fb598, input=0x55baf75acd20, type=JSON_RCURLY, x=113, y=19) at qobject/json-streamer.c:105
#9 0x000055baf6abf7aa in json_lexer_feed_char (lexer=0x55baf77fb598, ch=125 '}', flush=false) at qobject/json-lexer.c:319
#10 0x000055baf6abf8f2 in json_lexer_feed (lexer=0x55baf77fb598, buffer=0x7ffc51369170 "}R\204\367\272U", size=1) at qobject/json-lexer.c:369
#11 0x000055baf6a9d13c in json_message_parser_feed (parser=0x55baf77fb590, buffer=0x7ffc51369170 "}R\204\367\272U", size=1) at qobject/json-streamer.c:124
#12 0x000055baf66221f7 in monitor_qmp_read (opaque=0x55baf77fb530, buf=0x7ffc51369170 "}R\204\367\272U", size=1) at /path/to/qemu.git/monitor.c:3994
#13 0x000055baf6757014 in qemu_chr_be_write_impl (s=0x55baf7610a40, buf=0x7ffc51369170 "}R\204\367\272U", len=1) at qemu-char.c:387
#14 0x000055baf6757076 in qemu_chr_be_write (s=0x55baf7610a40, buf=0x7ffc51369170 "}R\204\367\272U", len=1) at qemu-char.c:399
#15 0x000055baf675b3b0 in tcp_chr_read (chan=0x55baf90244b0, cond=G_IO_IN, opaque=0x55baf7610a40) at qemu-char.c:2927
#16 0x000055baf6a5d655 in qio_channel_fd_source_dispatch (source=0x55baf7610df0, callback=0x55baf675b25a <tcp_chr_read>, user_data=0x55baf7610a40) at io/channel-watch.c:84
#17 0x00007f1d3e80cbbd in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#18 0x000055baf69d3720 in glib_pollfds_poll () at main-loop.c:213
#19 0x000055baf69d37fd in os_host_main_loop_wait (timeout=126000000) at main-loop.c:258
#20 0x000055baf69d38ad in main_loop_wait (nonblocking=0) at main-loop.c:506
#21 0x000055baf676587b in main_loop () at vl.c:1908
#22 0x000055baf676d3bf in main (argc=101, argv=0x7ffc5136a6c8, envp=0x7ffc5136a9f8) at vl.c:4604
(gdb) p opts
$1 = (QemuOpts *) 0x0
The crash occurred when attaching vhost-user net via QMP:
{
"execute": "chardev-add",
"arguments": {
"id": "charnet2",
"backend": {
"type": "socket",
"data": {
"addr": {
"type": "unix",
"data": {
"path": "/var/run/openvswitch/vhost-user1"
}
},
"wait": false,
"server": false
}
}
},
"id": "libvirt-19"
}
{
"return": {
},
"id": "libvirt-19"
}
{
"execute": "netdev_add",
"arguments": {
"type": "vhost-user",
"chardev": "charnet2",
"id": "hostnet2"
},
"id": "libvirt-20"
}
Code using chardevs should not be poking at the internals of the
CharDriverState struct. What vhost-user wants is a chardev that is
operating as reconnectable network service, along with the ability
to do FD passing over the connection. The colo code simply wants
a network service. Add a feature concept to the char drivers so
that chardev users can query the actual features they wish to have
supported. The QemuOpts member is removed to prevent future mistakes
in this area.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-07 12:18:34 +00:00
|
|
|
{
|
|
|
|
return set_bit(feature, chr->features);
|
|
|
|
}
|
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
Chardev *qemu_chardev_new(const char *id, const char *typename,
|
2016-12-14 12:23:36 +00:00
|
|
|
ChardevBackend *backend,
|
2019-02-13 13:18:13 +00:00
|
|
|
GMainContext *gcontext,
|
2016-12-14 12:23:36 +00:00
|
|
|
Error **errp)
|
2012-12-19 09:33:56 +00:00
|
|
|
{
|
2016-12-14 12:23:36 +00:00
|
|
|
Object *obj;
|
2016-12-07 13:20:22 +00:00
|
|
|
Chardev *chr = NULL;
|
2015-09-29 12:54:05 +00:00
|
|
|
Error *local_err = NULL;
|
2016-10-22 10:09:43 +00:00
|
|
|
bool be_opened = true;
|
2012-12-19 09:33:56 +00:00
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
assert(g_str_has_prefix(typename, "chardev-"));
|
2012-12-19 09:33:56 +00:00
|
|
|
|
2016-12-14 12:23:36 +00:00
|
|
|
obj = object_new(typename);
|
|
|
|
chr = CHARDEV(obj);
|
2016-12-07 15:39:10 +00:00
|
|
|
chr->label = g_strdup(id);
|
2019-02-13 13:18:13 +00:00
|
|
|
chr->gcontext = gcontext;
|
2015-09-29 12:55:59 +00:00
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
qemu_char_open(chr, backend, &be_opened, &local_err);
|
2016-10-21 13:30:29 +00:00
|
|
|
if (local_err) {
|
2016-12-14 12:23:36 +00:00
|
|
|
goto end;
|
2015-09-29 12:54:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!chr->filename) {
|
2016-12-07 15:39:10 +00:00
|
|
|
chr->filename = g_strdup(typename + 8);
|
2012-12-19 09:33:56 +00:00
|
|
|
}
|
2016-10-22 10:09:43 +00:00
|
|
|
if (be_opened) {
|
2015-09-29 12:54:05 +00:00
|
|
|
qemu_chr_be_event(chr, CHR_EVENT_OPENED);
|
|
|
|
}
|
2016-12-07 15:39:10 +00:00
|
|
|
|
2016-12-14 12:23:36 +00:00
|
|
|
if (id) {
|
|
|
|
object_property_add_child(get_chardevs_root(), id, obj, &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
object_unref(obj);
|
|
|
|
}
|
|
|
|
|
|
|
|
end:
|
|
|
|
if (local_err) {
|
|
|
|
error_propagate(errp, local_err);
|
|
|
|
object_unref(obj);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-12-07 15:39:10 +00:00
|
|
|
return chr;
|
|
|
|
}
|
|
|
|
|
|
|
|
ChardevReturn *qmp_chardev_add(const char *id, ChardevBackend *backend,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
const ChardevClass *cc;
|
|
|
|
ChardevReturn *ret;
|
|
|
|
Chardev *chr;
|
|
|
|
|
2017-08-24 08:46:08 +00:00
|
|
|
cc = char_get_class(ChardevBackendKind_str(backend->type), errp);
|
2016-12-07 15:39:10 +00:00
|
|
|
if (!cc) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-12-14 17:58:50 +00:00
|
|
|
chr = qemu_chardev_new(id, object_class_get_name(OBJECT_CLASS(cc)),
|
2019-02-13 13:18:13 +00:00
|
|
|
backend, NULL, errp);
|
2016-12-07 15:39:10 +00:00
|
|
|
if (!chr) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = g_new0(ChardevReturn, 1);
|
|
|
|
if (CHARDEV_IS_PTY(chr)) {
|
|
|
|
ret->pty = g_strdup(chr->filename + 4);
|
|
|
|
ret->has_pty = true;
|
|
|
|
}
|
|
|
|
|
2015-09-29 12:54:05 +00:00
|
|
|
return ret;
|
2012-12-19 09:33:56 +00:00
|
|
|
}
|
|
|
|
|
char: chardevice hotswap
This patch adds a possibility to change a char device without a frontend
removal.
Ideally, it would have to happen transparently to a frontend, i.e.
frontend would continue its regular operation.
However, backends are not stateless and are set up by the frontends
via qemu_chr_fe_<> functions, and it's not (generally) possible to replay
that setup entirely in a backend code, as different chardevs respond
to the setup calls differently, so do frontends work differently basing
on those setup responses.
Moreover, some frontend can generally get and save the backend pointer
(qemu_chr_fe_get_driver()), and it will become invalid after backend change.
So, a frontend which would like to support chardev hotswap has to register
a "backend change" handler, and redo its backend setup there.
Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <1499342940-56739-4-git-send-email-anton.nefedov@virtuozzo.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-06 12:08:50 +00:00
|
|
|
ChardevReturn *qmp_chardev_change(const char *id, ChardevBackend *backend,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
CharBackend *be;
|
|
|
|
const ChardevClass *cc;
|
|
|
|
Chardev *chr, *chr_new;
|
|
|
|
bool closed_sent = false;
|
|
|
|
ChardevReturn *ret;
|
|
|
|
|
|
|
|
chr = qemu_chr_find(id);
|
|
|
|
if (!chr) {
|
|
|
|
error_setg(errp, "Chardev '%s' does not exist", id);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (CHARDEV_IS_MUX(chr)) {
|
|
|
|
error_setg(errp, "Mux device hotswap not supported yet");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (qemu_chr_replay(chr)) {
|
|
|
|
error_setg(errp,
|
|
|
|
"Chardev '%s' cannot be changed in record/replay mode", id);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
be = chr->be;
|
|
|
|
if (!be) {
|
|
|
|
/* easy case */
|
|
|
|
object_unparent(OBJECT(chr));
|
|
|
|
return qmp_chardev_add(id, backend, errp);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!be->chr_be_change) {
|
|
|
|
error_setg(errp, "Chardev user does not support chardev hotswap");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-08-24 08:46:08 +00:00
|
|
|
cc = char_get_class(ChardevBackendKind_str(backend->type), errp);
|
char: chardevice hotswap
This patch adds a possibility to change a char device without a frontend
removal.
Ideally, it would have to happen transparently to a frontend, i.e.
frontend would continue its regular operation.
However, backends are not stateless and are set up by the frontends
via qemu_chr_fe_<> functions, and it's not (generally) possible to replay
that setup entirely in a backend code, as different chardevs respond
to the setup calls differently, so do frontends work differently basing
on those setup responses.
Moreover, some frontend can generally get and save the backend pointer
(qemu_chr_fe_get_driver()), and it will become invalid after backend change.
So, a frontend which would like to support chardev hotswap has to register
a "backend change" handler, and redo its backend setup there.
Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <1499342940-56739-4-git-send-email-anton.nefedov@virtuozzo.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-06 12:08:50 +00:00
|
|
|
if (!cc) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
chr_new = qemu_chardev_new(NULL, object_class_get_name(OBJECT_CLASS(cc)),
|
2019-02-13 13:18:13 +00:00
|
|
|
backend, chr->gcontext, errp);
|
char: chardevice hotswap
This patch adds a possibility to change a char device without a frontend
removal.
Ideally, it would have to happen transparently to a frontend, i.e.
frontend would continue its regular operation.
However, backends are not stateless and are set up by the frontends
via qemu_chr_fe_<> functions, and it's not (generally) possible to replay
that setup entirely in a backend code, as different chardevs respond
to the setup calls differently, so do frontends work differently basing
on those setup responses.
Moreover, some frontend can generally get and save the backend pointer
(qemu_chr_fe_get_driver()), and it will become invalid after backend change.
So, a frontend which would like to support chardev hotswap has to register
a "backend change" handler, and redo its backend setup there.
Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <1499342940-56739-4-git-send-email-anton.nefedov@virtuozzo.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-06 12:08:50 +00:00
|
|
|
if (!chr_new) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
chr_new->label = g_strdup(id);
|
|
|
|
|
|
|
|
if (chr->be_open && !chr_new->be_open) {
|
|
|
|
qemu_chr_be_event(chr, CHR_EVENT_CLOSED);
|
|
|
|
closed_sent = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
chr->be = NULL;
|
|
|
|
qemu_chr_fe_init(be, chr_new, &error_abort);
|
|
|
|
|
|
|
|
if (be->chr_be_change(be->opaque) < 0) {
|
|
|
|
error_setg(errp, "Chardev '%s' change failed", chr_new->label);
|
|
|
|
chr_new->be = NULL;
|
|
|
|
qemu_chr_fe_init(be, chr, &error_abort);
|
|
|
|
if (closed_sent) {
|
|
|
|
qemu_chr_be_event(chr, CHR_EVENT_OPENED);
|
|
|
|
}
|
|
|
|
object_unref(OBJECT(chr_new));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
object_unparent(OBJECT(chr));
|
|
|
|
object_property_add_child(get_chardevs_root(), chr_new->label,
|
|
|
|
OBJECT(chr_new), &error_abort);
|
|
|
|
object_unref(OBJECT(chr_new));
|
|
|
|
|
|
|
|
ret = g_new0(ChardevReturn, 1);
|
|
|
|
if (CHARDEV_IS_PTY(chr_new)) {
|
|
|
|
ret->pty = g_strdup(chr_new->filename + 4);
|
|
|
|
ret->has_pty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-12-19 09:33:56 +00:00
|
|
|
void qmp_chardev_remove(const char *id, Error **errp)
|
|
|
|
{
|
2016-12-07 13:20:22 +00:00
|
|
|
Chardev *chr;
|
2012-12-19 09:33:56 +00:00
|
|
|
|
|
|
|
chr = qemu_chr_find(id);
|
2014-08-11 13:00:55 +00:00
|
|
|
if (chr == NULL) {
|
2012-12-19 09:33:56 +00:00
|
|
|
error_setg(errp, "Chardev '%s' not found", id);
|
|
|
|
return;
|
|
|
|
}
|
2016-10-22 09:53:01 +00:00
|
|
|
if (qemu_chr_is_busy(chr)) {
|
2012-12-19 09:33:56 +00:00
|
|
|
error_setg(errp, "Chardev '%s' is busy", id);
|
|
|
|
return;
|
|
|
|
}
|
2016-10-21 19:58:45 +00:00
|
|
|
if (qemu_chr_replay(chr)) {
|
2016-03-14 07:44:36 +00:00
|
|
|
error_setg(errp,
|
|
|
|
"Chardev '%s' cannot be unplugged in record/replay mode", id);
|
|
|
|
return;
|
|
|
|
}
|
2016-12-14 12:23:36 +00:00
|
|
|
object_unparent(OBJECT(chr));
|
2012-12-19 09:33:56 +00:00
|
|
|
}
|
2013-03-05 17:51:28 +00:00
|
|
|
|
2017-06-11 07:48:17 +00:00
|
|
|
void qmp_chardev_send_break(const char *id, Error **errp)
|
|
|
|
{
|
|
|
|
Chardev *chr;
|
|
|
|
|
|
|
|
chr = qemu_chr_find(id);
|
|
|
|
if (chr == NULL) {
|
|
|
|
error_setg(errp, "Chardev '%s' not found", id);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
qemu_chr_be_event(chr, CHR_EVENT_BREAK);
|
|
|
|
}
|
|
|
|
|
2018-01-04 14:18:35 +00:00
|
|
|
/*
|
|
|
|
* Add a timeout callback for the chardev (in milliseconds), return
|
|
|
|
* the GSource object created. Please use this to add timeout hook for
|
|
|
|
* chardev instead of g_timeout_add() and g_timeout_add_seconds(), to
|
|
|
|
* make sure the gcontext that the task bound to is correct.
|
|
|
|
*/
|
|
|
|
GSource *qemu_chr_timeout_add_ms(Chardev *chr, guint ms,
|
|
|
|
GSourceFunc func, void *private)
|
|
|
|
{
|
|
|
|
GSource *source = g_timeout_source_new(ms);
|
|
|
|
|
|
|
|
assert(func);
|
|
|
|
g_source_set_callback(source, func, private, NULL);
|
|
|
|
g_source_attach(source, chr->gcontext);
|
|
|
|
|
|
|
|
return source;
|
|
|
|
}
|
|
|
|
|
char: do not use atexit cleanup handler
It turns out qemu is calling exit() in various places from various
threads without taking much care of resources state. The atexit()
cleanup handlers cannot easily destroy resources that are in use (by
the same thread or other).
Since c1111a24a3, TCG arm guests run into the following abort() when
running tests, the chardev mutex is locked during the write, so
qemu_mutex_destroy() returns an error:
#0 0x00007fffdbb806f5 in raise () at /lib64/libc.so.6
#1 0x00007fffdbb822fa in abort () at /lib64/libc.so.6
#2 0x00005555557616fe in error_exit (err=<optimized out>, msg=msg@entry=0x555555c38c30 <__func__.14622> "qemu_mutex_destroy")
at /home/drjones/code/qemu/util/qemu-thread-posix.c:39
#3 0x0000555555b0be20 in qemu_mutex_destroy (mutex=mutex@entry=0x5555566aa0e0) at /home/drjones/code/qemu/util/qemu-thread-posix.c:57
#4 0x00005555558aab00 in qemu_chr_free_common (chr=0x5555566aa0e0) at /home/drjones/code/qemu/qemu-char.c:4029
#5 0x00005555558b05f9 in qemu_chr_delete (chr=<optimized out>) at /home/drjones/code/qemu/qemu-char.c:4038
#6 0x00005555558b05f9 in qemu_chr_delete (chr=<optimized out>) at /home/drjones/code/qemu/qemu-char.c:4044
#7 0x00005555558b062c in qemu_chr_cleanup () at /home/drjones/code/qemu/qemu-char.c:4557
#8 0x00007fffdbb851e8 in __run_exit_handlers () at /lib64/libc.so.6
#9 0x00007fffdbb85235 in () at /lib64/libc.so.6
#10 0x00005555558d1b39 in testdev_write (testdev=0x5555566aa0a0) at /home/drjones/code/qemu/backends/testdev.c:71
#11 0x00005555558d1b39 in testdev_write (chr=<optimized out>, buf=0x7fffc343fd9a "", len=0) at /home/drjones/code/qemu/backends/testdev.c:95
#12 0x00005555558adced in qemu_chr_fe_write (s=0x5555566aa0e0, buf=buf@entry=0x7fffc343fd98 "0q", len=len@entry=2) at /home/drjones/code/qemu/qemu-char.c:282
Instead of using a atexit() handler, only run the chardev cleanup as
initially proposed at the end of main(), where there are less chances
(hic) of conflicts or other races.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reported-by: Andrew Jones <drjones@redhat.com>
Message-Id: <20160704153823.16879-1-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-07-04 15:38:23 +00:00
|
|
|
void qemu_chr_cleanup(void)
|
2016-06-16 19:28:50 +00:00
|
|
|
{
|
2016-12-14 12:23:36 +00:00
|
|
|
object_unparent(get_chardevs_root());
|
2016-06-16 19:28:50 +00:00
|
|
|
}
|
|
|
|
|
2013-03-05 17:51:28 +00:00
|
|
|
static void register_types(void)
|
|
|
|
{
|
2016-12-08 21:50:12 +00:00
|
|
|
type_register_static(&char_type_info);
|
2016-10-21 13:07:45 +00:00
|
|
|
|
chardev: fix CHR_EVENT_OPENED events for mux chardevs
As of bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec, chardevs no longer use
bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
semantics, we instead defer the CHR_EVENT_OPENED events toward the end
of chardev initialization.
For muxes, this isn't good enough, since a range of FEs must be able
to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
each FE will immediately print it's initial output (prompts, banners,
etc.) just prior to us switching to the next FE as part of
initialization.
The is new and confusing behavior for users, as they'll see output for
things like the HMP monitor, even though their the current mux focus
may be a guest serial port with potentially no output.
We fix this by further deferring CHR_EVENT_OPENED events for FEs
associated with muxes until after machine init by flagging mux chardevs
with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
events until we explicitly set the mux as opened later.
Currently, we must defer till after machine init since we potentially
associate FEs with muxes as part of realize (for instance,
serial_isa_realizefn).
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-30 18:04:22 +00:00
|
|
|
/* this must be done after machine init, since we register FEs with muxes
|
|
|
|
* as part of realize functions like serial_isa_realizefn when -nographic
|
|
|
|
* is specified
|
|
|
|
*/
|
2018-03-06 05:33:16 +00:00
|
|
|
qemu_add_machine_init_done_notifier(&chardev_machine_done_notify);
|
2013-03-05 17:51:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
type_init(register_types);
|