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

To: "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/5] VT-d support for PV guests
From: "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>
Date: Wed, 21 May 2008 13:42:22 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 May 2008 22:42:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <18482.57829.832681.982678@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8C834404208B254EAD4E532C94859869017DD5C2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18482.57829.832681.982678@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci6hvmh7ao/HkkZSK2c2Z3lJjFZzwAX+VQg
Thread-topic: [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