From owner-freebsd-current@FreeBSD.ORG Thu Apr 9 10:50:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAC7F16F for ; Thu, 9 Apr 2015 10:50:30 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 903B7150 for ; Thu, 9 Apr 2015 10:50:30 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YgA2U-000EWz-QD; Thu, 09 Apr 2015 13:50:26 +0300 Date: Thu, 9 Apr 2015 13:50:26 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Subject: Re: No IOMMU/DMAR with DELL 3020 Message-ID: <20150409105026.GH8220@zxy.spb.ru> References: <552635A5.5070707@entel.upc.edu> <20150409082128.GF2390@kib.kiev.ua> <5526381A.3010909@entel.upc.edu> <20150409083512.GG2390@kib.kiev.ua> <20150409085233.GD1394@zxy.spb.ru> <20150409100335.GJ2390@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150409100335.GJ2390@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Gustau P?rez , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 10:50:30 -0000 On Thu, Apr 09, 2015 at 01:03:35PM +0300, Konstantin Belousov wrote: > On Thu, Apr 09, 2015 at 11:52:33AM +0300, Slawa Olhovchenkov wrote: > > On Thu, Apr 09, 2015 at 11:35:12AM +0300, Konstantin Belousov wrote: > > > > > On Thu, Apr 09, 2015 at 10:28:10AM +0200, Gustau P?rez wrote: > > > > Yup, sorry for the error. I checked the micro in the ark and it has vt-d: > > > > > > > > http://goo.gl/CZZRHz > > > It only indicates that the CPU/northbridge has the hardware, but BIOS must > > > do a work to configure it and to inform the OS about the configuration. > > > Your BIOS did not. > > > > > > > > > > > in the bios, there's only one option to enable virtualization > > > > support, which is ticked. > > > > > > > > The complete log is here: > > > > > > > > http://dpaste.com/28FDMJQ > > > > > > > Dmesg would not give you any useful information there. A DMAR table > > > is either present, or is it not. In the later case, OS cannot use the > > > hardware, and if no option in BIOS is present, your only choice is to > > > complain to the machine/BIOS vendor. > > > > May be some OS utilites can do same work? > > This is theoretically capable? > > No, OS must know the peculiarities of the particular chipset. But also, Someone may be know this and wrote support in utility. May be chipset datashit available. I am don't talk about 'universal, out of box support in OS'. I am talk about theoretically utility, that perform some operations after OS load. Also, I am interesting by OS-control interleaving memory (in multi-socket configuration). This is totaly imposible or just very complex? > it must know the intimate details of the BIOS operation, since several > facilities perform background DMA transfers not under the OS control. > Examples are USB legacy emulation, BMC working with the main memory, > or UMA GPU in BIOS-configured mode. Normally, BIOS communicates the > requirements of such facilities to OS using RMRR records in the DMAR > table.