[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
>-----Original Message----- >From: Espen Skoglund [mailto:espen.skoglund@xxxxxxxxxxxxx] >Sent: Tuesday, May 20, 2008 10:36 PM >To: Yang, Xiaowei >Cc: Espen Skoglund; xen-devel@xxxxxxxxxxxxxxxxxxx >Subject: RE: [Xen-devel] [PATCH 0/5] VT-d support for PV guests > >[Xiaowei Yang] >> Espen, >> The patches look good to me with some comments: > >> - For the occasions when P2M is changed, the hooks of >> iommu_{un}map_page() can be added cleaner. Only the hooks inside >> guest_physmap_add/remove_page() are necessary. The hooks in >> populate_physmap() and memory_exchange() can be omitted by some >> small code rearrangement like removing if(paging_mode_translate(d)) >> before calling guest_physmap_add_page(). > >Yes. I considered this as an option as well, but ended up with the >current approach. Your suggestion is probably cleaner, so I'll switch >over to doing that. > > >> - gnttab_map/unmap_grant_ref() need to be hooked also. There are no >> P2M changes at that time while the guest PT is updated directly. The >> mapped pages can also be used for DMA by backend drivers. > >Thanks. Overlooked that one. Only caught the gnttab_transfer(). > > >> - dom0 can be treated as the same as other PV domains with regard to >> VTd PT updating. Unfortunately, it need some special care. All of >> devices are assigned to it by default and usually it ones the most >> of devices. iommu_{un}map_page() could be called very frequently by >> it while it serves other domains IO requests. It will bring >> performance penalty and CPU overhead. > >dom0 should not need to do any VT-d page table updating once it has >been set up, so marking it as need_iommu() should be unnecessary. >Also, if passthrough mode is supported in VT-d then dom0 does not need >to have VT-d page tables at all. I think setting it's VT-d tables up >to have complete access at startup and leave it that way is perfectly >fine. > Currently, [0, max_page] is 1:1 mapped in dom0's VT-d page table, which gives dom0 the ability to DMA all range of memory, including critical regions like Xen HV. It's a security hole, and it's still there with passthrough mode. Dynamic VT-d page table for dom0 can fix it. Hopefully, it will be acceptable with gnttab map/unmap and other optimizations. Thanks, Xiaowei _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |