Hi Cam,
> Sorry I haven't answered your email from last Thursday. I'll answer it
> shortly.
Thanks, I'm still chipping away at it slowly.
>> On Thu, Jul 9, 2009 at 6:01 PM, Cam Macdonell<cam@xxxxxxxxxxxxxx> 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?
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.
>> (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.
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 from
>> 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).
> 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.
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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
