From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Donnelly <sfdonnelly@gmail.com>
Subject: Re: R/W HG memory mappings with kvm?
Date: Thu, 9 Jul 2009 09:33:05 +1200
Message-ID: <5f370d430907081433x6e96a419m661e4d4da626238b@mail.gmail.com>
References: <5f370d430907051541o752d3dbag80d5cb251e5e4d00@mail.gmail.com>
	 <4A51A9F0.7000909@redhat.com>
	 <5f370d430907071523t120da246wf366dbfbbac9169b@mail.gmail.com>
	 <4A54225F.1050703@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: kvm@vger.kernel.org
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-gx0-f226.google.com ([209.85.217.226]:40612 "EHLO
	mail-gx0-f226.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754867AbZGHVdJ convert rfc822-to-8bit (ORCPT
	<rfc822;kvm@vger.kernel.org>); Wed, 8 Jul 2009 17:33:09 -0400
Received: by gxk26 with SMTP id 26so3658675gxk.13
        for <kvm@vger.kernel.org>; Wed, 08 Jul 2009 14:33:06 -0700 (PDT)
In-Reply-To: <4A54225F.1050703@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

> Shared memory is fully coherent. =A0You can use the ordinary x86 bus =
lock
> operations for concurrent read-modify-write access, and the memory ba=
rrier
> instructions to prevent reordering. =A0Just like ordinary shared memo=
ry.

Okay, I think I was confused by the 'dirty' code. Is that just to do
with migration?

> (copied) means Cam was copied (cc'ed) on the email, not the name of t=
he
> driver. =A0It hasn't been merged but copies (of the driver, not Cam) =
are
> floating around on the Internet.

Thanks, I'll ask him for a pointer.

> The relevant parts of cirrus_vga.c are:
>
> static void cirrus_pci_lfb_map(PCIDevice *d, int region_num,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t =
addr, uint32_t size, int type)
> {
>
> ...
>
> =A0 =A0/* XXX: add byte swapping apertures */
> =A0 =A0cpu_register_physical_memory(addr, s->vga.vram_size,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s->ci=
rrus_linear_io_addr);
>
> This function is called whenever the guest updates the BAR.

So guest accesses to the LFB PCI_BAR trigger the cirrus_linear
functions, which set dirty on writes and allow 'side effect' handling
for reads if required? In my case there should be no side effects, so
it could be quite simple. I wonder about the cost of the callbacks on
each access though, am I still missing something?

Thank you for your patience, I really appreciate the assistance and
look forward to using kvm more widely.

Stephen.