Re: [RFC v2 1/1] memory: Delete assertion in memory_region_unregister_iommu_notifier

[Peter Xu]

On Wed, Jul 01, 2020 at 04:11:49PM +0800, Jason Wang wrote:
> 
> On 2020/6/30 下午11:20, Peter Xu wrote:
> > On Tue, Jun 30, 2020 at 05:23:31PM +0800, Jason Wang wrote:
> > > > > Ok, we had a dedicated mr for interrupt:
> > > > > 
> > > > > memory_region_add_subregion_overlap(MEMORY_REGION(&vtd_dev_as->iommu),
> > > > > VTD_INTERRUPT_ADDR_FIRST,
> > > > > &vtd_dev_as->iommu_ir, 1);
> > > > > 
> > > > > So it should be fine. I guess the reason that I'm asking is that I 
> > > > > thought
> > > > > "IR" means "Interrupt remapping" but in fact it means "Interrupt 
> > > > > Region"?
> > I was meaning "interrupt remapping", and of course it's the interrupt region
> > too when IR enabled...
> 
> 
> Right.
> 
> 
> > 
> > > > > But I'm still not clear about the invalidation part for interrupt 
> > > > > region,
> > > > > maybe you can elaborate a little more on this.
> > > > > 
> > > > > Btw, I think guest can trigger the assert in vtd_do_iommu_translate() 
> > > > > if we
> > > > > teach vhost to DMA to that region:
> > > > Why would we want to?
> > > 
> > > I meant a buggy(malicious) guest driver.
> > Yes seems possible.  Do you want to post a patch?  Let me know if you want 
> > me
> > to...  Thanks,
> 
> 
> Yes please.

Oh wait...  Actually the comment above explains...

    /*
     * We have standalone memory region for interrupt addresses, we
     * should never receive translation requests in this region.
     */
    assert(!vtd_is_interrupt_addr(addr));

I overlooked myself that the IR region will be there even if ir=off.  So I
think the assert should stand.

-- 
Peter Xu