xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: "Han, Weidong" <weidong.han@intel.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: feature suggestion: DMAR table emulation for Xen
Date: Fri, 14 May 2010 12:58:29 +0200	[thread overview]
Message-ID: <4BED2CD5.4060900@invisiblethingslab.com> (raw)
In-Reply-To: <C812E911.144DD%keir.fraser@eu.citrix.com>


[-- Attachment #1.1: Type: text/plain, Size: 1609 bytes --]

On 05/14/2010 12:48 PM, Keir Fraser wrote:
> On 14/05/2010 11:15, "Joanna Rutkowska" <joanna@invisiblethingslab.com>
> wrote:
> 
>>> Yeah, actually the integrated graphics can implement all sorts of dirty
>>> tricks between OS driver, video BIOS, and SMM. This can rely on fixed memory
>>> areas for communication -- both for host accesses and DMA, the latter
>>> requiring RMRR setup. Maybe the RMRRs are static per-chipset, but I wouldn't
>>> be too sure of it.
>>>
>> Hmmm... Shouldn't this affect only (and potentially) the text mode
>> display? I would expect that once Dom0 Linux takes over, it would be
>> using its own IGD driver that is VT-d aware and is not on the mercy of
>> the evil BIOS?
> 
> Well, if you do not pass through the IGD to a domU then the issue is moot.
> Dom0 gets an all-inclusive mapping below 4GB, which should be a superset of
> anything the RMRRs would specify. It's when passing through to a domU that
> the RMRRs matter, especially if you pass through as the primary adaptor and
> hence re-execute the video BIOS in domU context.
> 

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

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

Do you do IGD passthrough in Xen Client?

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

  reply	other threads:[~2010-05-14 10:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-13 14:14 feature suggestion: DMAR table emulation for Xen Joanna Rutkowska
2010-05-14  5:41 ` Kay, Allen M
2010-05-14  9:22   ` Joanna Rutkowska
2010-05-14  9:35     ` Keir Fraser
2010-05-14 10:15       ` Joanna Rutkowska
2010-05-14 10:48         ` Keir Fraser
2010-05-14 10:58           ` Joanna Rutkowska [this message]
2010-05-14 11:29             ` Keir Fraser
2010-05-14 11:47               ` philosophically about IGD pass-through (was: feature suggestion: DMAR table emulation for Xen) Joanna Rutkowska
2010-05-14 11:58                 ` James Harper
2010-05-14 12:30                 ` Keir Fraser
2010-05-14 15:57                 ` Dan Magenheimer
2010-05-14 16:43                   ` philosophically about IGD pass-through Joanna Rutkowska
2010-05-14 17:54                 ` philosophically about IGD pass-through (was: feature suggestion: DMAR table emulation for Xen) Kay, Allen M
2010-05-15 16:54             ` feature suggestion: DMAR table emulation for Xen Ian Pratt
2010-05-15 17:12               ` IGD passthrough security (was Re: feature suggestion: DMAR table emulation for Xen) Joanna Rutkowska
2010-05-14  9:41     ` feature suggestion: DMAR table emulation for Xen Barde Kaushik 00901718
2010-05-14 10:16       ` Joanna Rutkowska
2010-05-14 14:25         ` Barde Kaushik 00901718

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BED2CD5.4060900@invisiblethingslab.com \
    --to=joanna@invisiblethingslab.com \
    --cc=allen.m.kay@intel.com \
    --cc=joseph.cihula@intel.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=weidong.han@intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).