linux-kernel - why Linux kernel will update BIOS's interrupt remapping table base address ? why does Linux Kernel create a new table instead of the one that BIOS provided ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANuKePntggbPrY7=eq-+AHzqcPG4Y6UGnP+9B57Gs2xNLeCR_A@mail.gmail.com>
Date:	Wed, 4 Jul 2012 14:55:47 +0800
From:	Lin-Bao Zhang <2004.zhang@...il.com>
To:	flyboy@...il.com, yinghai@...nel.org, suresh.b.siddha@...el.com
Cc:	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: why Linux kernel will update BIOS's interrupt remapping table base
 address ? why does Linux Kernel create a new table instead of the one that
 BIOS provided ?

Hi all,

my questions are :
1, Linux kernel will create a new interrupt remapping table to replace
BIOS' table ?
we guys used ITP to know that BIOS' interrupt remapping table pointer
has been changed . I am tracing related code to see how linux kernel
creates interrupt remapping table.

2, why ? why linux kernel doesn't directly use BIOS' table ?   our
bios has enabled x2apic mode ,and also export interrupt remapping
table

3, what is the relationship between interrupt remapping table with
"virtual wire mode B" , now , if firmware disabled "virtual wire mode
B" , linux kernel won't panic , otherwise , linux kernel will panic .

thanks for your replies .

from following commit messages , I have known that BIOS should provide
a interrupt remapping table and export to OS.
-------------------------------------------------------------------------------
commit fb209bd891645bb87b9618b724f0b4928e0df3de
Author: Yinghai Lu <yinghai@...nel.org>
Date:   Wed Dec 21 17:45:17 2011 -0800

    x86, x2apic: Fallback to xapic when BIOS doesn't setup interrupt-remapping

    On some of the recent Intel SNB platforms, by default bios is pre-enabling
    x2apic mode in the cpu with out setting up interrupt-remapping.
    This case was resulting in the kernel to panic as the cpu is already in
    x2apic mode but the OS was not able to enable interrupt-remapping (which
    is a pre-req for using x2apic capability).

    On these platforms all the apic-ids are < 255 and the kernel can fallback to
    xapic mode if the bios has not enabled interrupt-remapping (which is
    mostly the case if the bios has not exported interrupt-remapping
tables to the
    OS).
    -------------------------------------------------------------------------------------

But now , I am carefully checking apic.c code to trace how interrupt
remapping table is enabled again by linux kernel.

struct smp_ops smp_ops  define native_smp_prepare_cpus() functions ->
native_smp_prepare_cpus() -> default_setup_apic_routing() ->
enable_IR_x2apic() -> enable_IR() -> enable_intr_remapping() ->
setup_intr_remapping() -> iommu_set_intr_remapping()
I check iommu_set_intr_remapping() function , it seems that it indeed
modify INTR remapping base addr.

FYI:
This function indeed follow “Intel VT for direct IO.pdf” ‘s P109
static void iommu_set_intr_remapping(struct intel_iommu *iommu, int mode)
{
   u64 addr;
   u32 sts;
   unsigned long flags;

   addr = virt_to_phys((void *)iommu->ir_table->base);

   raw_spin_lock_irqsave(&iommu->register_lock, flags);

   dmar_writeq(iommu->reg + DMAR_IRTA_REG,   // #define DMAR_IRTA_REG
0xb8 /* Interrupt remapping table addr register */
          (addr) | IR_X2APIC_MODE(mode) | INTR_REMAP_TABLE_REG_SIZE);

   /* Set interrupt-remapping table pointer */
   iommu->gcmd |= DMA_GCMD_SIRTP;     //P109 in Intel VT-d for direct
IO.pdf  from ftp://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);

   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
            readl, (sts & DMA_GSTS_IRTPS), sts);
   raw_spin_unlock_irqrestore(&iommu->register_lock, flags);

   /*
   * global invalidation of interrupt entry cache before enabling
   * interrupt-remapping.
   */
   qi_global_iec(iommu);

   raw_spin_lock_irqsave(&iommu->register_lock, flags);

   /* Enable interrupt-remapping */
   iommu->gcmd |= DMA_GCMD_IRE;
   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);

   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
            readl, (sts & DMA_GSTS_IRES), sts);

   raw_spin_unlock_irqrestore(&iommu->register_lock, flags);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/