- Oct 03, 2023
-
-
Thomas Huth authored
When starting a guest via libvirt with "virsh start --console ...", the first second of the console output is missing. This is especially annoying on s390x that only has a text console by default and no graphical output - if the bios fails to boot here, the information about what went wrong is completely lost. One part of the problem (there is also some things to be done on the libvirt side) is that QEMU only checks with a 1 second timer whether the other side of the pty is already connected, so the first second of the console output is always lost. This likely used to work better in the past, since the code once checked for a re-connection during write, but this has been removed in commit f8278c7d ("char-pty: remove the check for connection on write") to avoid some locking. To ease the situation here at least a little bit, let's check with g_poll() whether we could send out the data anyway, even if the connection has not been marked as "connected" yet. The file descriptor is marked as non-blocking anyway since commit fac6688a ("Do not hang on full PTY"), so this should not cause any trouble if the other side is not ready for receiving yet. With this patch applied, I can now successfully see the bios output of a s390x guest when running it with "virsh start --console" (with a patched version of virsh that fixes the remaining issues there, too). Reported-by:
Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20230816210743.1319018-1-thuth@redhat.com>
-
- Jun 05, 2023
-
-
Philippe Mathieu-Daudé authored
Mechanical change running Coccinelle spatch with content generated from the qom-cast-macro-clean-cocci-gen.py added in the previous commit. Suggested-by:
Markus Armbruster <armbru@redhat.com> Signed-off-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230601093452.38972-3-philmd@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
Thomas Huth <thuth@redhat.com>
-
- Jan 09, 2023
-
-
Nikita Ivanov authored
There is a defined RETRY_ON_EINTR() macro in qemu/osdep.h which handles the same while loop. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/415 Signed-off-by:
Nikita Ivanov <nivanov@cloudlinux.com> Message-Id: <20221023090422.242617-3-nivanov@cloudlinux.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> [thuth: Dropped the hunk that changed socket_accept() in libqtest.c] Signed-off-by:
Thomas Huth <thuth@redhat.com>
-
- May 03, 2022
-
-
Marc-André Lureau authored
Those calls are either for non-socket fd, or are POSIX-specific. Use the dedicated GLib API. (qemu_set_nonblock() is for socket-like) (this is a preliminary patch before renaming qemu_set_nonblock()) Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com>
-
- Apr 06, 2022
-
-
Marc-André Lureau authored
Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-33-marcandre.lureau@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Marc-André Lureau authored
It is only needed by char-pty. Fix the code style while at it. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-6-marcandre.lureau@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Sep 09, 2020
-
-
Eduardo Habkost authored
Generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]') Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-12-ehabkost@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-13-ehabkost@redhat.com> Message-Id: <20200831210740.126168-14-ehabkost@redhat.com> Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com>
-
Eduardo Habkost authored
Some typedefs and macros are defined after the type check macros. This makes it difficult to automatically replace their definitions with OBJECT_DECLARE_TYPE. Patch generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]') which will split "typdef struct { ... } TypedefName" declarations. Followed by: $ ./scripts/codeconverter/converter.py -i --pattern=MoveSymbols \ $(git grep -l '' -- '*.[ch]') which will: - move the typedefs and #defines above the type check macros - add missing #include "qom/object.h" lines if necessary Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-9-ehabkost@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-10-ehabkost@redhat.com> Message-Id: <20200831210740.126168-11-ehabkost@redhat.com> Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com>
-
- Jun 12, 2019
-
-
Markus Armbruster authored
No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by:
Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]
-
Markus Armbruster authored
Signed-off-by:
Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
-
- Apr 18, 2019
-
-
Markus Armbruster authored
char_pty_open() prints a "char device redirected to PTY_NAME (label LABEL)" message to the current monitor or else to stderr. This is not an error, so it shouldn't go to stderr. Print it to stdout instead. Why is it even printed? No other ChardevClass::open() prints anything on success. It's because you need to know PTY_NAME to actually use this char device, e.g. like e.g. "socat STDIO,cfmakeraw FILE:PTY_NAME" to use the monitor's readline interface. You can get PTY_NAME with "info chardev" (a.k.a. query-chardev for QMP), but only if you already have a monitor. Signed-off-by:
Markus Armbruster <armbru@redhat.com> Message-Id: <20190417190641.26814-15-armbru@redhat.com> Reviewed-by:
Eric Blake <eblake@redhat.com>
-
- Feb 13, 2019
-
-
Marc-André Lureau authored
The lock usage was described with its introduction in commit 9005b2a7. It was necessary because PTY write() shares more state than GIOChannel with other operations. This made char-pty a bit different from other chardev, that only lock around the write operation. This was apparent in commit 7b3621f4, which introduced an idle source to avoid the lock. By removing the PTY chardev state sharing on write() with previous patch, we can remove the lock and the idle source. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190206174328.9736-7-marcandre.lureau@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Marc-André Lureau authored
This doesn't help much compared to the 1 second poll PTY timer. I can't think of a use case where this would help. However, we can simplify the code around chr_write(): the write lock is no longer needed for other char-pty callbacks (see following patch). Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190206174328.9736-6-marcandre.lureau@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Oct 19, 2018
-
-
Markus Armbruster authored
Calling error_report() in a function that takes an Error ** argument is suspicious. Convert a few that are actually help and such to error_printf(). Improves output of -chardev help from qemu-system-x86_64: -chardev help: Available chardev backend types: serial ... to Available chardev backend types: serial ... Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com> Signed-off-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181017082702.5581-8-armbru@redhat.com>
-
- Oct 02, 2018
-
-
Paolo Bonzini authored
For some reason __APPLE__ was not checked in pty code. However, the #ifdef is redundant: this file is already compiled only if CONFIG_POSIX, same as util/qemu-openpty.c which it uses. Reported-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Feb 05, 2018
-
-
Peter Xu authored
glib reported error when pty chardev used: $ ./qemu-system-x86_64 -chardev pty,id=foo -device isa-serial,chardev=foo qemu-system-x86_64: -chardev pty,id=foo: char device redirected to /dev/pts/2 (label foo) (qemu-system-x86_64:27885): GLib-CRITICAL **: g_source_unref: assertion 'source != NULL' failed (qemu-system-x86_64:27885): GLib-CRITICAL **: g_source_unref: assertion 'source != NULL' failed This patch fixes that. Fixes: 2c716ba1 ("chardev: introduce qemu_chr_timeout_add_ms()") CC: Paolo Bonzini <pbonzini@redhat.com> Reported-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <20180118052049.31119-1-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jan 12, 2018
-
-
Peter Xu authored
It's a replacement of g_timeout_add[_seconds]() for chardevs. Chardevs now can have dedicated gcontext, we should always bind chardev tasks onto those gcontext rather than the default main context. Since there are quite a few of g_timeout_add[_seconds]() callers, a new function qemu_chr_timeout_add_ms() is introduced. One thing to mention is that, terminal3270 is still always running on main gcontext. However let's convert that as well since it's still part of chardev codes and in case one day we'll miss that when we move it out of main gcontext too. Also, convert all the timers from GSource tags into GSource pointers. Gsource tag IDs and g_source_remove()s can only work with default gcontext, while now these GSources can logically be attached to other contexts. So let's use explicit g_source_destroy() plus another g_source_unref() to remove a timer. Note: when in the timer handler, we don't need the g_source_destroy() any more since that'll be done automatically if the timer handler returns false (and that's what all the current handlers do). Yet another note: in pty_chr_rearm_timer() we take special care for ms=1000. This patch merged the two cases into one. Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <20180104141835.17987-4-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
The idle task will be attached to main gcontext even if the chardev backend is running in another gcontext. Fix the only caller by extending the g_idle_add() logic into the more powerful g_source_attach(). It's basically g_idle_add_full() implementation, but with the chardev's gcontext passed in. Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <20180104141835.17987-3-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Sep 22, 2017
-
-
Peter Xu authored
We had a per-chardev cache for context, then we don't need this parameter to be passed in every time when chr_update_read_handler() called. As long as we are calling chr_update_read_handler() using qemu_chr_be_update_read_handlers() we'll be fine. Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <1505975754-21555-5-git-send-email-peterx@redhat.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
It was only passed in by chr_update_read_handlers(). However when reconnect, we'll lose that context information. So if a chardev was running on another context (rather than the default context, the NULL pointer), it'll switch back to the default context if reconnection happens. But, it should really stick to the old context. Convert all the callers of io_add_watch_poll() to use the internally cached gcontext. Then the context should be able to survive even after reconnections. Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <1505975754-21555-4-git-send-email-peterx@redhat.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 02, 2017
-
-
Marc-André Lureau authored
So they are all in one place. The following patch will move serial & parallel declarations to the respective headers. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
- May 04, 2017
-
-
Marc-André Lureau authored
The function simply alias and hides the real event function. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
- May 03, 2017
-
-
Hailiang Zhang authored
We use fd_in_tag to find a GSource, fd_in_tag is return value of g_source_attach(GSource *source, GMainContext *context), the return value is unique only in the same context, so we may get the same values with different 'context' parameters. It is no problem to find the right fd_in_tag by using g_main_context_find_source_by_id(GMainContext *context, guint source_id) while there is only one default main context. But colo-compare tries to create/use its own context, and if we pass wrong 'context' parameter with right fd_in_tag, we will find a wrong GSource to handle. We tried to fix the related codes in commit b43decb0, but it didn't fix the bug completely, because we still have some codes didn't pass *right* context parameter for remove_fd_in_watch(). Let's fix it by record the GSource directly instead of fd_in_tag. Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1492564532-91680-1-git-send-email-zhang.zhanghailiang@huawei.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Mar 06, 2017
-
-
Hailiang Zhang authored
We can call qemu_chr_fe_set_handlers() to add/remove fd been watched in 'context' which can be either default main context or other explicit context. But the original logic is not correct, we didn't remove the right fd because we call g_main_context_find_source_by_id(NULL, tag) which always try to find the Gsource from default context. Fix it by passing the right context to g_main_context_find_source_by_id(). Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
- Feb 16, 2017
-
-
Ed Swierk authored
When a serial port writes data to a pty that's disconnected, drop the data and return the length dropped. This avoids triggering pointless retries in callers like the 16550A serial_xmit(), and causes qemu_chr_fe_write() to write all data to the log file, rather than logging only while a pty client like virsh console happens to be connected. Signed-off-by:
Ed Swierk <eswierk@skyportsystems.com> Message-Id: <1485870329-79428-1-git-send-email-eswierk@skyportsystems.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jan 31, 2017
-
-
Marc-André Lureau authored
Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by:
Eric Blake <eblake@redhat.com>
-