From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35061 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OCe0Q-0001zW-1v
	for qemu-devel@nongnu.org; Thu, 13 May 2010 15:23:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <jamie@shareable.org>) id 1OCe0M-00036v-DQ
	for qemu-devel@nongnu.org; Thu, 13 May 2010 15:23:38 -0400
Received: from mail2.shareable.org ([80.68.89.115]:38888)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <jamie@shareable.org>) id 1OCe0M-00035z-89
	for qemu-devel@nongnu.org; Thu, 13 May 2010 15:23:34 -0400
Date: Thu, 13 May 2010 20:23:24 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 2/4] Add support for execution from ROMs in
	IO device mode
Message-ID: <20100513192324.GA9388@shareable.org>
References: <cover.1273760202.git.jan.kiszka@web.de>
	<5b7efeb30fe6f93a369b6a9f964a2cb7c0519222.1273760202.git.jan.kiszka@web.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5b7efeb30fe6f93a369b6a9f964a2cb7c0519222.1273760202.git.jan.kiszka@web.de>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Michael Walle <michael@walle.cc>, qemu-devel@nongnu.org

Jan Kiszka wrote:
> While IO_MEM_ROMD marks an I/O memory region as "read/execute from RAM,
> but write to I/O handler", there is no flag indicating that an I/O
> region which is fully managed by I/O handlers can still be hosting
> executable code. One use case for this are flash device models that
> switch to I/O mode during reprogramming. Not all reprogramming states
> modify to read data, thus practically allow to continue execution.
> Moreover, we need to avoid switching the modes too frequently for
> performance reasons which requires fetching opcodes while still in I/O
> device mode.

I like this change.

Does "fetching opcodes while still in I/O device mode" fetch opcodes
from the RAM backing, or via the I/O read handlers?

If the latter, I'm wondering how KVM would cope with that.

Thanks,
-- Jamie