From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cam Macdonell Subject: Re: R/W HG memory mappings with kvm? Date: Mon, 27 Jul 2009 08:48:52 -0600 Message-ID: <4A6DBE54.3080609@cs.ualberta.ca> References: <5f370d430907051541o752d3dbag80d5cb251e5e4d00@mail.gmail.com> <4A51A9F0.7000909@redhat.com> <5f370d430907071523t120da246wf366dbfbbac9169b@mail.gmail.com> <4A54225F.1050703@redhat.com> <4A551387.3000702@cs.ualberta.ca> <5f370d430907081501m60064c7dp23ebd4153c9050f1@mail.gmail.com> <5f370d430907262256rd7f9fdalfbbec1f9492ce86@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "kvm@vger.kernel.org list" To: Stephen Donnelly Return-path: Received: from fleet.cs.ualberta.ca ([129.128.22.22]:60400 "EHLO fleet.cs.ualberta.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751137AbZG0Os5 (ORCPT ); Mon, 27 Jul 2009 10:48:57 -0400 In-Reply-To: <5f370d430907262256rd7f9fdalfbbec1f9492ce86@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: Stephen Donnelly wrote: > Hi Cam, Hi Steve, Sorry I haven't answered your email from last Thursday. I'll answer it shortly. > > On Thu, Jul 9, 2009 at 6:01 PM, Cam Macdonell wrote: > >> The memory for the device allocated as a POSIX shared memory object and then >> mmapped on to the allocated BAR region in Qemu's allocated memory. That's >> actually one spot that needs a bit of fixing by passing the already >> allocated memory object to qemu instead of mmapping on to it. > > If you work out how to use pre-existing host memory rather than > allocating it inside qemu I would be interested. How is the host memory pre-existing? > > I would like to have qemu mmap memory from a host char driver, and > then in turn register that mapping as a PCI BAR for the guest device. > (I know this sounds like pci pass-through, but it isn't.) In my setup, qemu just calls mmap on the shared memory object that was opened. So I *think* that switching the shm_open(...) to open("/dev/chardev"), might be all that's necessary as long as your char device handles mmapping. > What I don't understand is how to turn the host address returned from > mmap into a ram_addr_t to pass to pci_register_bar. Memory must be allocated using the qemu RAM functions. Look at qemu_ram_alloc() and qemu_get_ram_ptr() which are a two step process that allocate the memory. Then notice that the ivshmem_ptr is mmapped on to the memory that is returned from the qemu_get_ram_ptr. pci_register_bar calls a function (the last parameter passed to it) that in turn calls cpu_register_physical_memory which registers the allocated memory (accessed a s->ivshmem_ptr) as the BAR. Let me know if you have any more questions, Cam