bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] i386: Omit pmap workaround on i486 or later.


From: Masanori Ogino
Subject: Re: [PATCH] i386: Omit pmap workaround on i486 or later.
Date: Fri, 8 Jul 2016 10:43:00 +0900

How about this patch?
Did I share this with you in a wrong way, or is it simply useless?

2016-06-18 22:04 GMT+09:00 Masanori Ogino <masanori.ogino@gmail.com>:
> As described in XXX comments, the workaround for memory mapping is
> implemented for 80386 and it is unnecessary on i486 or later.  Thus, it
> is safe to omit that if the kernel is built for the recent (1989~)
> processors.
>
> Fuhito Inagawa pointed out the problem to me.
>
> * i386/i386/trap.c (kernel_trap): Disable the workaround when the kernel
> is built for i[456]86.
> * i386/intel/pmap.c (pmap_protect, pmap_enter): Ditto.
> * i386/intel/read_fault.c: Define intel_read_fault if and only if it is
> necessary.
> ---
>  i386/i386/trap.c        | 2 ++
>  i386/intel/pmap.c       | 9 +++++----
>  i386/intel/read_fault.c | 2 ++
>  3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/i386/i386/trap.c b/i386/i386/trap.c
> index 6470504..77aa6db 100644
> --- a/i386/i386/trap.c
> +++ b/i386/i386/trap.c
> @@ -250,6 +250,7 @@ dump_ss(regs);
>                 }
>                 else
>  #endif /* MACH_KDB */
> +#if !(__486__ || __586__ || __686__)
>                 if ((code & T_PF_WRITE) == 0 &&
>                     result == KERN_PROTECTION_FAILURE)
>                 {
> @@ -261,6 +262,7 @@ dump_ss(regs);
>                     result = intel_read_fault(map,
>                                           trunc_page((vm_offset_t)subcode));
>                 }
> +#endif
>
>                 if (result == KERN_SUCCESS) {
>                     /*
> diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c
> index e362b45..9a3a7ac 100644
> --- a/i386/intel/pmap.c
> +++ b/i386/intel/pmap.c
> @@ -1711,17 +1711,17 @@ void pmap_protect(
>                 return;
>         }
>
> +#if !(__486__ || __586__ || __686__)
>         /*
>          * If write-protecting in the kernel pmap,
>          * remove the mappings; the i386 ignores
>          * the write-permission bit in kernel mode.
> -        *
> -        * XXX should be #if'd for i386
>          */
>         if (map == kernel_pmap) {
>             pmap_remove(map, s, e);
>             return;
>         }
> +#endif
>
>         SPLVM(spl);
>         simple_lock(&map->lock);
> @@ -1812,14 +1812,14 @@ if (pmap_debug) printf("pmap(%lx, %lx)\n", v, pa);
>         if (pmap == kernel_pmap && (v < kernel_virtual_start || v >= 
> kernel_virtual_end))
>                 panic("pmap_enter(%p, %p) falls in physical memory area!\n", 
> v, pa);
>  #endif
> +
> +#if !(__486__ || __586__ || __686__)
>         if (pmap == kernel_pmap && (prot & VM_PROT_WRITE) == 0
>             && !wired /* hack for io_wire */ ) {
>             /*
>              *  Because the 386 ignores write protection in kernel mode,
>              *  we cannot enter a read-only kernel mapping, and must
>              *  remove an existing mapping if changing it.
> -            *
> -            *  XXX should be #if'd for i386
>              */
>             PMAP_READ_LOCK(pmap, spl);
>
> @@ -1836,6 +1836,7 @@ if (pmap_debug) printf("pmap(%lx, %lx)\n", v, pa);
>             PMAP_READ_UNLOCK(pmap, spl);
>             return;
>         }
> +#endif
>
>         /*
>          *      Must allocate a new pvlist entry while we're unlocked;
> diff --git a/i386/intel/read_fault.c b/i386/intel/read_fault.c
> index 4b1edce..f28cbbc 100644
> --- a/i386/intel/read_fault.c
> +++ b/i386/intel/read_fault.c
> @@ -33,6 +33,7 @@
>
>  #include <kern/macros.h>
>
> +#if !(__486__ || __586__ || __686__)
>  /*
>   *     Expansion of vm_fault for read fault in kernel mode.
>   *     Must enter the mapping as writable, since the i386
> @@ -174,3 +175,4 @@ intel_read_fault(
>
>         return (KERN_SUCCESS);
>  }
> +#endif
> --
> 2.7.3
>



-- 
Masanori Ogino <masanori.ogino@gmail.com>
http://twitter.com/omasanori
http://gplus.to/omasanori



reply via email to

[Prev in Thread] Current Thread [Next in Thread]