From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Donnelly Subject: Re: R/W HG memory mappings with kvm? Date: Tue, 28 Jul 2009 09:32:52 +1200 Message-ID: <5f370d430907271432y5283c2cat7673efeed0febe20@mail.gmail.com> 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> <4A6DBE54.3080609@cs.ualberta.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , "kvm@vger.kernel.org list" To: Cam Macdonell Return-path: Received: from qw-out-2122.google.com ([74.125.92.25]:64143 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753474AbZG0Vcw convert rfc822-to-8bit (ORCPT ); Mon, 27 Jul 2009 17:32:52 -0400 Received: by qw-out-2122.google.com with SMTP id 8so1811696qwh.37 for ; Mon, 27 Jul 2009 14:32:52 -0700 (PDT) In-Reply-To: <4A6DBE54.3080609@cs.ualberta.ca> Sender: kvm-owner@vger.kernel.org List-ID: Hi Cam, > Sorry I haven't answered your email from last Thursday. =A0I'll answe= r it > shortly. Thanks, I'm still chipping away at it slowly. >> On Thu, Jul 9, 2009 at 6:01 PM, Cam Macdonell wr= ote: >> >>> 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. >>> =A0That'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? It comes from outside qemu, it is mapped in via mmap. >> 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= =2E >> (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 wa= s > opened. =A0So I *think* that switching the shm_open(...) to > open("/dev/chardev"), might be all that's necessary as long as your c= har > device handles mmapping. It does, but it maps memory into the user program rather than out. >> What I don't understand is how to turn the host address returned fro= m >> mmap into a ram_addr_t to pass to pci_register_bar. > > Memory must be allocated using the qemu RAM functions. That seems to be the problem. The memory cannot be allocated by qemu_ram_alloc, because it is coming from the mmap call. The memory is already allocated outside the qemu process. mmap can indicate where in the qemu process address space the local mapping should be, but mapping it 'on top' of memory allocated with qemu_ram_alloc doesn't seem to work (I get a BUG in gfn_to_pfn). > =A0Look at > qemu_ram_alloc() and qemu_get_ram_ptr() which are a two step process = that > allocate the memory. =A0Then notice that the ivshmem_ptr is mmapped o= n to the > memory that is returned from the qemu_get_ram_ptr. > > pci_register_bar calls a function (the last parameter passed to it) t= hat in > turn calls cpu_register_physical_memory which registers the allocated= memory > (accessed a s->ivshmem_ptr) as the BAR. Right, that seems to make sense for your application where you allocate the memory in qemu and then share it externally via shm. Have you thought about how to use a shm file that has already been allocated by another application? I think you mentioned this as a feature you were going to look at in one of your list posts. Regards, Stephen.