RE: [Xen-devel] [PATCH 0/5] VT-d support for PV guests

["Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>]

>-----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