Bug 1145028

Created attachment 939925 [details]
RHEL7 debug log

Created attachment 939926 [details]
RHEL6 sendkey debug log

What does "crash" mean in this context? Did virsh stop working? Did Windows get a blue screen? Did QEMU crash?

You said you tried with RHEL6, what are the QEMU and libvirt versions?

Have you tried to reproduce running QEMU directly (ie. w/o libvirt)?

PS: Yes, I've noticed libvirt has a fd=-1 for the monitor, which could be the cause. But you this report doesn't contain enough information to determine what the problem is.

(In reply to Luiz Capitulino from comment #6)
Just from a libvirt's POV, that fd=-1 doesn't mean anything to qemu.

(In reply to Luiz Capitulino from comment #6)
> What does "crash" mean in this context? Did virsh stop working? Did Windows
> get a blue screen? Did QEMU crash?
> 
> You said you tried with RHEL6, what are the QEMU and libvirt versions?
> 
> Have you tried to reproduce running QEMU directly (ie. w/o libvirt)?
> 
> PS: Yes, I've noticed libvirt has a fd=-1 for the monitor, which could be
> the cause. But you this report doesn't contain enough information to
> determine what the problem is.

1.The "crash" mean Windows get a blue screen  

2.the RHEL6 version which i tried:
qemu-kvm-rhev-0.12.1.2-2.446
libvirt-0.10.2-46.el6

Also i have tried to use virsh qemu-monitor-command r6 --hmp "sendkey 0x9D-0x46-0x46" to crash the guest(windows get a blue screen) in RHEL7 ,but it didn't work.

3.Sorry,I haven't tried that and i will try to use QEMU monitor command tmr.


Thanks,
Luyao Huang

OK, so I guess there are two possible reasons: it's either a bug in Windows itself or an emulation problem in QEMU/KVM.

Yan, can you debug this bug please? If it turns out to be something outside the scope of your work, you can re-assign it back to me. But I need help to at least debug this down.

I think there was a huge misunderstanding here.  What Luyao is trying to say is that when you have the right setting in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters, Windows *are supposed* to crash when you press Ctrl+(2*ScrollLock).  That is a "feature" there.  And what he tried is that he did that on RHEL6 and BSOD appeared as was expected, but on RHEL7 it *didn't* crash and that is the problem.

Libvirt switched from HMP to QMP between RHEL6 and RHEL7 because of newer qemu.  I hope those commands behave the same way.  The only thing that may cause the problem is that, for example, the hmp command does something like:

hold down Control
press ScrollLock
press ScrollLock

whether the qmp one does:

press Control
press ScrollLock
press ScrollLock

Should this bug stay assigned to Yan or be assigned back to you after the explanation in comment #10 ?

Thanks for your explanation. I really got it completely wrong.

When you mention this difference between HMP and QMP, where HMP "holds down Control" while QMP just presses it, does it happen in libvirt or QEMU? How do you know QEMU does it?

I'm going to re-assign this BZ to Amos, as he re-wrote the send-key command for newer QMP.

(In reply to Luiz Capitulino from comment #13)
I don't know whether that's the problem, that's just my guess.  But if that's the case it's in QEMU.

Actually there are two problem here.

1) I sensitively identified the first issue when I saw comment #1, the qcodes of last keys are same. I touched this issue in the past.

2) In verifying my thought, I found a regression [1], so I filed a new bug.

I will post patch to fix those two issues.

[1] Bug 1146801 - sendkey: releasing order of combined keys was wrongly converse

As discussed in http://marc.info/?l=qemu-devel&m=141456679226178&w=2, my patch isn't accepted by upstream, they prefer to use Marcelo's new QMP command to emit the event, then we can hold on Ctrl key.

Marcelo's patch v4: https://patchwork.ozlabs.org/patch/395116/

Marcelo's patch was applied by upstream, then we can crash Windows by:

1. hold on right ctrl
{ "execute": "input-send-event", "arguments": { "console": 0, "events": [ { "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "ctrl_r" } } }] } }

2. press the SCROLL LOCK key twice
{ "execute": "send-key", "arguments": { "keys": [{"type": "qcode", "data": "scroll_lock"} ] } }

{ "execute": "send-key", "arguments": { "keys": [{"type": "qcode", "data": "scroll_lock"} ] } }

3. release right ctrl

{ "execute": "input-send-event", "arguments": { "console": 0, "events": [ { "type": "key", "data" : { "down": false, "key": {"type": "qcode", "data": "ctrl_r" } } } ] } }

Fix included in qemu-kvm-rhev-2.1.2-6.el7

During upstream review of a documentation patch triggered by downstream review, doubts on the API came up.  Upstream marked the command experimental by prefixing it with x- for the 2.2 release, to give us time to get it right.  We want to wait for the dust to settle upstream, so punt to 7.2.

Status of this bug:

need to backport patch :

[RHEL-7.1 qemu-kvm-rhev PATCH 2/2] add input-send-event command

Can QE reproduce this on recent qemu-kvm-rhev?

(In reply to jason wang from comment #36)
> Can QE reproduce this on recent qemu-kvm-rhev?

No, i cannot reproduce this problem with steps in comment 0

(In reply to Luyao Huang from comment #37)
> (In reply to jason wang from comment #36)
> > Can QE reproduce this on recent qemu-kvm-rhev?
> 
> No, i cannot reproduce this problem with steps in comment 0

Closed according to this.