[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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.