Logical to Physical Address mapping, Physical to DIMM mapping - Linux

This is a discussion on Logical to Physical Address mapping, Physical to DIMM mapping - Linux ; Two questions, Is there a call to translate a virtual address to a physical address? Is there a way to find the physical address to DIMM map? I'd like to upgrade the memory test in sys_basher to call out a ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Logical to Physical Address mapping, Physical to DIMM mapping

  1. Logical to Physical Address mapping, Physical to DIMM mapping

    Two questions,

    Is there a call to translate a virtual address to a physical address?

    Is there a way to find the physical address to DIMM map?

    I'd like to upgrade the memory test in sys_basher to call out a specific
    DIMM.

    http://www.polybus.com/sys_basher_web/


  2. Re: Logical to Physical Address mapping, Physical to DIMM mapping

    On Oct 20, 6:03 pm, General Schvantzkopf
    wrote:

    > Is there a call to translate a virtual address to a physical address?


    > Is there a way to find the physical address to DIMM map?


    I think this is impossible in principle. Even if you lock the memory,
    that only guarantees it will stay resident, it does not guarantee that
    its physical address will remain constant.

    It may still be possible in practice. But I don't think so.

    DS


  3. Re: Logical to Physical Address mapping, Physical to DIMM mapping

    On Oct 20, 6:03 pm, General Schvantzkopf
    wrote:

    > Is there a call to translate a virtual address to a physical address?


    > Is there a way to find the physical address to DIMM map?


    I think this is impossible in principle. Even if you lock the memory,
    that only guarantees it will stay resident, it does not guarantee that
    its physical address will remain constant.

    It may still be possible in practice. But I don't think so.

    DS


  4. Re: Logical to Physical Address mapping, Physical to DIMM mapping

    General Schvantzkopf wrote:
    >
    >Is there a call to translate a virtual address to a physical address?


    A kernel driver can do this, using virt_to_phys. However, as David pointed
    out, as soon as you switch back to user mode the physical address can
    change.

    >Is there a way to find the physical address to DIMM map?
    >
    >I'd like to upgrade the memory test in sys_basher to call out a specific
    >DIMM.


    No. Remember that there is no promise that the memory is even in DIMMs at
    all.

    The system's BIOS has information about this, but it isn't visible.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  5. Re: Logical to Physical Address mapping, Physical to DIMM mapping

    General Schvantzkopf wrote:
    >
    >Is there a call to translate a virtual address to a physical address?


    A kernel driver can do this, using virt_to_phys. However, as David pointed
    out, as soon as you switch back to user mode the physical address can
    change.

    >Is there a way to find the physical address to DIMM map?
    >
    >I'd like to upgrade the memory test in sys_basher to call out a specific
    >DIMM.


    No. Remember that there is no promise that the memory is even in DIMMs at
    all.

    The system's BIOS has information about this, but it isn't visible.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  6. Logical to Physical Address mapping, Physical to DIMM mapping

    DS> I think this is impossible in principle. Even if you lock the
    DS> memory, that only guarantees it will stay resident, it
    DS> does not guarantee that its physical address will
    DS> remain constant.

    That depends from one's definition of "lock". Certainly, one doesn't
    have such guarantees from application mode APIs. However the point of
    pinning pages in kernel mode is to make them accessible to DMA and
    busmastering hardwares, which requires (for sane operation) that the
    physical addresses don't change whilst the pages are pinned.

    However, this has strayed from the original purpose behind the
    question, which was to print out a physical RAM chip location when an
    application's "memory testing" function discovered a failure. The
    issue here is not so much the impossibility of achieving the step as
    the idea that the overall goal is even the correct thing to be doing,
    in an application running on a virtual memory operating system, in the
    first place. Who is to say, for example, that the memory test didn't
    fail because a page-in operation corrupted the data as they passed
    through a buggy PCI-to-ATA bridge? How is it meaningful to blame the
    RAM chips for that? The original design is ill-conceived.

    This is one of the reasons that real memory testing utilities run
    directly on top of the machine firmware, without an intervening
    operating system. Microsoft's Windows Memory Diagnostic is a "pre-
    boot" application, for example. (The EFI version is by convention \efi
    \microsoft\boot\memtest.efi in an EFI System partition.) As is
    Memtest86.


  7. Logical to Physical Address mapping, Physical to DIMM mapping

    DS> I think this is impossible in principle. Even if you lock the
    DS> memory, that only guarantees it will stay resident, it
    DS> does not guarantee that its physical address will
    DS> remain constant.

    That depends from one's definition of "lock". Certainly, one doesn't
    have such guarantees from application mode APIs. However the point of
    pinning pages in kernel mode is to make them accessible to DMA and
    busmastering hardwares, which requires (for sane operation) that the
    physical addresses don't change whilst the pages are pinned.

    However, this has strayed from the original purpose behind the
    question, which was to print out a physical RAM chip location when an
    application's "memory testing" function discovered a failure. The
    issue here is not so much the impossibility of achieving the step as
    the idea that the overall goal is even the correct thing to be doing,
    in an application running on a virtual memory operating system, in the
    first place. Who is to say, for example, that the memory test didn't
    fail because a page-in operation corrupted the data as they passed
    through a buggy PCI-to-ATA bridge? How is it meaningful to blame the
    RAM chips for that? The original design is ill-conceived.

    This is one of the reasons that real memory testing utilities run
    directly on top of the machine firmware, without an intervening
    operating system. Microsoft's Windows Memory Diagnostic is a "pre-
    boot" application, for example. (The EFI version is by convention \efi
    \microsoft\boot\memtest.efi in an EFI System partition.) As is
    Memtest86.


+ Reply to Thread