mp_machdep.c (was Re: [Fwd: Re: Bug reports requested - acpi])

John Baldwin jhb at FreeBSD.org
Tue Sep 21 12:01:37 PDT 2004


On Tuesday 21 September 2004 12:27 pm, Roman Kurakin wrote:
> My solution works for current so I am going to commit it and MFC after
> a while. To be sure that I am not on the wrong way I need some
> reviewed/approved signs ;-) I also hope to get one (or more) tested signs.
>
> Patch I plan to commit following patch:
>
> Index: mp_machdep.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
> retrieving revision 1.238
> diff -u -r1.238 mp_machdep.c
> --- mp_machdep.c        1 Sep 2004 06:42:01 -0000       1.238
> +++ mp_machdep.c        21 Sep 2004 15:54:41 -0000
> @@ -743,10 +743,11 @@
>         u_int8_t *dst8;
>         u_int16_t *dst16;
>         u_int32_t *dst32;
> +       vm_offset_t va = (vm_offset_t) dst;
>
>         POSTCODE(INSTALL_AP_TRAMP_POST);
>
> -       pmap_kenter(boot_address + KERNBASE, boot_address);
> +       pmap_map(&va, boot_address, boot_address + size, 0);
>         for (x = 0; x < size; ++x)
>                 *dst++ = *src++;
>
> Any signs for(or against)?
>
> Thanks!
>
> PS. John: I am against of pmap_kenter/pmap_invalidate_XXX since we could
> get
> the same problem if we would use atomic functions instead of composite
> functions,
> which, I hope, will track all changes in the future.

pmap_foo() doesn't change much. :)  One reason I would prefer the 
kenter/invalidate is that we explicitly assume a single page for the boot 
code when we go to allocate an address for it, so I'd kind of like to keep it 
as an explicit assumption, but I'd be ok with just adding a KASSERT(size <= 
PAGE_SIZE, ("bewm"));  Also, I think your end va needs to be boot_address + 
size -1 so that if size == PAGE_SIZE you don't bogusly try to map the first 
page of Video RAM as read/write memory.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-current mailing list