Re: [Xen-devel] [PATCH v2] VTD/Intremap: Disable Intremap on Chipset 5500/5520/X58 due to errata

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.03.13 at 14:46, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> wrote:
> http://www.intel.com/content/www/us/en/chipsets/5520-and-5500-chipset-ioh-specific
>  
> ation-update.html
> 
> Stepping B-3 has two errata (#47 and #53) related to Interrupt
> remapping, to which the workaround is for the BIOS to completely disable
> interrupt remapping.  These errata are fixed in stepping C-2.
> 
> Unfortunately this chipset stepping is very common and many BIOSes are
> not disabling interrupt remapping on this stepping .  We can detect this in
> Xen and prevent Xen from using the problematic interrupt remapping feature.
> 
> The Intel 5500/5520/X58 chipset does not support VT-d
> Extended Interrupt Mode(EIM). This means the iommu_supports_eim() check
> always fails and so x2apic mode cannot be enabled in Xen before this quirk
> disables the interrupt remapping feature.

Just like for the first version of this patch (where you didn't really
follow up on all the comment made), and in line with the XSA-36
follow up that you also asked upon some time last week, I don't
think we can take this as is. First and foremost we need to settle
on a policy:

- fully disable IOMMU
  - stay with allowing PV passthrough in this mode
  - also suppress PV passthrough in this mode
- partially disable IOMMU in presence of platform errata
  (yielding an unexpectedly - to the user - insecure system)
- other options?

All that including ways to override the behavior towards lower
security (but perhaps not towards erroneous behavior, i.e. in the
case here we probably shouldn't permit interrupt remapping to be
forcibly enabled).

This specifically needs to be distinguished from firmware
disabling/hiding some functionality - we ought to be permitted
to expect the operator to know the security level that the
platform provides.

My personal opinion is that in the event where we need to disable
_any_ IOMMU functionality, we ought to _fully_ suppress
passthrough (and hence we can as well disable the IOMMU
altogether, as we did for XSA-36). We can _then_ allow the user
to re-enable the IOMMU (in the case here as much as for XSA-36
e.g. via "iommu=no-intremap", i.e. the operator explicitly
declaring to be willing to take the risk). That would require parts
of the XSA-36 follow up patch that I had posted (other parts of it
would need adjustment).

Only then can we, consistently for AMD Vi and VT-d, implement
workarounds like the one here.

Besides that, please don't use dprintk() except for truly
debugging messages - the file/line prefixing is only producing
extra noise when the message itself is unique.

And - do you really need to iterate over all buses on segment 0?
The X58 data sheet says at the top of section 17.1: "All devices
on the IOH reside on bus 0". I wonder whether you wouldn't
instead need to do this over all segments, on each bus 0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel