[Top][All Lists]

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

Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback

From: David Hildenbrand
Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
Date: Mon, 10 Feb 2020 10:53:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 10.02.20 10:50, Shameerali Kolothum Thodi wrote:
>> -----Original Message-----
>> From: David Hildenbrand [mailto:address@hidden]
>> Sent: 10 February 2020 09:29
>> To: Shameerali Kolothum Thodi <address@hidden>;
>> Igor Mammedov <address@hidden>
>> Cc: address@hidden; address@hidden;
>> address@hidden; address@hidden; address@hidden;
>> xuwei (O) <address@hidden>; Linuxarm <address@hidden>;
>> address@hidden; address@hidden; address@hidden
>> Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
>>>> Can you look the original value up somehow and us the resize callback
>>>> only as a notification that something changed? (that value would have to
>>>> be stored somewhere and migrated I assume - maybe that's already being
>>>> done)
>>> Ok. I will take a look at that. But can we instead pass the 
>>> block->used_length
>> to
>>> fw_cfg_add_file_callback(). That way we don’t have to change the
>> qemu_ram_resize()
>>> as well. I think Igor has suggested this before[1] and I had a go at it 
>>> before
>> coming up
>>> with the "req_length" proposal here.
>> You mean, passing the old size as well? I don't see how that will solve
>> the issue, but yeah, nothing speaks against simply sending the old and
>> the new size.
> Nope. I actually meant using the block->used_length to store in the 
> s->files->f[index].size. 
> virt_acpi_setup()
>   acpi_add_rom_blob()
>     rom_add_blob()
>       rom_set_mr()  --> used_length  = page aligned blob size
>         fw_cfg_add_file_callback()  --> uses actual blob size.
> Right now what we do is use the actual blob size to store in FWCfgEntry.
> Instead pass the RAMBlock used_length to fw_cfg_add_file_callback().
> Of course by this, the firmware will see an aligned size, but that is fine I 
> think.
> But at the same time this means the qemu_ram_resize() can stay as it is 
> because it will invoke the callback when the size changes beyond the aligned
> page size. And also during migration, there won't be any inconsistency as 
> everyone
> works on aligned page size.
> Does that make sense? Or I am again missing something here?

Oh, you mean simply rounding up to full pages in the fw entries? If we
can drop the "sub-page" restriction, that would be awesome!

Need to double check if that could be an issue for fw/migration/whatever.


David / dhildenb

reply via email to

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