qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 0/4] Inter-VM shared memory device


From: Cam Macdonell
Subject: Re: [Qemu-devel] [PATCH v7 0/4] Inter-VM shared memory device
Date: Mon, 26 Jul 2010 15:46:32 -0600

On Mon, Jul 26, 2010 at 2:41 PM, Anthony Liguori <address@hidden> 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?
>>
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]