1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
virtual: 0.431
debug: 0.366
register: 0.178
x86: 0.170
vnc: 0.116
operating system: 0.087
hypervisor: 0.084
files: 0.082
PID: 0.068
TCG: 0.058
i386: 0.053
network: 0.041
user-level: 0.040
performance: 0.039
kernel: 0.038
semantic: 0.031
socket: 0.027
alpha: 0.027
ppc: 0.026
device: 0.018
boot: 0.017
permissions: 0.007
assembly: 0.006
arm: 0.006
peripherals: 0.004
risc-v: 0.004
VMM: 0.004
graphic: 0.003
architecture: 0.003
KVM: 0.002
mistranslation: 0.002
[Qemu-devel] Can I have someone's feedback on [bug 1809075] Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel
Hi everyone.
Can I please have someone's feedback on this bug?
https://bugs.launchpad.net/qemu/+bug/1809075
Briefly, guest OS loses characters sent to it via vnc. And I spot the
bug in relation to ps2 driver.
I'm thinking of possible fixes and I might want to use a memory barrier.
But I would really like to have some suggestion from a qemu developer
first. For example, can we brutally drop capslock LED key events in ps2
queue?
It is actually relevant to openQA, an automated QA tool for openSUSE.
And this bug blocks a few test cases for us.
Thank you in advance!
Kind regards,
Gao Zhiyuan
Cc'ing Marc-André & Gerd.
On 12/19/18 10:31 AM, Gao Zhiyuan wrote:
>
Hi everyone.
>
>
Can I please have someone's feedback on this bug?
>
https://bugs.launchpad.net/qemu/+bug/1809075
>
Briefly, guest OS loses characters sent to it via vnc. And I spot the
>
bug in relation to ps2 driver.
>
>
I'm thinking of possible fixes and I might want to use a memory barrier.
>
But I would really like to have some suggestion from a qemu developer
>
first. For example, can we brutally drop capslock LED key events in ps2
>
queue?
>
>
It is actually relevant to openQA, an automated QA tool for openSUSE.
>
And this bug blocks a few test cases for us.
>
>
Thank you in advance!
>
>
Kind regards,
>
Gao Zhiyuan
>
On Thu, Jan 03, 2019 at 12:05:54PM +0100, Philippe Mathieu-Daudé wrote:
>
Cc'ing Marc-André & Gerd.
>
>
On 12/19/18 10:31 AM, Gao Zhiyuan wrote:
>
> Hi everyone.
>
>
>
> Can I please have someone's feedback on this bug?
>
>
https://bugs.launchpad.net/qemu/+bug/1809075
>
> Briefly, guest OS loses characters sent to it via vnc. And I spot the
>
> bug in relation to ps2 driver.
>
>
>
> I'm thinking of possible fixes and I might want to use a memory barrier.
>
> But I would really like to have some suggestion from a qemu developer
>
> first. For example, can we brutally drop capslock LED key events in ps2
>
> queue?
There is no "capslock LED key event". 0xfa is KBD_REPLY_ACK, and the
device queues it in response to guest port writes. Yes, the ack can
race with actual key events. But IMO that isn't a bug in qemu.
Probably the linux kernel just throws away everything until it got the
ack for the port write, and that way the key event gets lost. On
physical hardware you will not notice because it is next to impossible
to type fast enough to hit the race window.
So, go fix the kernel.
Alternatively fix vncdotool to send uppercase letters properly with
shift key pressed. Then qemu wouldn't generate capslock key events
(that happens because qemu thinks guest and host capslock state is out
of sync) and the guests's capslock led update request wouldn't get into
the way.
cheers,
Gerd
|