WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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.


Thanks for feedback.  Will repost once I've incorporated all the
comments.

        eSk




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel