[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] pre Sandy bridge IOMMU support (gm45)



>>> On 30.01.16 at 02:47, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.