From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkuxP-0004ou-Ig for qemu-devel@nongnu.org; Tue, 18 Dec 2012 06:03:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkuxN-0005Ze-W4 for qemu-devel@nongnu.org; Tue, 18 Dec 2012 06:03:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkuxN-0005ZO-OZ for qemu-devel@nongnu.org; Tue, 18 Dec 2012 06:03:29 -0500 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 qBIB3RF5023107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Dec 2012 06:03:28 -0500 Message-ID: <50D04D7D.3000404@redhat.com> Date: Tue, 18 Dec 2012 12:03:25 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1355492147-5023-1-git-send-email-hdegoede@redhat.com> <1355492147-5023-10-git-send-email-hdegoede@redhat.com> <50CF1B33.7060708@redhat.com> <50CF2AFB.2050705@redhat.com> <50CF2EB3.9020501@redhat.com> <50CF308C.70204@redhat.com> <50CF3167.7080707@redhat.com> <50D0437B.80106@redhat.com> In-Reply-To: <50D0437B.80106@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 09/26] ehci: Use uframe precision for interrupt threshold checking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel@nongnu.org Hi, > Can qemu not handle an mmio range where writes are trapped, but reads are > not? That would force the use of the shadow variable, but should otherwise > provide a nice speedup. No. vmexit is needed anyway btw, but the round-trip to qemu userspace could be short-cutted in theory. It's non-trivial though. Alex had a talk about it at kvm forum (covering ide). First a simple read directly + write via qemu isn't that useful. You need a policy per register. For most reads it would work, but there are exceptions. Registers holding timers for example. frindex is actually an example of that. With async_stepdown active frindex updates are quite jumpy. We might want to update the register on guest reads (and maybe also reset async stepdown in that case). Likewise the other way around: Not all register writes have some effect which qemu must emulate, some are just storage (like ehci frame list address). Locking is an unsolved issue (in-kernel register reads/writes don't grab the qemu lock and thus would race with iothread accessing the register variables). cheers, Gerd