From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: R/W HG memory mappings with kvm? Date: Wed, 08 Jul 2009 07:36:47 +0300 Message-ID: <4A54225F.1050703@redhat.com> References: <5f370d430907051541o752d3dbag80d5cb251e5e4d00@mail.gmail.com> <4A51A9F0.7000909@redhat.com> <5f370d430907071523t120da246wf366dbfbbac9169b@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]:59940 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751033AbZGHEgg (ORCPT ); Wed, 8 Jul 2009 00:36:36 -0400 In-Reply-To: <5f370d430907071523t120da246wf366dbfbbac9169b@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/08/2009 01:23 AM, Stephen Donnelly wrote: > >>> Also it appears that PCI IO memory (cpu_register_io_memory) is >>> provided via access functions, like the pci config space? >>> >> It can also use ordinary RAM (for example, vga maps its framebuffer as a PCI >> BAR). >> > > So host memory is exported as a PCI_BAR to the guest via > cpu_register_physical_memory(). It looks like the code has to > explicitly manage marking pages dirty and synchronising at appropriate > times. Is the coherency problem bidirectional, e.g. writes from either > host or guest to the shared memory need to mark pages dirty, and > ensure sync is called before the other side reads those areas? > 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. >>> Does this >>> cause a page fault/vm_exit on each read or write, or is it more >>> efficient than that? >>> >> It depends on how you configure it. Look at the vga code (hw/vga.c, >> hw/cirrus_vga.c). Also Cam (copied) wrote a PCI card that provides shared >> memory across guests, you may want to look at that. >> > > I will look into the vga code and see if I get inspired. The 'copied' > driver sounds interesting, the code is not in kvm git? > (copied) means Cam was copied (cc'ed) on the email, not the name of the driver. It hasn't been merged but copies (of the driver, not Cam) are floating around on the Internet. The relevant parts of cirrus_vga.c are: 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. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.