From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bauer Subject: Re: iommu: mapping reserved region failed - Q35 -VT-DIssue Date: Fri, 31 Oct 2008 14:31:06 +0100 Message-ID: <490B089A.10403@cubewerk.de> References: <49089D18.4030405@cubewerk.de><409D32C55C48D34DB5E31C8AB29EB15B071C6E25@FTLPEXCH05.citrite.net><4908B669.7080108@cubewerk.de><409D32C55C48D34DB5E31C8AB29EB15B071C6E74@FTLPEXCH05.citrite.net> <4908BC3C.3070307@cubewerk.de> <409D32C55C48D34DB5E31C8AB29EB15B071C6EA7@FTLPEXCH05.citrite.net> <4908C6FC.9030307@cubewerk.de> <715D42877B251141A38726ABF5CABF2C018686CF47@pdsmsx503.ccr.corp.intel.com> <49096151.8090500@cubewerk.de> <715D42877B251141A38726ABF5CABF2C018686D126@pdsmsx503.ccr.corp.intel.com> <49098860.9050309@cubewerk.de> <715D42877B251141A38726ABF5CABF2C018686D17B@pdsmsx503.ccr.corp.intel.com><4909C811.9070105@cubewerk.de><715D42877B251141A38726ABF5CABF2C018686D23C@pdsmsx503.ccr.corp.intel.com> <490AB8FC.1020807@cubewerk.de> <409D32C55C48D34DB5E31C8AB29EB15B071C760D@FTLPEXCH05.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <409D32C55C48D34DB5E31C8AB29EB15B071C760D@FTLPEXCH05.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Ross Philipson schrieb: > Stefan, > > Most of the paths through the function domain_context_mapping() (in > xen/drivers/passthrough/vtd/iommu.c) also trace extra information but I > don't see those traces so it is reasonable to assume that the function > is returning an error when the call to acpi_find_matched_drhd_unit() > fails to find a DRHD for the particular device. I would start by putting > a trace there in the failure case and trace out the bus/dev info > (presumably it is device 00:03.2). If this is the case then we can look > at your DMAR ACPI table - maybe this is a faulty BIOS issue (e.g. there > is no DRHD reporting INCLUDE_ALL devices). Sorry but thats a way to technically for me. I'm not familiar with C nor any other higher programming language. I will provide informations and do testing. > Or I may be wrong and the logging level is just not set for those > gdprintk() calls in trace in the switch statement (though I don't think > this is the case). If it is the case put code after the various calls in > the switch statement to test the "ret" value and trace an error if it Regards -- Stefan