Re: R/W HG memory mappings with kvm?

[Cam Macdonell <cam@cs.ualberta.ca>]

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<cam@cs.ualberta.ca> 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