[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 16.01.13 at 22:09, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> wrote:
> On 16/01/13 13:57, Jan Beulich wrote:
>>>>> On 16.01.13 at 00:27, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> 
>>>>> wrote:
>>> +/* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
>>> + * Fixed in stepping C-2. */
>>> +void __init tylersburg_intremap_quirk(void)
>>> +{
>>> +    uint32_t bus, device;
>>> +    uint8_t rev;
>>> +
>>> +    for ( bus = 0; bus < 0x100; bus++ )
>>> +    {
>>> +        /* Match on System Management Registers on Device 20 Function 0 */
>>> +        device = pci_conf_read32(0, bus, 20, 0, PCI_VENDOR_ID);
>>> +        rev = pci_conf_read8(0, bus, 20, 0, PCI_REVISION_ID);
>>> +
>>> +        if ( rev == 0x13 && device == 0x342e8086 )
>>> +        {
>>> +            dprintk(XENLOG_INFO VTDPREFIX,
>>> +                    "Disabling Interrupt Remapping due to Intel 
>>> 5500/5520/X58 Chipset errata #47, #53\n");
>>> +            iommu_intremap = 0;
>> Unless it is guaranteed that no system with this chipset can have
>> x2APIC, I don't think this is right. For one, this happens way too
>> late (namely after x2apic_bsp_setup()). And second, if you move
>> this earlier, such systems with x2APIC pre-enabled won't boot
>> anymore.
> After some digging, I discovered that the errata affects chipsets 
> (5520,5500,X58) which don't have IOMMU EIM( Extended Interrupt Mode) 
> support. EIM is required to support x2APIC mode and so this means the 
> chipset can't support x2APIC mode and so we should never see a system 
> with x2APIC enabled.

Xiantao,

while I realize that you already ack-ed that patch, I'd like this to
be confirmed, as well as the fact that there indeed is on better
workaround known than disabling interrupt remapping.

Malcolm,

I still don't feel well with this making a small security hole bigger
(the erratum to me mainly means that with lost interrupts we
might observe systems hangs in the worst case, or maybe
data corruption if recovery code in the OSes doesn't work well).
Whereas with interrupt remapping disabled passthrough
becomes inherently insecure (and the host vulnerable to guest
attacks).

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.

Jan


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


 


Rackspace

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