From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:60822)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QoHpH-0006Kx-MN
	for qemu-devel@nongnu.org; Tue, 02 Aug 2011 12:28:16 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QoHpG-0003Yn-98
	for qemu-devel@nongnu.org; Tue, 02 Aug 2011 12:28:15 -0400
Received: from mx1.redhat.com ([209.132.183.28]:16833)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QoHpG-0003Yg-0L
	for qemu-devel@nongnu.org; Tue, 02 Aug 2011 12:28:14 -0400
Message-ID: <4E382597.4020108@redhat.com>
Date: Tue, 02 Aug 2011 18:28:07 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1312135082-31985-1-git-send-email-avi@redhat.com>
	<1312135082-31985-21-git-send-email-avi@redhat.com>
	<20110801082600.GD5439@redhat.com> <4E367370.6070100@redhat.com>
	<20110801195343.GA16682@redhat.com> <4E37C092.8060108@redhat.com>
In-Reply-To: <4E37C092.8060108@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 20/39] virtio-pci: convert to memory API
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>

On 08/02/11 11:17, Avi Kivity wrote:
> On 08/01/2011 10:53 PM, Michael S. Tsirkin wrote:
>> >
>> >
>> > Just because a memory region becomes visible to the cpu is no reason
>> > to have a callback. From the device perspective, it can't tell that
>> > it happened.
>>
>> BTW this is what qxl does, too, conceptually: on config writes, it peeks
>> at the bar to detect whether that got unmapped.
>
> Can you elaborate? why? what does it do?

Nothing special, just keep track of the map state and toggle logging if 
needed, especially make sure to (re-)enable logging after the guest 
mapped the bar somewhere.

I'm pretty sure this can be killed during the conversion as the new 
memory slot manager will care about this so qxl doesn't has to.

cheers,
   Gerd