qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH qemu v3 01/13] memory: Postpone flatview and dis


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH qemu v3 01/13] memory: Postpone flatview and dispatch tree building till all devices are added
Date: Tue, 19 Sep 2017 09:40:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 19/09/2017 08:57, Alexey Kardashevskiy wrote:
>>> 3) you can consult the list (or hash table :)) of live FlatViews (which
>>> means you keep it live after memory_region_transaction_commit ends, and
>>> only clear it on the next call), and reuse an existing FlatView.  Note
>>> that the number of distinct FlatViews should be very few, 
>>
>> I keep missing this bit - why few? Each virtio-pci device creates 2 AS,
>> with proxy->modern_bar and pci_dev->bus_master_container_region which are
>> unique and not aliases. Remember, 500 virtio devices is my test case ;)

Argh, no, it's me who keeps missing the bit.

> More details: pci_dev->bus_master_container_region is a root and it is
> enabled but its only child pci_dev->bus_master_enable_region is not. Ok, in
> flatview_topology_update() I can render a FV, see that it is empty
> (view->nr==0) and share an empty FV in this case too, this halves the
> number of FVs (from ~1000 to ~500 for 500 virtio devices).

We can also resolve "fake" aliases, obtained through a region with only
one subregion.

> But proxy->modern_bar (which has an modern_cfg alias which is a root of an
> AS) is enabled since it is created and I could disable it and enable
> afterwards but since a PCI device enablement is done by writing to the
> config space, I kind of stuck here.
> 
> I can do something like this and it helps a lot (now with -S I end up
> having 4 FVs and much better start time) but it is kinda hacky and "memory:
> Postpone flatview and dispatch tree building till all devices are added"
> solves this better imho, no?

I think modern_bar (actually modern_cfg) shouldn't have its own address
space, it's a pretty wasteful way to compute the dispatch tree where a
simple linked list or array would be enough:

memory-region: virtio-pci
  00000000fe000000-00000000fe003fff (prio 1, i/o): virtio-pci
    00000000fe000000-00000000fe000fff (prio 0, i/o): virtio-pci-common
    00000000fe001000-00000000fe001fff (prio 0, i/o): virtio-pci-isr
    00000000fe002000-00000000fe002fff (prio 0, i/o): virtio-pci-device
    00000000fe003000-00000000fe003fff (prio 0, i/o): virtio-pci-notify

Paolo



reply via email to

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