[Qemu-devel] Throughput confusion with data plane
Hi, I run one I/O thread (sequential read 4 KB each time and read 8 GB in total) in host OS, the throughput is around 420 MB/s. However, when I run this I/O thread in one VM (no other VM is created and data-plane is enabled) with dedicated hardware, the throughput will be around 350 MB/s. The VM's experiment setting is as follows. In the VM, there are 15 vCPUs (vCPU0 - vCPU14); each vCPU is pinned to corresponding dedicated pCPU (for example, vCPU 0 is pinned to pCPU0 ... vCPU 14 is pinned to pCPU 14); "Idle=poll" is added in the VM's boot grub so that the vCPU will not be idle; in the VM, all the interrupts are pinned to vCPU0 to guarantee these interrupts can be responded on time; the I/O thread is executed on one of the vCPU except vCPU0. In the host OS, there are 16 pCPUs (pCPU0 - pCPU15); pCPU 0 - pCPU 14 are used for vCPU0 - vCPU 14 in the VM dedicatedly; pCPU 15 is used by QEMU IOthread (data-plane) to handle I/O read requests from VM dedicatedly. Kernel version: 3.16.39 QEMU version: 2.4.1 I don't know why there is 70 MB/s difference between host OS and guest OS as above experiment. Does anyone have same experiences? Any comments? Thank you in advance. BTW, I have checked several times about my hardware configuration and I think the throughput difference as above should be related to QEMU. Maybe, I miss any configuration about QEMU. Best, Weiwei Jia
[Qemu-devel] [PATCH] dp8393x: fix dp8393x_receive
address_space_rw() access size must be multiplied by width.
dp8393x_receive() must return the number of bytes read, not the length
of the last memory access.
Signed-off-by: Laurent Vivier
---
hw/net/dp8393x.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index 17f0338..3506bca 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -766,10 +766,11 @@ static ssize_t dp8393x_receive(NetClientState *nc, const
uint8_t * buf,
/* EOL detected */
s->regs[SONIC_ISR] |= SONIC_ISR_RDE;
} else {
+size = sizeof(uint16_t) * width;
data[0 * width] = 0; /* in_use */
address_space_rw(&s->as,
((s->regs[SONIC_URDA] << 16) | s->regs[SONIC_CRDA]) +
sizeof(uint16_t) * 6 * width,
-MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, sizeof(uint16_t), 1);
+MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, size, 1);
s->regs[SONIC_CRDA] = s->regs[SONIC_LLFA];
s->regs[SONIC_ISR] |= SONIC_ISR_PKTRX;
s->regs[SONIC_RSC] = (s->regs[SONIC_RSC] & 0xff00) |
(((s->regs[SONIC_RSC] & 0x00ff) + 1) & 0x00ff);
@@ -783,7 +784,7 @@ static ssize_t dp8393x_receive(NetClientState *nc, const
uint8_t * buf,
/* Done */
dp8393x_update_irq(s);
-return size;
+return rx_len;
}
static void dp8393x_reset(DeviceState *dev)
--
2.7.4
[Qemu-devel] [PATCH v2] ui/cocoa.m: fix sending mouse event to guest
The mouse down event should not be sent to the guest if the mouse down event
causes QEMU to move the foreground from the background. This patch prevents
these activation clicks from going to the guest.
Signed-off-by: John Arbuckle
---
v2 changes:
Fix a bug that caused fullscreen mode not to receive mouse events.
ui/cocoa.m | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 26d4a1c..ae3f5a1 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -695,13 +695,13 @@ QemuCocoaView *cocoaView;
if (mouse_event) {
/* Don't send button events to the guest unless we've got a
- * mouse grab or window focus. If we have neither then this event
- * is the user clicking on the background window to activate and
- * bring us to the front, which will be done by the sendEvent
- * call below. We definitely don't want to pass that click through
- * to the guest.
+ * mouse grab, window focus, or in fullscreen mode. If we have neither
+ * then this event is the user clicking on the background window to
+ * activate and bring us to the front, which will be done by the
+ * sendEvent call below. We definitely don't want to pass that click
+ * through to the guest.
*/
-if ((isMouseGrabbed || [[self window] isKeyWindow]) &&
+if (isMouseGrabbed && ([[self window] isKeyWindow] || isFullscreen) &&
(last_buttons != buttons)) {
static uint32_t bmap[INPUT_BUTTON__MAX] = {
[INPUT_BUTTON_LEFT] = MOUSE_EVENT_LBUTTON,
--
2.7.2
[Qemu-devel] Speed menu for GTK interfaace
Hello, I was wondering if you would accept a patch that added a Speed menu to the GTK interface. This would allow the user to change how much CPU time the emulated CPU would see.
[Qemu-devel] [Bug 925405] Re: VNC server does not work with Mac Screen Sharing
Hey there. Will git tip from September do? At that time I built QEMU on Ubuntu 16.04.1, pointed my Mac (10.10) at it again and had the same experience (had to use a third-party client) Considering I opened this four years ago, I'm kind of surprised it's still a talking topic. Was kind of expecting more people to report it, but then again Launchpad is a bit off the beaten path these days and most people just sigh and fetch a third party client. It's just that it seems like a trivial thing to fix overall, so I thought it worthwhile to chime in - Happy New Year! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/925405 Title: VNC server does not work with Mac Screen Sharing Status in QEMU: Incomplete Status in Ubuntu: Invalid Bug description: When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. Background info: Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: * At a terminal, by typing "open vnc://hostname:tcp_port" * From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925405/+subscriptions
[Qemu-devel] [Bug 1653419] [NEW] SVM emulation fails due to EIP and FLAG register update optimization
Public bug reported: SVM emulation support has a bug due to which causes KVM emulation error when qemu-kvm is run over KVM installed on top of QEmu in software mode. Steps to reproduce 1. Run KVM inside QEmu(software mode with SVM emulation support). Make sure kvm_amd is running. 2. Run any guest OS on top of the KVM using qemu-kvm. 3. Following KVM emulation error is thrown immediately. KVM internal error. Suberror: 1 emulation failure EAX= EBX=404b ECX= EDX=000f5ea0 ESI= EDI= EBP= ESP=6fd0 EIP=4000 EFL=0086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f7180 0037 IDT= 000f71be CR0=0011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Reason for the error Due to performance reasons, EIP and FLAG registers are not updated after executing every guest instructions. There are optimizations done to update these registers intelligently, for eg: EIP is updated at the end of translation block. This means EIP remains the address of the first instruction in the TB throughout the execution. In case of a VMEXIT because of a page fault happened after executing an instruction in the middle of the TB, the VMCB is updated with the wrong guest EIP and jumps to the address where host has left off. On the subsequent VMRUN by the host QEmu start executing some of the instructions that has already been executed. This can cause wrong execution flow. Following is the instruction execution trace of the above scenario. 0x000f368f: callq 0xeecc4 vmexit(0060, , , 000eecc4)! vmsave! b72e9000 vmload! b72e9000 vmrun! b72e9000 0x000eecc4: push %rbx 0x000eecc5: xor %ecx,%ecx 0x000eecc7: mov (%rax,%rcx,1),%bl 0x000eecca: cmp (%rdx,%rcx,1),%bl vmexit(004e, , 000f5ea0, 000eecc4)! Page fault happens at 0x000eecca which triggers a VMEXIT. vmcb->save->rip is updated with 0x000eecc4 instead of 0x000eecca. vmsave! b72e9000 vmload! b72e9000 vmrun! b72e9000 0x000eecc4: push %rbx 0x000eecc5: xor %ecx,%ecx 0x000eecc7: mov (%rax,%rcx,1),%bl 0x000eecca: cmp (%rdx,%rcx,1),%bl 0x000eeccd: je 0xeecdc 0x000eeccf: setl %al 0x000eecd2: movzbl %al,%eax 0x000eecd5: neg %eax 0x000eecd7: or $0x1,%eax 0x000eecda: jmp 0xeece3 0x000eece3: pop %rbx 0x000eece4: retq vmexit(004e, , 4000, 4000)! The subsequent VMRUN again starts executing from 0x000eecc4 which causes %rbx being pushed to the stack for the second time. The retq instruction picks wrong return address and jumps to an illegal location. Similar issue is there with updating FLAG register as well. ** Affects: qemu Importance: Undecided Status: New ** Tags: svm -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1653419 Title: SVM emulation fails due to EIP and FLAG register update optimization Status in QEMU: New Bug description: SVM emulation support has a bug due to which causes KVM emulation error when qemu-kvm is run over KVM installed on top of QEmu in software mode. Steps to reproduce 1. Run KVM inside QEmu(software mode with SVM emulation support). Make sure kvm_amd is running. 2. Run any guest OS on top of the KVM using qemu-kvm. 3. Following KVM emulation error is thrown immediately. KVM internal error. Suberror: 1 emulation failure EAX= EBX=404b ECX= EDX=000f5ea0 ESI= EDI= EBP= ESP=6fd0 EIP=4000 EFL=0086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=
[Qemu-devel] [kvm-unit-tests PATCH 2/2] run_tests: allow run tests in parallel
run_task.sh is getting slow. This patch is trying to make it faster by
running the tests concurrently.
First of all, we provide a new parameter "-j" for the run_tests.sh,
which can be used to specify how many run queues we want for the tests.
When "-j" is not provided, we'll keep the old behavior.
When the tests are running concurrently, we will use seperate log file
for each test case (currently located in logs/ dir, with name
test.TESTNAME.log), to avoid test logs messing up with each other.
A quick test on my laptop (x86 with 4 cores and 2 threads, so 8
processors) shows 3x improvement on overall test time:
|-+---|
| command | time used |
|-+---|
| run_test.sh | 75s |
| run_test.sh -j8 | 27s |
|-+---|
Signed-off-by: Peter Xu
---
run_tests.sh| 19 +-
scripts/functions.bash | 20 ++-
scripts/global.bash | 13
scripts/mkstandalone.sh | 1 +
scripts/task.bash | 156
5 files changed, 205 insertions(+), 4 deletions(-)
create mode 100644 scripts/task.bash
diff --git a/run_tests.sh b/run_tests.sh
index a04bfce..8794aa0 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -8,16 +8,18 @@ if [ ! -f config.mak ]; then
fi
source config.mak
source scripts/global.bash
+source scripts/task.bash
source scripts/functions.bash
function usage()
{
cat < $ut_default_log_file
diff --git a/scripts/functions.bash b/scripts/functions.bash
index 90daed4..0da08e6 100644
--- a/scripts/functions.bash
+++ b/scripts/functions.bash
@@ -1,7 +1,18 @@
+source scripts/global.bash
+source scripts/task.bash
+
function run_task()
{
- RUNTIME_log_file=$ut_default_log_file
- "$@"
+ local testname="$2"
+
+ if ut_in_parallel; then
+ RUNTIME_log_file="${ut_log_dir}/test.${testname}.log"
+ # run in background
+ task_enqueue "$@"
+ else
+ RUNTIME_log_file=$ut_default_log_file
+ "$@"
+ fi
}
function for_each_unittest()
@@ -51,5 +62,10 @@ function for_each_unittest()
fi
done
run_task "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch"
"$check" "$accel" "$timeout"
+
+ if ut_in_parallel; then
+ task_wait_all
+ fi
+
exec {fd}<&-
}
diff --git a/scripts/global.bash b/scripts/global.bash
index 9076785..dfcf0fe 100644
--- a/scripts/global.bash
+++ b/scripts/global.bash
@@ -1 +1,14 @@
: ${ut_default_log_file:=test.log}
+: ${ut_log_dir:=logs}
+# how many run queues for the unit tests
+: ${ut_run_queues:=1}
+
+function ut_in_parallel()
+{
+[[ $ut_run_queues != 1 ]]
+}
+
+function is_number()
+{
+[[ "$1" =~ ^[0-9]+$ ]]
+}
diff --git a/scripts/mkstandalone.sh b/scripts/mkstandalone.sh
index d2bae19..b6c23c6 100755
--- a/scripts/mkstandalone.sh
+++ b/scripts/mkstandalone.sh
@@ -5,6 +5,7 @@ if [ ! -f config.mak ]; then
exit 1
fi
source config.mak
+source scripts/global.bash
source scripts/functions.bash
escape ()
diff --git a/scripts/task.bash b/scripts/task.bash
new file mode 100644
index 000..4b74e0e
--- /dev/null
+++ b/scripts/task.bash
@@ -0,0 +1,156 @@
+###
+#
+# This is a bash library to allow run multiple tasks in the
+# background.
+#
+# Exported interface:
+#
+# - task_enqueue: enqueue a command to run in the bg
+# - task_wait_all:wait until all the tasks are finished
+#
+# A sample test code:
+#
+# source task.bash
+# for i in $(seq 10); do
+# task_enqueue sleep $i
+# done
+# task_wait_all
+#
+# NOTE: SIGUSR1 is used to deliver task notifications.
+#
+# Author(s): Peter Xu
+#
+###
+
+task_debug=false# debug flag
+task_max_n=5# concurrent task number
+
+# stores the main process that sourced this library
+task_main_pid=$$
+task_cur_n=0
+
+declare -a task_pid_list
+
+task_set_queue_num()
+{
+task_max_n=$1
+}
+
+__task_print()
+{
+echo "$@" >&2
+}
+
+__task_debug()
+{
+if $task_debug; then
+__task_print "$@"
+fi
+}
+
+__task_sig_handler()
+{
+local i pid
+
+# wait for a short time to make sure the subprocess that has sent
+# this signal has totally quit. 200ms should be far enough in most
+# systems.
+sleep 0.2
+
+__task_debug "Detected child die"
+
+for (( i=0; i<$task_max_n; i++ )); do
+pid="${task_pid_list[$i]}"
+if [[ -z "$pid" ]]; then
+__task_debug " Task slot $i empty"
+continue;
+fi
+if ! kill -0 $pid &> /dev/null; then
+__task_debug " Child $pid died"
+task_pid_list[$i]=""
+else
+__task_debug " Child $pid still working"
+fi
+done
+}
+trap __task_sig_handler SIGUSR1
+
+__task_c
[Qemu-devel] [kvm-unit-tests PATCH 0/2] run_tests: support concurrent test execution
run_tests.sh is getting slower. Maybe it's time to let it run faster. An obvious issue is that, we were running the tests sequentially in the past. This series provides another new "-j" parameter. "-j 8" means we run the tests on 8 task queues. That'll fasten the script a lot. A very quick test of mine shows 3x speed boost with 8 task queues. Most of the changes are in scripts/tash.bash of patch 2, which implemented the main logic for task managements. Please see commit message for more information. I did a quick "make standalone" test to make sure this series won't break it. However I am not sure whether it'll break other thing that I don't know... Please kindly review, thanks. Peter Xu (2): run_tests: provide RUNTIME_log_file run_tests: allow run tests in parallel run_tests.sh| 30 +++--- scripts/functions.bash | 25 +++- scripts/global.bash | 14 + scripts/mkstandalone.sh | 1 + scripts/task.bash | 156 5 files changed, 217 insertions(+), 9 deletions(-) create mode 100644 scripts/global.bash create mode 100644 scripts/task.bash -- 2.7.4
[Qemu-devel] [Bug 925405] Re: VNC server does not work with Mac Screen Sharing
QEMU 2.0 is not maintained by the QEMU project anymore. Can you please try again with the latest release of QEMU (v2.8)? ... otherwise you should report this to the bug tracker of your distro instead. ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/925405 Title: VNC server does not work with Mac Screen Sharing Status in QEMU: Incomplete Status in Ubuntu: Invalid Bug description: When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. Background info: Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: * At a terminal, by typing "open vnc://hostname:tcp_port" * From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925405/+subscriptions
[Qemu-devel] [kvm-unit-tests PATCH 1/2] run_tests: provide RUNTIME_log_file
Prepare that we may use different log file for different tests in the
future (i.e., to run tests in parallel).
Added another new file (scripts/global.bash) to store future global vars
and function clips.
Signed-off-by: Peter Xu
---
run_tests.sh | 13 +++--
scripts/functions.bash | 9 +++--
scripts/global.bash| 1 +
3 files changed, 15 insertions(+), 8 deletions(-)
create mode 100644 scripts/global.bash
diff --git a/run_tests.sh b/run_tests.sh
index 254129d..a04bfce 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -7,6 +7,7 @@ if [ ! -f config.mak ]; then
exit 1
fi
source config.mak
+source scripts/global.bash
source scripts/functions.bash
function usage()
@@ -46,17 +47,17 @@ while getopts "g:hv" opt; do
esac
done
-RUNTIME_log_stderr () { cat >> test.log; }
+# RUNTIME_log_file will be configured later
+RUNTIME_log_stderr () { cat >> $RUNTIME_log_file; }
RUNTIME_log_stdout () {
if [ "$PRETTY_PRINT_STACKS" = "yes" ]; then
-./scripts/pretty_print_stacks.py $1 >> test.log
+./scripts/pretty_print_stacks.py $1 >> $RUNTIME_log_file
else
-cat >> test.log
+cat >> $RUNTIME_log_file
fi
}
-
config=$TEST_DIR/unittests.cfg
-rm -f test.log
-printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
+rm -f $ut_default_log_file
+printf "BUILD_HEAD=$(cat build-head)\n\n" > $ut_default_log_file
for_each_unittest $config run
diff --git a/scripts/functions.bash b/scripts/functions.bash
index ee9143c..90daed4 100644
--- a/scripts/functions.bash
+++ b/scripts/functions.bash
@@ -1,3 +1,8 @@
+function run_task()
+{
+ RUNTIME_log_file=$ut_default_log_file
+ "$@"
+}
function for_each_unittest()
{
@@ -17,7 +22,7 @@ function for_each_unittest()
while read -u $fd line; do
if [[ "$line" =~ ^\[(.*)\]$ ]]; then
- "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts"
"$arch" "$check" "$accel" "$timeout"
+ run_task "$cmd" "$testname" "$groups" "$smp" "$kernel"
"$opts" "$arch" "$check" "$accel" "$timeout"
testname=${BASH_REMATCH[1]}
smp=1
kernel=""
@@ -45,6 +50,6 @@ function for_each_unittest()
timeout=${BASH_REMATCH[1]}
fi
done
- "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check"
"$accel" "$timeout"
+ run_task "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch"
"$check" "$accel" "$timeout"
exec {fd}<&-
}
diff --git a/scripts/global.bash b/scripts/global.bash
new file mode 100644
index 000..9076785
--- /dev/null
+++ b/scripts/global.bash
@@ -0,0 +1 @@
+: ${ut_default_log_file:=test.log}
--
2.7.4
[Qemu-devel] [PATCH] ui/gtk: fix crash at startup when no console is available
This patch fixes a segfault at QEMU startup, introduced in
a08156321ab9a7d2fed9ee77dbfeea2a61ffd153.
gd_vc_find_current() return NULL, which is dereferenced without checking it.
While at it, disable the whole 'View' menu if no console exists.
Reproducer: qemu-system-i386 -M none -nodefaults
Signed-off-by: Hervé Poussineau
---
ui/gtk.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index a216216..406de4f 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -2171,6 +2171,8 @@ static gboolean gtkinit;
void gtk_display_init(DisplayState *ds, bool full_screen, bool grab_on_hover)
{
+VirtualConsole *vc;
+
GtkDisplayState *s = g_malloc0(sizeof(*s));
char *filename;
GdkDisplay *window_display;
@@ -2249,9 +2251,11 @@ void gtk_display_init(DisplayState *ds, bool
full_screen, bool grab_on_hover)
}
#endif
+vc = gd_vc_find_current(s);
+gtk_widget_set_sensitive(s->view_menu, vc != NULL);
#ifdef CONFIG_VTE
gtk_widget_set_sensitive(s->copy_item,
- gd_vc_find_current(s)->type == GD_VC_VTE);
+ vc && vc->type == GD_VC_VTE);
#endif
if (full_screen) {
--
2.1.4
