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


Xen-devel mailing list



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