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] feature suggestion: DMAR table emulation for Xen

To: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] feature suggestion: DMAR table emulation for Xen
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Date: Sat, 15 May 2010 17:54:52 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 15 May 2010 09:55:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BED2CD5.4060900@xxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C812E911.144DD%keir.fraser@xxxxxxxxxxxxx> <4BED2CD5.4060900@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcrzVCzA8ZutsJLwQSaVq2/3SnHIqAAeuhRw
Thread-topic: [Xen-devel] feature suggestion: DMAR table emulation for Xen
> Well, we don't do graphics passthrough in Qubes, mostly for two reasons:
> 
> 1) We believe users prefer seamless integration of all apps onto one
> desktop (and that requires only one domain, e.g. Dom0, to have access to
> the graphics card),

Not necessarily. If dom0 retains control of the display side of the GPU you can 
use video overlays to merge in windows from a couple of other domains. [Though 
ideally the GPU would use different PCI requestor IDs for displaying the 
framebuffer or fetching overlay data vs rendering]

> 2) Giving a potentially untrusted domain full access to the graphics
> device creates a potential security risk. In fact, you cannot make such an
> architecture secure without using TXT (yes, TXT in addition to VT-d).

I agree you can't give an untrusted domain full access, but there's an 
interesting design point where you emulate some parts of the GPU (e.g. anything 
controlling what is displayed) and pass-through others. GPU designs that enable 
you to do this without babysitting the command rings are obviously preferable...

Best,
Ian


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

<Prev in Thread] Current Thread [Next in Thread>