From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: pre Sandy bridge IOMMU support (gm45) Date: Mon, 01 Feb 2016 05:35:04 -0700 Message-ID: <56AF5F0902000078000CCF2E@prv-mh.provo.novell.com> References: <56A63F9502000078000CAAD1@prv-mh.provo.novell.com> <56A75DF402000078000CAFAF@prv-mh.provo.novell.com> <56A7687102000078000CB035@prv-mh.provo.novell.com> <20160130014758.GA24446@mail-itl> <56AF1E5402000078000CCBDF@prv-mh.provo.novell.com> <20160201122856.GU1702@mail-itl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aQDhI-0007Og-B2 for xen-devel@lists.xenproject.org; Mon, 01 Feb 2016 12:35:12 +0000 In-Reply-To: <20160201122856.GU1702@mail-itl> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?UTF-8?Q?Marek=20Marczykowski-G=C3=B3recki?= Cc: xen-devel , Thierry Laurion List-Id: xen-devel@lists.xenproject.org >>> On 01.02.16 at 13:28, wrote: > On Mon, Feb 01, 2016 at 12:59:00AM -0700, Jan Beulich wrote: >> >>> On 30.01.16 at 02:47, 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, 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. > > Note that Thierry said "The point is the iommu=no-igfx doesn't fix the > issue", so either it is totally unrelated issue, or iommu=no-igfx is > broken. Does iommu=no-igfx have any meaning when IDG is _not_ passed > through to some domU? Yes: Iirc that option turns off the IOMMU responsible for IGD. > And generally - is IOMMU used in any way for dom0 > devices? Of course; by how much depends on what options you use (see the command line doc). > Is Linux kernel able to utilize it for its own purposes (my > guess: no)? Under Xen? If so - indeed, no. > Somehow unrelated: I've tried to get p2m iommu mapping using `xl > debug-key o`, but it's too long (and xenconsoled isn't fast enough to > catch it into hypervisor.log). Is is possible to enlarge console ring > buffer at runtime? No. > If not, is `conring_size` the right option? Yes. > How large > it should be (aprox) for `xl debug-key o` output? Depends on the amount of memory page tables need to be created for as well as how fragmented memory was at the time memory allocation for domains happens. I'm afraid you can only try it out. Jan