[Top][All Lists]
[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?
>>
>
>
Re: [Qemu-devel] [PATCH v7 0/4] Inter-VM shared memory device, Avi Kivity, 2010/07/26
Re: [Qemu-devel] [PATCH v7 0/4] Inter-VM shared memory device, Anthony Liguori, 2010/07/26