Re: [Qemu-devel] [RFC PATCH qemu 1/4] memory: Postpone flatview and dispatch tree building till all devices are added

[Alexey Kardashevskiy]

On 07/09/17 19:30, Peter Maydell wrote:
> On 7 September 2017 at 10:20, Alexey Kardashevskiy <address@hidden> wrote:
>> Most devices use at least one address space and every time a new address
>> space is added, flat views and dispatch trees are rebuild for all address
>> spaces. This is not a problem for a relatively small amount of devices but
>> even 50 virtio-pci devices use more than 8GB of RAM.
>>
>> What happens that on every flatview/dispatch rebuild, new arrays are
>> allocated and old ones release but the release is done via RCU so until
>> an entire machine is build, they are not released.
>>
>> This wraps devices creation into memory_region_transaction_begin/commit
>> to massively reduce amount of flat view/dispatch tree (re)allocations.
>>
>> Signed-off-by: Alexey Kardashevskiy <address@hidden>
>> ---
>>  vl.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/vl.c b/vl.c
>> index 8e247cc2a2..3c39cc8b3a 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4655,12 +4655,16 @@ int main(int argc, char **argv, char **envp)
>>      igd_gfx_passthru();
>>
>>      /* init generic devices */
>> +    memory_region_transaction_begin();
>> +
>>      rom_set_order_override(FW_CFG_ORDER_OVERRIDE_DEVICE);
>>      if (qemu_opts_foreach(qemu_find_opts("device"),
>>                            device_init_func, NULL, NULL)) {
>>          exit(1);
>>      }
>>
>> +    memory_region_transaction_commit();
> 
> What happens if something in a device realize function tries
> to do a read from an AddressSpace? 


address_space_memory is created before that loop but yes, address spaces
for devices are not rendered and QEMU crashes, needs fixing.

> I can't think of any examples
> that need to do that and I suspect it's probably a bug if anybody
> tries it, but I'm curious whether this change alters the failure
> mode...




-- 
Alexey