[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] VTD/Intremap: Disable Intremap on Chipset 5500/5520/X58 due to errata
On Thu, 2013-01-17 at 09:33 +0000, Jan Beulich wrote: > >>> On 17.01.13 at 10:15, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > > On Thu, 2013-01-17 at 09:09 +0000, Jan Beulich wrote: > >> >>> On 17.01.13 at 10:01, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > >> > On Thu, 2013-01-17 at 08:49 +0000, Jan Beulich wrote: > >> >> So the question really is whether, rather than disabling interrupt > >> >> remapping, disabling the IOMMU as a whole wouldn't be the > >> >> better (read: more secure) workaround. > >> > > >> > That, plus providing a command line "I accept the risks" option, is the > >> > approach we've taken in the past I think. > >> > >> An option for this we already have - "iommu=force". > > > > I thought that but isn't it sort of the other way found? iommu=force > > will fail to boot if the iommu cannot be enabled, including intremap > > support. > > Of course using "iommu=force" when enabling the IOMMU fails > is a bad idea - that will indeed panic. But we're talking about the > situation where enabling the IOMMU so far worked fine, and the > option is only to be used as an override to us disabling it as > workaround. I wasn't aware that =force had dual meaning like that. It seems dangerous to me, if I build a (security) product which wants to ensure that an iommu is always available and therefore add "iommu=force" to the command line this will have the side effect of forcibly enabling the iommu in an unsafe mode on certain systems. I hope I've just misunderstood how this works! > > But perhaps iommu=no-intremap does what we want already? > > Not really - we want to do the disabling automatically (turning > off both iommu and interrupt remapping), so that to override > this one would need "iommu=force" (enabling the IOMMU, but > not interrupt remapping) or "iommu=force,intremap" (enabling > both - that case needs some code adjustment to work as > described). I agree with the premise here, even if I'm confused by the exact names of the options needed to override. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |