Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

From: Jan Beulich <jbeulich@suse.com>
To: "Roman Shaposhnik" <roman@zededa.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
Date: Wed, 7 Aug 2019 09:08:58 +0200	[thread overview]
Message-ID: <999aabe3-7406-9ad9-fb85-432c29352a77@suse.com> (raw)
In-Reply-To: <CAMmSBy91XfNz5DfbaL8OC7v1eYp7n_EKjGgSgAH+YBALh9HM-g@mail.gmail.com>

On 06.08.2019 23:48, Roman Shaposhnik wrote:
> On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
>>
>> On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
>>> On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
>>>> This patch completely fixes the problem for me!
>>>>
>>>> Thanks Roger! I'd love to see this in Xen 4.13
>>>
>>> Thanks for testing!
>>>
>>> It's still not clear to me why the previous approach didn't work, but
>>> I think this patch is better because it removes the usage of
>>> {set/clear}_identity_p2m_entry from PV domains. I will submit this
>>> formally now.
>>
>> Sorry to bother again, but since we still don't understand why the
>> previous fix didn't work for you, and I can't reproduce this with my
>> hardware, could you give the attached patch a try?
> 
> No worries -- and thanks for helping to get it over the finish line --
> this is much appreciated!
> 
> I'm happy to say that this latest patch is also working just fine. So
> I guess this is the one that's going to land in Xen 4.13?

Not necessarily - the other patch is also a candidate, but its
description would need to explain what was actually wrong.

>> AFAICT the only difference between the non-working version and the
>> working version is the flush, so I've added it here.

Now I'm afraid I still can't draw a helpful conclusion from Roman's
successful test: intel_iommu_hwdom_init(), after having called
setup_hwdom_rmrr(), calls iommu_flush_all() (with one other,
seemingly innocent call in between). The only conclusion I _could_
draw is that iommu_flush_all() doesn't do what its name says. Which
would be quite bad. But

[orig]
iommu_flush_all()
-> iommu_flush_iotlb_global(flush_non_present_entry=0)
-> flush->iotlb(DMA_TLB_GLOBAL_FLUSH, flush_non_present_entry=0)

[patch]
iommu_flush_iotlb_all()
-> iommu_flush_iotlb(dma_old_pte_present=0, page_count=0)
-> iommu_flush_iotlb_dsi(flush_non_present_entry=0)
-> flush->iotlb(DMA_TLB_DSI_FLUSH, flush_non_present_entry=0)

suggests to me that (as one would infer from the names) is the
more through flush. I must be overlooking something ...

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel