From: "Jan Beulich" <JBeulich@suse.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Thierry Laurion <thierry.laurion@gmail.com>
Subject: Re: pre Sandy bridge IOMMU support (gm45)
Date: Mon, 01 Feb 2016 00:59:00 -0700 [thread overview]
Message-ID: <56AF1E5402000078000CCBDF@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20160130014758.GA24446@mail-itl>
>>> On 30.01.16 at 02:47, <marmarek@invisiblethingslab.com> wrote:
> On Tue, Jan 26, 2016 at 04:37:05AM -0700, Jan Beulich wrote:
>> (re-adding xen-devel)
>>
>> >>> On 26.01.16 at 12:28, <thierry.laurion@gmail.com> wrote:
>> > Iommu=0 let the whole Qubes system work, without enforcing hardware
>> > compartimentalisation (iommu is enforced in software mode)
>> >
>> > When iommu=no-igfx is enforced, shell console boot up works flawlessly. All
>> > domu machines get booted up. A system hang will happen at the moment a domu
>> > machine does graphic rendering,
>>
>> And this is (other than I originally implied) without passing through
>> the IGD to the DomU? If so, I can't see the difference between a
>> guest rendering to its display (and vncviewer or whatever frontend
>> you use converting this to rendering on the host) and rendering
>> which originates in the host.
>
> Not sure if relevant, but window content is mapped from PV domU directly
> into X server (in dom0) address space, using xc_map_foreign_pages. It is
> done by hacking XShmAttach function. Not sure what graphics driver do
> with it next. Theoretically it could be possible that driver will direct IGD
> to do DMA directly from that place, but I guess it does not.
Interesting. This then really needs to be investigated from the
Qubes end rather than here. Possible resulting patches, if
relevant outside of that unusual setup, would then of course be
appreciated to be sent here.
Jan
next prev parent reply other threads:[~2016-02-01 7:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-23 7:38 pre Sandy bridge IOMMU support (gm45) Thierry Laurion
2016-01-24 18:21 ` Thierry Laurion
2016-01-24 23:45 ` [qubes-devel] " Marek Marczykowski-Górecki
2016-01-26 21:10 ` Thierry Laurion
2016-01-27 5:08 ` Thierry Laurion
2016-01-29 17:52 ` Thierry Laurion
2016-01-25 10:01 ` Andrew Cooper
2016-01-25 14:30 ` Jan Beulich
2016-01-25 21:49 ` Thierry Laurion
2016-01-26 10:52 ` Jan Beulich
[not found] ` <CAAzJznxr4CT8J0fnx1kkWfQ+56J0PH+QBjgjH=6phtzbDd4dyw@mail.gmail.com>
2016-01-26 11:37 ` Jan Beulich
2016-01-26 11:57 ` Thierry Laurion
2016-01-26 12:27 ` Jan Beulich
2016-01-26 22:21 ` Tian, Kevin
2016-01-26 23:39 ` Thierry Laurion
2016-01-30 1:47 ` Marek Marczykowski-Górecki
2016-02-01 7:59 ` Jan Beulich [this message]
2016-02-01 12:28 ` Marek Marczykowski-Górecki
2016-02-01 12:35 ` Jan Beulich
2016-02-20 18:20 ` Thierry Laurion
2016-02-21 3:45 ` Thierry Laurion
2016-02-28 19:08 ` Thierry Laurion
2016-06-26 23:47 ` Thierry Laurion
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=56AF1E5402000078000CCBDF@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=marmarek@invisiblethingslab.com \
--cc=thierry.laurion@gmail.com \
--cc=xen-devel@lists.xenproject.org \
/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).