On 07/26/2010 04:46 PM, Cam Macdonell wrote:
On Mon, Jul 26, 2010 at 2:41 PM, Anthony Liguori<anthony@xxxxxxxxxxxxx> wrote:
On 07/26/2010 03:27 PM, Avi Kivity wrote:
On 07/26/2010 10:41 PM, Anthony Liguori wrote:
kvm_set_irqfd() is fine, it just needs to be ported. It should be there
due to vhost though?
It should, but isn't.
qemu_ram_map() is more difficult. I would think the better approach
would be to invert things. Instead of a "give me a stable mapping that is
shared atomically with a guest to this ram region", I would go with "go
create a ram region with this preallocated memory" and then just assume that
afterwards, you can make use of it and it's exposed as atomic memory.
Isn't that what qemu_ram_map() does?
Yup, name is misleading. I thought it was the equivalent of
cpu_physical_memory_map() but took a ram_addr_t instead of a target_ulong.
If I add it to my patch set, should I change the name to the suggested
qemu_ram_alloc_from_ptr() or keep it as is for consistency?
Please rename it.
Also, the current version of qemu_ram_map() in qemu-kvm.git uses the
DeviceState parameter. Are Alex's DeviceState changes going into 0.13
for the qemu_ram_*() functions??
They're already there.
Regards,
Anthony Liguori
Cam
Regards,
Anthony Liguori
ram_addr_t qemu_ram_map(DeviceState *dev, const char *name,
ram_addr_t size, void *host)
'host' is your "this preallocated memory", no?
--
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
