Re: [Qemu-devel] [PATCH qemu v3 01/13] memory: Postpone flatview and dispatch tree building till all devices are added

[Alexey Kardashevskiy]

On 19/09/17 20:47, Paolo Bonzini wrote:
> On 19/09/2017 12:39, Alexey Kardashevskiy wrote:
>>> No, there's still
>>>
>>>     as->dispatch = NULL;
>>>     memory_region_update_pending |= root->enabled;
>>>     memory_region_transaction_commit();
>>>
>>> when creating the address space, which touches all address spaces.
>>
>> This does not seem helping a lot - my test without such an optimization
>> allocates 2966044 FVs and 2388768 with it, which is just 25%, i.e. worth
>> making a patch but yet getting rid of those nasty virtio-modern address
>> spaces will do a lot better job.
> 
> Have you tried resolving aliases that are implemented with containers
> and one subregion?

Yes, for 10 virtio-net and 8 cpus it looks like below, #5 is that shared
thing. And if I use Intel e1000 instead, it is just 4 FVs.


(qemu) info mtree -f -d
FlatView #0
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #1
 AS "I/O", root: io
 Root memory region: io

FlatView #2
 AS "address@hidden", root: address@hidden
 Root memory region: address@hidden

FlatView #3
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #4
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #5
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 AS "virtio-net-pci", root: bus master container
 Root memory region: (none)
  No rendered FlatView

FlatView #6
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #7
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #8
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #9
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #10
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #11
 AS "memory", root: system
 AS "cpu-memory", root: system
 AS "cpu-memory", root: system
 AS "cpu-memory", root: system
 AS "cpu-memory", root: system
 AS "cpu-memory", root: system
 AS "cpu-memory", root: system
 AS "cpu-memory", root: system
 AS "cpu-memory", root: system
 Root memory region: system

FlatView #12
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci

FlatView #13
 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci
 Root memory region: virtio-pci


>> What is the exact concern about the "[PATCH qemu v3 01/13] memory: Postpone
>> flatview and dispatch tree building till all devices are added"? Is it that
>> you missed that modern AS thing in virtio and thought we can do well even
>> without it?
> 
> I am afraid that some of the special sysbus devices (not PCI, those go
> through the bus master DMA region and it's empty on startup) might write
> to memory during initialization.


And somehow QEMU guarantees that all RAM MRs are rendered to FlatViews even
though some might be added via -device (can they btw?)?



> 
> Thanks,
> 
> Paolo
> 
>> Or there is something wrong with the approach?
> 


-- 
Alexey