From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH][VTD] force boot to fail if interrupt remapping cannot be enabled when iommu=force Date: Thu, 28 Apr 2011 18:05:03 +0100 Message-ID: References: <987664A83D2D224EAE907B061CE93D5301C51BE9D8@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <987664A83D2D224EAE907B061CE93D5301C51BE9D8@orsmsx505.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Kay, Allen M" , "xen-devel@lists.xensource.com" Cc: "Cihula, Joseph" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 28/04/2011 00:42, "Kay, Allen M" wrote: > Force Xen boot to fail if interrupt remapping fails to enable and the > following are true: iommu=force is set as xen boot parameter, VT-d engine HW > is interrupt remapping capable, DMAR_INTR_REMAP bit is set in DMAR flags. > This forces iommu=force boot instances has interrupt remapping enabled if HW > and BIOS supports it. If HW and BIOS support it, why would it fail to be enabled? This doesn't look like a particularly useful panic() path. If interrupt remapping is so important, perhaps iommu=force should unconditionally require it, and panic in its absence regardless of platform features? As it is, this looks like a panic that is never realistically going to trigger. -- Keir > Signed-off-by: Allen Kay