qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] hostmem-file: allow option 'size' optional


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2/2] hostmem-file: allow option 'size' optional
Date: Wed, 26 Oct 2016 16:30:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


On 26/10/2016 16:17, Eduardo Habkost wrote:
> On Wed, Oct 26, 2016 at 03:49:29PM +0800, Haozhong Zhang wrote:
>> On 10/26/16 13:56 +0800, Haozhong Zhang wrote:
>>> On 10/25/16 17:50 -0200, Eduardo Habkost wrote:
>>>> On Mon, Oct 24, 2016 at 05:21:51PM +0800, Haozhong Zhang wrote:
>>>>> +    if (memory) {
>>>>> +        memory = memory ?: file_size;
>>>>
>>>> This doesn't make sense to me. You already checked if memory is
>>>> zero above, and now you are checking if it's zero again.
>>>> file_size is never going to be used here.
>>>>
>>>>> +        memory_region_set_size(block->mr, memory);
>>>>> +        memory = HOST_PAGE_ALIGN(memory);
>>>>> +        block->used_length = memory;
>>>>> +        block->max_length = memory;
>>>>
>>>> This is fragile: it duplicates the logic that initializes
>>>> used_length and max_length in qemu_ram_alloc_*().
>>>>
>>>> Maybe it's better to keep the file-size-probing magic inside
>>>> hostmem-file.c, and always give a non-zero size to
>>>> memory_region_init_ram_from_file().
>>>>
>>>
>>> Yes, I can move the logic in above if-statement to 
>>> qemu_ram_alloc_from_file().
>>>
>>
>> Maybe no. Two reasons:
>> 1) Patch 1 has some code related to file size and I'd like to put all
>>   logic related to file size in the same function.
>> 2) file_ram_alloc() has the logic to open/create/close the backend file
>>   and handle errors in this process, which also needs to move to
>>   qemu_ram_alloc_from_file() if file-size-probing is moved.
> 
> I'd argue to move the whole file creation/opening logic to
> hostmem-file.c. But it wouldn't be a small amount of work, so
> your points make sense.
> 
> The plan below could work, but I would like it to get feedback
> from the Memory API maintainer (Paolo).

Yes, it makes sense.

Paolo

>>
>> Instead, I'd
>> 1) keep all logic related to file size in file_ram_alloc()
>>
>> 2) let file_ram_alloc() return the value of 'memory', e.g.
>>     static void *file_ram_alloc(RAMBlock *block,
>>    -                            ram_addr_t *memory,
>>    +                            ram_addr_t memory,
>>                                 const char *path,
>>                                 Error **errp)
>>     {
>>         ...
>>         // other usages of 'memory' are changed as well
>>    -    memory = ROUND_UP(*memory, block->page_size);      +    *memory =
>> ROUND_UP(*memory, block->page_size);
>>         ...
>>     }
>> 3) in qemu_ram_alloc_from_file(), move setting
>>   block->used_length/max_length after calling file_ram_alloc(),
>>   e.g.
>>     RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
>>                                        bool share, const char *mem_path,
>>                                        Error **errp)
>>     {
>>         ...
>>         size = HOST_PAGE_ALIGN(size);
>>         new_block = g_malloc0(sizeof(*new_block));
>>         new_block->mr = mr;
>>   -     new_block->used_length = size;
>>   -     new_block->max_length = size;
>>         new_block->flags = share ? RAM_SHARED : 0;
>>   -     new_block->host = file_ram_alloc(new_block, size,
>>   +     new_block->host = file_ram_alloc(new_block, &size,
>>                                          mem_path, errp);
>>         if (!new_block->host) {
>>            g_free(new_block);
>>            return NULL;
>>         }
>>   +     new_block->used_length = size;
>>   +     new_block->max_length = size;
>>         ...
>>     }
>>
> 



reply via email to

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