[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 17.01.13 at 10:51, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > 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's not that way currently, just how I envisioned Malcolm's patch to be changed (don't set iommu [and iommu_intremap] to 0 when iommu_force). > 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. In that case we need a new sub-option instead. Malcolm - are you going to follow up on this? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |