From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TORwZ-0008FP-7X for qemu-devel@nongnu.org; Wed, 17 Oct 2012 07:37:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TORwS-0000B8-Ol for qemu-devel@nongnu.org; Wed, 17 Oct 2012 07:37:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TORwS-0000B4-GX for qemu-devel@nongnu.org; Wed, 17 Oct 2012 07:37:40 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9HBbdLQ030241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Oct 2012 07:37:39 -0400 Message-ID: <507E9881.2090809@redhat.com> Date: Wed, 17 Oct 2012 13:37:37 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1350297511-25437-1-git-send-email-hdegoede@redhat.com> <1350297511-25437-7-git-send-email-hdegoede@redhat.com> <507BF0C6.9010300@redhat.com> <507C08D1.9070607@redhat.com> <507E9014.7010507@redhat.com> <507E9249.3080404@redhat.com> In-Reply-To: <507E9249.3080404@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 06/22] ehci: Speed up the timer of raising int from the async schedule List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel@nongnu.org Hi, > 1) It causes migration issues when migrating to / from an old version With -1 yes, shifting the scale shoudn't be a that big issue though as it is just a optimization. > 2) We don't want to change the wakeup rate when the interrupt flag gets set > as pending, but when it actually gets committed, and we only want to change > the wakeup rate when the int was requested by an async packet, not when it > was requested by a periodic packet, so we will need the int_req_by_async > flag anyways, as which point this seemed the cleanest way. Missed that little details, ok then. cheers, Gerd