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@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?
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
--
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
