Re: [Qemu-devel] Flatview rendering scalability issue

[Paolo Bonzini]

On 12/03/19 13:14, Peter Xu wrote:
>> You're right.  However, the DMAR FlatView only has three sections so I
>> suspect it's not a big deal if we keep it per-device.  You'd still have
>> O(n) flatviews when the IOMMU is present and DMAR is enabled, but they
>> would have a constant number of sections so the cost overall is still
>> O(n) and not O(n^2).  If the IOMMU is present but DMAR is disabled, all
>> VT-d address spaces would still share the same FlatView vtd_root_nodmar,
>> and that is where the performance loss happens.
>>
>> The final scheme would be same as above with vtd_root_dmar replaced by
>> vtd_root_dmar_%d.
> 
> Just to make sure I understand - do you mean to keep the DMAR-enabled
> scenario as it is (I think it should be at least as slow as the perf
> number provided by Sergio)

No, the DMAR-enabled scenario would not be (too) slow because the
vtd_root_dmar FlatView only has three sections.  What makes things slows
is not sharing the vtd_root_nodmar FlatView, which has hundreds of sections.

> but we only fix up when guest doesn't
> enable DMAR?  Asked since IIUC normally people won't specify "-device
> intel-iommu" if they don't need the IOMMU functionality at all (and
> DMAR is the major one), and if it's not specified then we should not
> suffer from the performance degradation after all?

We would also suffer from performance degradation when using iommu=pt,
which is the common case for VFIO for example.

> (But hmm... I think it could benefit users who only need IR/x2apic...)
> 
> Btw, how do you think about my previous proposal?  Do you think it's
> doable somehow? (Make IOMMUMemoryRegion to have only MR pointer that
> points to the shared MRs)

I'm not sure, but it would certainly be too complicated for 4.0.

Paolo