All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Superymk <superymkxen@hotmail.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Chu Rui <ruichu@gmail.com>
Subject: Re: How EPT translates an X86_32 guest physical address?
Date: Wed, 17 Nov 2010 10:32:54 +0000	[thread overview]
Message-ID: <4CE3AF56.9030503@eu.citrix.com> (raw)
In-Reply-To: <BLU0-SMTP204EE298B6F47B9A3CB2B67A2380@phx.gbl>

The exact implementation of 32-bit mode on a 64-bit capable processor is 
something only the engineers at Intel know; but logically yes, whatever 
it does is equivalent to first zero-extending the 32-bit value.

You can see the software implementation in 
xen/arch/x86/mm/hap/p2m-ept.c:ept_get_entry().  That function is passed 
an unsigned long, which in 64-bit mode is 64 bits, so at that point any 
hardware address would have been zero-extended.

  -George

On 17/11/10 10:20, Superymk wrote:
> So your point is the guest CR3 needs to be "extended" to 64 bits with
> zeroes first, if it is a 32-bit guest. right?
>
> On 11/17/2010 6:11 PM, George Dunlap wrote:
>> If you're in 64-bit mode and the hardware had a TLB miss for virtual
>> address of 0xdeadb000, how would the hardware walk the pagetables?
>> There are 20 bits for the virtual frame number, but each page-table
>> entry has 9 bits.
>>
>> It's the exact same situation if the guest cr3 was set to 0xdeadb000.
>> The indexes into the higher-level tables would simply be zero.
>>
>>    -George
>>
>> On Wed, Nov 17, 2010 at 9:40 AM, Superymk<superymkxen@hotmail.com>   wrote:
>>> Your figure points out the exactly EPT translation mechanism for an X64
>>> guest.
>>>
>>> In the face of an X86_32 guest, how can EPT find the right EPML4 entry when
>>> translating CR3's pfn value into the right mfn value? There are 20 bits for
>>> indexing in total, while each level of EPT paging structure uses only 9 bits
>>> for indexing.
>>>
>>>
>>> On 11/17/2010 5:20 PM, Chu Rui wrote:
>>>
>>> Maybe this figure depicts the process...
>>>
>>> The original URL is http://software.intel.com/file/25040
>>>
>>> 2010/11/17 Superymk<superymkxen@hotmail.com>
>>>> Hi all,
>>>>
>>>> Can some one please tell me how EPT translates an X86_32 guest physical
>>>> address? I have read the Intel's manual, but it seems there is no discussion
>>>> about this condition.
>>>>
>>>> My concern is that, the guest CR3 pfn can be considered as being
>>>> constituted by two 10 bits indexers for an X86_32 virtual machine. However,
>>>> the EPT paging structures is similar with the page tables used on X86_64
>>>> platform. which has four 9 bits indexers in its address layout. In addition,
>>>> each EPT entry is 64 bits long. Hence, a 4K page can hold at most 512
>>>> entries. So, if the guest CR3's pfn is 0xfffff (an X86_32 virtual machine)
>>>> and I get a valid EPTP, how EPT will perform the translation?
>>>>
>>>> Thanks,
>>>> Superymk
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>

  reply	other threads:[~2010-11-17 10:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17  8:39 How EPT translates an X86_32 guest physical address? Superymk
2010-11-17  9:20 ` Chu Rui
2010-11-17  9:40   ` Superymk
2010-11-17 10:11     ` George Dunlap
2010-11-17 10:20       ` Superymk
2010-11-17 10:32         ` George Dunlap [this message]
2010-11-17 10:42           ` Superymk
2010-11-17 11:23             ` Chu Rui
2010-11-17 10:49           ` Ian Campbell
2010-11-17 11:26             ` Chu Rui
2010-11-17 11:47               ` Ian Campbell
2010-11-17 11:57                 ` Chu Rui
2010-11-17 12:02                   ` Keir Fraser
2010-11-18  6:18                   ` Haitao Shan
2010-11-17 11:53               ` Superymk
2010-11-21 10:11                 ` Superymk
2010-11-21 10:22                   ` Superymk
2010-11-22  6:49                   ` Haitao Shan
2010-11-22  7:42                     ` Superymk
2010-11-22  8:37                     ` Superymk
2010-11-23  1:05                       ` Haitao Shan
2010-11-23  4:41                         ` Superymk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CE3AF56.9030503@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Xen-devel@lists.xensource.com \
    --cc=ruichu@gmail.com \
    --cc=superymkxen@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.