qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qemu physical address


From: Xin Tong
Subject: Re: [Qemu-devel] qemu physical address
Date: Sat, 21 Apr 2012 16:54:05 -0400

On Sat, Apr 21, 2012 at 3:06 AM, Blue Swirl <address@hidden> wrote:
> On Fri, Apr 20, 2012 at 04:25, Xin Tong <address@hidden> wrote:
>> On Thu, Apr 19, 2012 at 6:56 PM, Xin Tong <address@hidden> wrote:
>>> On Thu, Apr 19, 2012 at 1:03 PM, Blue Swirl <address@hidden> wrote:
>>>> On Thu, Apr 19, 2012 at 01:55, Xin Tong <address@hidden> 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 <address@hidden> wrote:
>>>>>> On Wed, Apr 18, 2012 at 01:28, Xin Tong <address@hidden> 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



reply via email to

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