On Sat, Apr 21, 2012 at 3:06 AM, Blue Swirl <blauwir...@gmail.com> wrote: > On Fri, Apr 20, 2012 at 04:25, Xin Tong <xerox.time.t...@gmail.com> wrote: >> On Thu, Apr 19, 2012 at 6:56 PM, Xin Tong <xerox.time.t...@gmail.com> wrote: >>> On Thu, Apr 19, 2012 at 1:03 PM, Blue Swirl <blauwir...@gmail.com> wrote: >>>> On Thu, Apr 19, 2012 at 01:55, Xin Tong <xerox.time.t...@gmail.com> wrote: >>>>> but should not the address be within 1 - 4G-1 even with PAE. is not >>>>> the PAE just using 64bits addresses as supposed to 32 bit ? what does >>>>> the physical address bigger than 4G mean ? is not the physical >>>>> address starting from 0 from the prospective of the processor ? >>>> >>>> With 64 bit physical addresses the range can be 0 to >>>> 0xffffffffffffffff. Perhaps you need to read more background material, >>>> for example Intel or AMD processor manuals are quite extensive. >>>> >>>> Please don't top post, it breaks the natural reply order. >>>> >>>>> >>>>> Xin >>>>> >>>>> >>>>> On Wed, Apr 18, 2012 at 4:03 PM, Blue Swirl <blauwir...@gmail.com> wrote: >>>>>> On Wed, Apr 18, 2012 at 01:28, Xin Tong <xerox.time.t...@gmail.com> >>>>>> wrote: >>>>>>> I am reading how qemu refill TLB working. >>>>>>> >>>>>>> target-i386/helper.c >>>>>>> >>>>>>> pte = pte & env->a20_mask; >>>>>>> >>>>>>> /* Even if 4MB pages, we map only one 4KB page in the cache to >>>>>>> avoid filling it too fast */ >>>>>>> page_offset = (addr & TARGET_PAGE_MASK) & (page_size - 1); >>>>>>> paddr = (pte & TARGET_PAGE_MASK) + page_offset; >>>>>>> vaddr = virt_addr + page_offset; >>>>>>> >>>>>>> >>>>>>> How can the paddr be bigger than 4G even though i gave the machine >>>>>>> 4096 MB of memory ( i.e. qemu -m 4096 ...). should not paddr be within >>>>>>> 0 - 4G-1 ? >>>>>> >>>>>> No. There's PAE and the same code is used by both i386 and x86_64. >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Xin >>>>>>> >>> >>> In QEMU, the guest memory is emulated by allocating a contiguous chunk >>> of memory from the host machine. is the emulated memory contiguous >>> with respect to the host memory. i.e. memory address 0x0 of guest maps >>> to 0x760000000 in host and memory address 0x5000 maps to 0x760005000 >>> in host, etc. >>> >>> Also, what would be a good way to find this offset ? qemu_get_ram_ptr(0) ? >>> >>> Xin >> >> Ok. this is what i want. when qemu starts, it mmaps a chunk of memory >> from the host as the emulated guest memory. If I am emulating more >> than one cpu, given a guest physical page, i want to know which cpu >> TLB has an entry that will translate into the guest physical page. >> >> >> the addr_read/addr_write + addend will give host virtual address. i >> want to build a core map keeping track of which TLB entries (could be >> in multiple emulated cpus) translates to the host page. > > The TLB is only a cache for the translations, the complete virtual to > physical mapping information is contained only in the guest MMU page > tables. On some non-x86 architectures even that is not enough if the > MMU is also TLB based, in that case the full maps can be guest OS > kernel internal structures. Maybe SVM on x86 could also makes things > less straightforward. > >> >> Thanks >> >> Xin
I know this. what i am currently doing is that i take a guest virtual address in the soft TLB. add the addend. then i should get a host virtual address. Then i substract it from the qemu_get_ram_ptr(0) . I sometimes end up with a negative address as shown in the code below.. env->tlb[mmu_idx][current_index].addr_read + env->tlb[mmu_idx][current_index].addend - qemu_get_ram_ptr(0) < 0 env->tlb[mmu_idx][current_index].addr_read is not -1 in this case. How can this happen ? This is all done on emulating x86_64 on x86_64. Thanks Xin
