qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jason Wang
Subject: Re: [RFC v2 1/1] memory: Delete assertion in memory_region_unregister_iommu_notifier
Date: Wed, 1 Jul 2020 20:30:07 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0


On 2020/7/1 下午8:16, Peter Xu wrote:
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.


Yes, but the point stands still but the issue is still if ir=off.


   So I
think the assert should stand.


Do you mean vhost can't trigger the assert()? If yes, I don't get how it can't.

Thanks







reply via email to

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