[patch 00/11] PAT x86: PAT support for x86 - Kernel

This is a discussion on [patch 00/11] PAT x86: PAT support for x86 - Kernel ; This series is heavily derived from the PAT patchset by Eric Biederman and Andi Kleen. http://www.firstfloor.org/pub/ak/x86_64/pat/ This patchset is a followup of "PAT support for X86_64" http://www.ussg.iu.edu/hypermail/lin...12.1/2268.html Things changed from the above (Dec 13 2007) version: * PAT mappings now ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: [patch 00/11] PAT x86: PAT support for x86

  1. [patch 00/11] PAT x86: PAT support for x86

    This series is heavily derived from the PAT patchset by Eric Biederman and
    Andi Kleen.
    http://www.firstfloor.org/pub/ak/x86_64/pat/

    This patchset is a followup of "PAT support for X86_64"
    http://www.ussg.iu.edu/hypermail/lin...12.1/2268.html

    Things changed from the above (Dec 13 2007) version:
    * PAT mappings now used are - (0,WB) (1,WT) (2,WC) (3,UC).
    * Covers both i386 and x86_64.
    * Resolve the /sysfs issue by exporting wc and uc interfaces.
    * Piggyback PAT initialization on existing MTRR initialization as they
    have same setup rules.
    * Avoid early table allocation problem for x86_64 by doing the reserved
    region pruning later in the boot. Handle both memory identity mapping and
    kernel test mapping.
    * Handle fork() and /dev/mem mapping and unmapping cases.

    Patchset is against Ingo's x86 branch from 2 days ago. Will need some merging
    effort with Andi's CPA changes and few other changes like pgtable.h unification.

    Not mapping reserved region in identity map is a sort of big change that can
    potentially have side-effects on drivers (especially on x86_64), that
    assume entire address range is mapped in identity map and use __va to
    access reserved regions instead of ioremap/early_ioremap. We have
    changed few such common cases, but there can be more in /drivers land.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Suresh Siddha

    --
    --
    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/

  2. Re: [patch 11/11] PAT x86: Expose uc and wc interfaces in /sysfs vor pci_mmap_resource

    On Thu, Jan 10, 2008 at 10:48:51AM -0800, venkatesh.pallipadi@intel.com wrote:
    > New interfaces exported for uc and wc accesses. Apps has to change to use
    > these new interfaces.
    >
    > Signed-off-by: Venkatesh Pallipadi
    > Signed-off-by: Suresh Siddha


    Please update the documentation for this change, as well as adding
    something to Documentation/ABI/ for these new sysfs files.

    thanks,

    greg k-h
    --
    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/

  3. RE: [patch 11/11] PAT x86: Expose uc and wc interfaces in /sysfsvor pci_mmap_resource



    >-----Original Message-----
    >From: Greg KH [mailto:gregkh@suse.de]
    >Sent: Thursday, January 10, 2008 11:43 AM
    >To: Pallipadi, Venkatesh
    >Cc: ak@muc.de; ebiederm@xmission.com; rdreier@cisco.com;
    >torvalds@linux-foundation.org; airlied@skynet.ie;
    >davej@redhat.com; mingo@elte.hu; tglx@linutronix.de;
    >hpa@zytor.com; akpm@linux-foundation.org; arjan@infradead.org;
    >Barnes, Jesse; davem@davemloft.net;
    >linux-kernel@vger.kernel.org; Siddha, Suresh B
    >Subject: Re: [patch 11/11] PAT x86: Expose uc and wc
    >interfaces in /sysfsvor pci_mmap_resource
    >
    >On Thu, Jan 10, 2008 at 10:48:51AM -0800,
    >venkatesh.pallipadi@intel.com wrote:
    >> New interfaces exported for uc and wc accesses. Apps has to

    >change to use
    >> these new interfaces.
    >>
    >> Signed-off-by: Venkatesh Pallipadi
    >> Signed-off-by: Suresh Siddha

    >
    >Please update the documentation for this change, as well as adding
    >something to Documentation/ABI/ for these new sysfs files.
    >


    OK. Will do.

    Thanks,
    Venki
    --
    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/

  4. Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text



    On Thu, 10 Jan 2008, venkatesh.pallipadi@intel.com wrote:
    >
    > x86_64: Map only usable memory in identity map. All reserved memory maps to a
    > zero page.


    I don't mind this horribly per se, but why a zero page?

    Accessing that page without mapping it explicitly would be a bug with
    your change - if only because you'd get the wrong value!

    So why map it at all? The only thing mapping it can do is to hide bugs.

    Linus
    --
    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/

  5. RE: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text



    >-----Original Message-----
    >From: Linus Torvalds [mailto:torvalds@linux-foundation.org]
    >Sent: Thursday, January 10, 2008 1:05 PM
    >To: Pallipadi, Venkatesh
    >Cc: ak@muc.de; ebiederm@xmission.com; rdreier@cisco.com;
    >gregkh@suse.de; airlied@skynet.ie; davej@redhat.com;
    >mingo@elte.hu; tglx@linutronix.de; hpa@zytor.com;
    >akpm@linux-foundation.org; arjan@infradead.org; Barnes, Jesse;
    >davem@davemloft.net; linux-kernel@vger.kernel.org; Siddha, Suresh B
    >Subject: Re: [patch 02/11] PAT x86: Map only usable memory in
    >x86_64 identity map and kernel text
    >
    >
    >
    >On Thu, 10 Jan 2008, venkatesh.pallipadi@intel.com wrote:
    >>
    >> x86_64: Map only usable memory in identity map. All reserved

    >memory maps to a
    >> zero page.

    >
    >I don't mind this horribly per se, but why a zero page?
    >
    >Accessing that page without mapping it explicitly would be a bug with
    >your change - if only because you'd get the wrong value!
    >
    >So why map it at all? The only thing mapping it can do is to hide bugs.
    >


    Yes. I had those pages not mapped at all earlier. The reason I switched
    to zero page is to continue support cases like:
    BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
    BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
    BIOS-e820: 00000000000cc000 - 00000000000d0000 (reserved)
    BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
    BIOS-e820: 0000000000100000 - 00000000cff60000 (usable)

    In this case if some one does a dd of /dev/mem before they can read the
    contents of usable memory in 0x100000-0xcff60000 range. But, if I not
    map reserved regions, dd will stop after fist such hole. Even though
    this may not be a good usage model, I thought there may be apps
    depending on such things. Having said that, I do not like having dummy
    zero page there very much. So, if we do not see any regressions due to
    usages like above, I will be happy to remove mapping reserved regions
    altogether.

    Thanks,
    Venki
    --
    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/

  6. RE: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text



    On Thu, 10 Jan 2008, Pallipadi, Venkatesh wrote:
    >
    > Yes. I had those pages not mapped at all earlier. The reason I switched
    > to zero page is to continue support cases like:
    > BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
    > BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
    > BIOS-e820: 00000000000cc000 - 00000000000d0000 (reserved)
    > BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
    > BIOS-e820: 0000000000100000 - 00000000cff60000 (usable)
    >
    > In this case if some one does a dd of /dev/mem before they can read the
    > contents of usable memory in 0x100000-0xcff60000 range.


    Well, I think that /dev/mem should simply give them the right info. That's
    what people use /dev/mem for - doing things like reading BIOS images etc.

    So returning *either* a zero page *or* stopping at the first hole is both
    equally wrong.

    Linus
    --
    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/

  7. RE: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text



    >-----Original Message-----
    >From: Linus Torvalds [mailto:torvalds@linux-foundation.org]
    >Sent: Thursday, January 10, 2008 2:15 PM
    >To: Pallipadi, Venkatesh
    >Cc: ak@muc.de; ebiederm@xmission.com; rdreier@cisco.com;
    >gregkh@suse.de; airlied@skynet.ie; davej@redhat.com;
    >mingo@elte.hu; tglx@linutronix.de; akpm@linux-foundation.org;
    >arjan@infradead.org; Barnes, Jesse; davem@davemloft.net;
    >linux-kernel@vger.kernel.org; Siddha, Suresh B
    >Subject: RE: [patch 02/11] PAT x86: Map only usable memory in
    >x86_64 identity map and kernel text
    >
    >
    >
    >On Thu, 10 Jan 2008, Pallipadi, Venkatesh wrote:
    >>
    >> Yes. I had those pages not mapped at all earlier. The reason

    >I switched
    >> to zero page is to continue support cases like:
    >> BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
    >> BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
    >> BIOS-e820: 00000000000cc000 - 00000000000d0000 (reserved)
    >> BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
    >> BIOS-e820: 0000000000100000 - 00000000cff60000 (usable)
    >>
    >> In this case if some one does a dd of /dev/mem before they

    >can read the
    >> contents of usable memory in 0x100000-0xcff60000 range.

    >
    >Well, I think that /dev/mem should simply give them the right
    >info. That's
    >what people use /dev/mem for - doing things like reading BIOS
    >images etc.
    >
    >So returning *either* a zero page *or* stopping at the first
    >hole is both
    >equally wrong.
    >


    I was not fully clear in my earlier email. Mapping /dev/mem would still
    work with our changes. As they go through proper map interface. It is
    the dd of dev mem which does the read that has the problem. I was
    wondering of apps using dd.

    Thanks,
    Venki
    --
    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/

  8. Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text

    On Thu, 10 Jan 2008 14:15:25 PST, Linus Torvalds said:

    > Well, I think that /dev/mem should simply give them the right info. That's
    > what people use /dev/mem for - doing things like reading BIOS images etc.
    >
    > So returning *either* a zero page *or* stopping at the first hole is both
    > equally wrong.


    A case could be made that the /dev/mem driver should at *least* prohibit access
    to those memory ranges that the kernel already knows have (or might have)
    memory-mapped control registers with Bad Juju side-effects attached to them.

    Of course, a case could also be made that it should be permitted, because
    anybody who tries to read such memory addresses either (a) knows what they're
    doing or (b) is about to become an example of evolution in action...

    (Personally, I keep a copy of Arjan's "restrict devmem" patch from Fedora
    around, so I guess that says which camp I belong in, and the fact it's a Fedora
    patch and not mainstream says something too...)


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHhqFBcC3lWbTT17ARAo7iAJ477vaLijWqQCycYpUEYK jEQVwOlwCePEw7
    ePBn+L6JYmJjj014YYYF5Hw=
    =VlWe
    -----END PGP SIGNATURE-----


  9. Re: [patch 09/11] PAT x86: Add ioremap_wc support

    > >I don't think that's a good idea. Drivers should be able to
    > >detect this somehow.
    > >Handling UC mappings as WC will probably give very poor results.


    > It is the other way. ioremap_wc aliases to ioremap_nocache.
    > This was based on earlier feedback from Roland.


    > >From: Roland Dreier [mailto:rdreier@cisco.com]
    > >I think ioremap_wc() needs to be available on all archs for this to be
    > >really useful to drivers. It can be a fallback to ioremap_nocache()
    > >everywhere except 64-bit x86, but it's not nice for every driver that
    > >wants to use this to need an "#ifdef X86" or whatever.


    Yes... my basic point is simply that the kernel interfaces to this WC
    stuff must be available on all architectures, even if it's stubbed out
    on architectures that don't support write-combining or where it hasn't
    been implemented yet. I think the only sane way to stub it out is to
    fall back to uncached...

    It's not going to be useful if drivers need crazy #ifdefs to decide
    whether to use ioremap_wc(), pgprot_writecombine() or whatever. Just
    look at the mess in drm_io_prot() in drm_vm.c to see what I want to
    avoid.

    Just to be explicit, my interest in this is that I want to be able to
    merge the patch below and have the mlx4 driver still build and work on
    every arch that has PCI support:

    diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
    index d8287d9..5eac9c6 100644
    --- a/drivers/infiniband/hw/mlx4/main.c
    +++ b/drivers/infiniband/hw/mlx4/main.c
    @@ -381,8 +381,7 @@ static int mlx4_ib_mmap(struct ib_ucontext *context, struct vm_area_struct *vma)
    PAGE_SIZE, vma->vm_page_prot))
    return -EAGAIN;
    } else if (vma->vm_pgoff == 1 && dev->dev->caps.bf_reg_size != 0) {
    - /* FIXME want pgprot_writecombine() for BlueFlame pages */
    - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
    + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);

    if (io_remap_pfn_range(vma, vma->vm_start,
    to_mucontext(context)->uar.pfn +

    --
    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/

  10. Re: [patch 06/11] PAT x86: Refactoring i386 cpa


    * Andi Kleen wrote:

    > venkatesh.pallipadi@intel.com writes:
    >
    > > This makes 32 bit cpa similar to x86_64 and makes it easier for
    > > following PAT patches.

    >
    > Please don't do this -- that would be a nightmare merging with my CPA
    > series.
    >
    > This means adding the _addr() entry point is ok (although it should
    > not be needed on i386 because it doesn't do the end_pfn_mapped trick),
    > but not a wide scale refactoring.


    yeah, i think we can unify after your cpa fixes and enhancements just
    fine - as you did the changes symmetrically for 32-bit and 64-bit.
    Hopefully i'll be able to upload the current PAT stuff in x86.git later
    today so that you can merge the cpa items ontop of it.

    Ingo
    --
    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/

  11. Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text

    On Thu, Jan 10, 2008 at 05:50:41PM -0500, Valdis.Kletnieks@vt.edu wrote:

    > (Personally, I keep a copy of Arjan's "restrict devmem" patch from Fedora
    > around, so I guess that says which camp I belong in, and the fact it's a Fedora
    > patch and not mainstream says something too...)


    The way that patch is right now (and has been for some time) is kind of nasty,
    and could use cleaning up. I made a half-assed attempt at improving it
    a little over xmas, but it could rewriting from scratch.
    That's the only reason I never bothered pushing it (and I assume, the reason
    that Arjan didn't push it when he wrote the original).

    Dave

    --
    http://www.codemonkey.org.uk
    --
    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/

  12. Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text


    * Dave Jones wrote:

    > On Thu, Jan 10, 2008 at 05:50:41PM -0500, Valdis.Kletnieks@vt.edu wrote:
    >
    > > (Personally, I keep a copy of Arjan's "restrict devmem" patch from Fedora
    > > around, so I guess that says which camp I belong in, and the fact it's a Fedora
    > > patch and not mainstream says something too...)

    >
    > The way that patch is right now (and has been for some time) is kind
    > of nasty, and could use cleaning up. I made a half-assed attempt at
    > improving it a little over xmas, but it could rewriting from scratch.
    > That's the only reason I never bothered pushing it (and I assume, the
    > reason that Arjan didn't push it when he wrote the original).


    could someone please send it into this thread so that we can have a go
    at integrating it into x86.git?

    Ingo
    --
    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/

+ Reply to Thread