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