<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <tt>> crash> rd -u 0x400000</tt> <tt>> rd: invalid user virtual address: 400000 type: "64-bit UVADDR"</tt><tt></tt> <tt>Ah, damn it -- it would also be printed later on in</tt> <tt>readmem() if uvtop() fails:</tt><tt></tt> <tt> while (size > 0) {</tt> <tt> switch (memtype)</tt> <tt> {</tt> <tt> case UVADDR:</tt> <tt> if (!uvtop(CURRENT_CONTEXT(), addr, &paddr, 0)) {</tt> <tt> if (PRINT_ERROR_MESSAGE)</tt> <tt> error(INFO, INVALID_UVADDR, addr, type);</tt> <tt> goto readmem_error;</tt> <tt> }</tt> <tt> break;</tt><tt></tt> <tt>That's probably where it's happening...</tt><tt></tt> <tt>I would guess that x86_64_uvtop() needs to immediately</tt> <tt>recognize if the new VM scheme is in place, and if so</tt> <tt>it should veer off to a new "x86_64_uvtop_lev4()" routine.</tt><tt></tt> <tt>We definitely want to keep the current one untouched, while</tt> <tt>the new one must need a 4th layer of page table translation.</tt> <tt>Note that x86_64_kvtop() has the extra FILL_PML4() stuff</tt> <tt>before the 3-level breakdown -- I guess that's why vmalloc</tt> <tt>addresses still translate. But there must be another layer</tt> <tt>user virtual addresses need to go through.</tt><tt></tt> <tt>Dave</tt></html>