qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gonglei <arei.gonglei@huawei.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kraxel@redhat.com" <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Break cross migration from qemu-1.5 to qemu-2.1. because of input/hid rewriting
Date: Mon, 24 Nov 2014 17:10:19 +0800	[thread overview]
Message-ID: <5472F5FB.1080305@huawei.com> (raw)
In-Reply-To: <5472F577.6030700@huawei.com>

On 2014/11/24 17:08, Gonglei wrote:

> On 2014/11/21 23:16, Dr. David Alan Gilbert wrote:
> 
>> * Gonglei (arei.gonglei@huawei.com) wrote:
>>>> Hi, Gerd
>>>>
>>>> I encounter a problem that breaking  migration from qemu-1.5 to qemu-2.1.
>>>> The error message as below:
>>>>  qemu-system-x86_64: hw/input/hid.c:121: hid_pointer_event: Assertion `hs->n < 16' failed.
>>>> Qemu assert in hid_pointer_event().
>> What is your test to reproduce this?
>>
>> Dave
>>
> 
> That's very easy.
> 
> a) Add some log in hid.c:
> 
> diff --git a/hw/input/hid.c b/hw/input/hid.c
> index 148c003..6908680 100644
> --- a/hw/input/hid.c
> +++ b/hw/input/hid.c
> @@ -161,12 +161,13 @@ static void hid_pointer_sync(DeviceState *dev)
>      HIDState *hs = (HIDState *)dev;
>      HIDPointerEvent *prev, *curr, *next;
>      bool event_compression = false;
> -
> +    printf("hs->n = %d\n", hs->n);
>      if (hs->n == QUEUE_LENGTH-1) {
>          /*
>           * Queue full.  We are losing information, but we at least
>           * keep track of most recent button state.
>           */
> +        printf("Queue full....\n");
>          return;
>      }
> 
> b) Reproduce Steps:
> 1. An image without graphic mode. You can set "runlevel = 3"
> 2. Booting Guest with below Qemu cmdline:
>  # ./qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -name redhat6.2 -drive file=/home/redhat_6.4_64 -device piix3-usb-uhci,id=uhci -device usb-tablet,bus=uhci.0,id=tablet.0 -vnc :10
> 3. Click, meanwhile move mouse ceaselessly.
> 
> c) Get result:
> hs->n = 0
> hs->n = 1
> hs->n = 1
> hs->n = 1
> hs->n = 1
> hs->n = 1
> hs->n = 2
> hs->n = 3
> hs->n = 4
> hs->n = 5
> hs->n = 6
> hs->n = 7
> hs->n = 8
> hs->n = 9
> hs->n = 10
> hs->n = 11
> hs->n = 12
> hs->n = 13
> hs->n = 14
> hs->n = 15
> Queue full....
> hs->n = 15
> Queue full....
> hs->n = 15
> Queue full....
> hs->n = 15
> Queue full....
> hs->n = 15
> Queue full....
> 
> We can see the Queue is full and will decrease, that's say hid_pointer_poll() will not be called.

Sorry, a typo. :(    s/will decrease/will not decrease/

> Normally, hid_pointer_poll() is called by below backstrace:
> 
> Breakpoint 1, hid_pointer_poll (hs=0x55555649d578, buf=0x55555649bf9c "\005\001\t\001\241\001\t\001\241", len=6)
>     at hw/input/hid.c:322
> 322     {
> (gdb) bt
> #0  hid_pointer_poll (hs=0x55555649d578, buf=0x55555649bf9c "\005\001\t\001\241\001\t\001\241", len=6) at hw/input/hid.c:322
> #1  0x00005555558c3b92 in usb_hid_handle_control (dev=0x55555649bec0, p=0x5555563f4410, request=41217, value=256, index=0, length=
>     6, data=0x55555649bf9c "\005\001\t\001\241\001\t\001\241") at hw/usb/dev-hid.c:609
> #2  0x00005555558a2999 in usb_device_handle_control (dev=0x55555649bec0, p=0x5555563f4410, request=41217, value=256, index=0,
>     length=6, data=0x55555649bf9c "\005\001\t\001\241\001\t\001\241") at hw/usb/bus.c:171
> #3  0x000055555589f42d in do_token_setup (s=0x55555649bec0, p=0x5555563f4410) at hw/usb/core.c:140
> #4  0x000055555589fe8a in usb_process_one (p=0x5555563f4410) at hw/usb/core.c:383
> #5  0x00005555558a00c7 in usb_handle_packet (dev=0x55555649bec0, p=0x5555563f4410) at hw/usb/core.c:428
> #6  0x00005555558a9ac0 in uhci_handle_td (s=0x5555563fdf20, q=0x55555649f240, qh_addr=931145090, td=0x7fffffffd8a0, td_addr=
>     931140928, int_mask=0x7fffffffd8cc) at hw/usb/hcd-uhci.c:867
> #7  0x00005555558aa1e5 in uhci_process_frame (s=0x5555563fdf20) at hw/usb/hcd-uhci.c:1054
> #8  0x00005555558aa826 in uhci_frame_timer (opaque=0x5555563fdf20) at hw/usb/hcd-uhci.c:1153
> #9  0x000055555594ed57 in timerlist_run_timers (timer_list=0x555556346650) at qemu-timer.c:491
> #10 0x000055555594edbf in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at qemu-timer.c:502
> #11 0x000055555594f2b7 in qemu_clock_run_all_timers () at qemu-timer.c:608
> #12 0x000055555594d604 in main_loop_wait (nonblocking=0) at main-loop.c:500
> #13 0x0000555555756b67 in main_loop () at vl.c:1882
> #14 0x000055555575e40e in main (argc=16, argv=0x7fffffffe0e8, envp=0x7fffffffe170) at vl.c:4400
> 
> But when Guest in non-graphic mode. the UHCI timer will be deleted because:
>     if (!(s->cmd & UHCI_CMD_RS)) {
>         /* Full stop */
>         trace_usb_uhci_schedule_stop();
>         timer_del(s->frame_timer);
>         uhci_async_cancel_all(s);
>         /* set hchalted bit in status - UHCI11D 2.1.2 */
>         s->status |= UHCI_STS_HCHALTED;
>         return;
>     }
> 
> ...and don't call  uhci_process_frame().
> 
> So, if somebody start VM with Qemu-1.5 and do above operations, then hs->n will arrive to 16 quickly,
> migrate the VM to Qemu-2.1 or later version, The Qemu assert inevitably.
> I think this problem is a big potential bug, caused by cross-version migration.
> 
> Gerd, what's your opinion? Thanks.
> 
> Best regards,
> -Gonglei

      reply	other threads:[~2014-11-24  9:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-20 13:03 [Qemu-devel] [RFC] Break cross migration from qemu-1.5 to qemu-2.1. because of input/hid rewriting Gonglei
2014-11-21  8:06 ` Gerd Hoffmann
2014-11-21  8:44   ` Gonglei
2014-11-21 15:16 ` Dr. David Alan Gilbert
2014-11-24  9:08   ` Gonglei
2014-11-24  9:10     ` Gonglei [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5472F5FB.1080305@huawei.com \
    --to=arei.gonglei@huawei.com \
    --cc=dgilbert@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).