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 > _at__at_ -743,10 +743,11 _at__at_ > 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.orgReceived on Tue Sep 21 2004 - 17:01:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:13 UTC