From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: R/W HG memory mappings with kvm? Date: Thu, 09 Jul 2009 11:10:17 +0300 Message-ID: <4A55A5E9.6030108@redhat.com> References: <5f370d430907051541o752d3dbag80d5cb251e5e4d00@mail.gmail.com> <4A51A9F0.7000909@redhat.com> <5f370d430907071523t120da246wf366dbfbbac9169b@mail.gmail.com> <4A54225F.1050703@redhat.com> <5f370d430907081433x6e96a419m661e4d4da626238b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Stephen Donnelly Return-path: Received: from mx2.redhat.com ([66.187.237.31]:59433 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757843AbZGIIHp (ORCPT ); Thu, 9 Jul 2009 04:07:45 -0400 In-Reply-To: <5f370d430907081433x6e96a419m661e4d4da626238b@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/09/2009 12:33 AM, Stephen Donnelly wrote: >> Shared memory is fully coherent. You can use the ordinary x86 bus lock >> operations for concurrent read-modify-write access, and the memory barrier >> instructions to prevent reordering. Just like ordinary shared memory. >> > > Okay, I think I was confused by the 'dirty' code. Is that just to do > with migration? > Migration and reducing vga updates. >> static void cirrus_pci_lfb_map(PCIDevice *d, int region_num, >> uint32_t addr, uint32_t size, int type) >> { >> >> ... >> >> /* XXX: add byte swapping apertures */ >> cpu_register_physical_memory(addr, s->vga.vram_size, >> s->cirrus_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? > Sorry, I quoted the wrong part. vga is complicated because some modes do need callbacks on reads and writes, and others can use normal RAM (with dirty tracking). The real direct mapping code is: static void map_linear_vram(CirrusVGAState *s) { vga_dirty_log_stop(&s->vga); if (!s->vga.map_addr && s->vga.lfb_addr && s->vga.lfb_end) { s->vga.map_addr = s->vga.lfb_addr; s->vga.map_end = s->vga.lfb_end; cpu_register_physical_memory(s->vga.map_addr, s->vga.map_end - s->vga.map_addr, s->vga.vram_offset); } s->vga.vram_offset is a ram_addr_t describing the the vga framebuffer. You're much better off reading Cam's code as it's much simpler and closer to what you want to do (possibly you can use it as is). -- error compiling committee.c: too many arguments to function