lkml.org 
[lkml]   [2012]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Subjectwhy 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 ?
    From
    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@kernel.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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-07-04 09:21    [W:0.026 / U:61.620 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site