How EPT translates an X86_32 guest physical address?

How EPT translates an X86_32 guest physical address?

[Superymk]

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

Re: How EPT translates an X86_32 guest physical address?

[Chu Rui]

[-- Attachment #1.1: Type: text/plain, Size: 1024 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 1517 bytes --]

[-- Attachment #2: ept.jpg --]
[-- Type: image/jpeg, Size: 146887 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

[-- Attachment #1.1: Type: text/plain, Size: 1549 bytes --]

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 
> <mailto: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 <mailto:Xen-devel@lists.xensource.com>
>     http://lists.xensource.com/xen-devel
>
>


[-- Attachment #1.2: Type: text/html, Size: 2778 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[George Dunlap]

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
>
>

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

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
>>
>>
>

Re: How EPT translates an X86_32 guest physical address?

[George Dunlap]

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
>>>
>>>
>>
>

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

Thanks a lot, George. Also thanks for Chu's material.

On 11/17/2010 6:32 PM, George Dunlap wrote:
> 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
>>>>
>>>>
>>>
>>
>
>
>

Re: How EPT translates an X86_32 guest physical address?

[Chu Rui]

[-- Attachment #1.1: Type: text/plain, Size: 3379 bytes --]

Also thanks to George!  I am just reading p2m-ept.c three hours ago.  As a
newbie, it is a hard work for me... wish I could get your kind help later.
2010/11/17 Superymk <superymkxen@hotmail.com>

> Thanks a lot, George. Also thanks for Chu's material.
>
>
> On 11/17/2010 6:32 PM, George Dunlap wrote:
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 4598 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[Ian Campbell]

On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
> 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.

Even on x86_32 physical addresses are >32 bit (think PAE). cr3 is a
physical address, even if the register which exposes it happens to be
limited to 32 bits. cr3 has probably already been expanded to a full
physical address by the time EPT sees it and I don't think there's any
difference between 32 and 64 bit (at least in this aspect) in how EPT
handles the translation from physical address to machine address.

Ian.

Re: How EPT translates an X86_32 guest physical address?

[Chu Rui]

[-- Attachment #1.1: Type: text/plain, Size: 977 bytes --]

Okay, in my mind, the hardware has only one work mode, 32bit or 64bit. Thus
the 32bit guest address will be extended under the 64bit host.
But what will happen for a 64bit guest under a 32bit host :-)

2010/11/17 Ian Campbell <Ian.Campbell@citrix.com>

> On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
> > 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.
>
> Even on x86_32 physical addresses are >32 bit (think PAE). cr3 is a
> physical address, even if the register which exposes it happens to be
> limited to 32 bits. cr3 has probably already been expanded to a full
> physical address by the time EPT sees it and I don't think there's any
> difference between 32 and 64 bit (at least in this aspect) in how EPT
> handles the translation from physical address to machine address.
>
> Ian.
>
>

[-- Attachment #1.2: Type: text/html, Size: 1340 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[Ian Campbell]

On Wed, 2010-11-17 at 11:26 +0000, Chu Rui wrote:
> Okay, in my mind, the hardware has only one work mode, 32bit or 64bit.
> Thus the 32bit guest address will be extended under the 64bit host.
> But what will happen for a 64bit guest under a 32bit host :-)

You appear to be confusing virtual address size, which is 32 or 64 bit
depending on mode, with phsyical address size, which depends on the
particular CPU model etc and not the mode it is running in. 

CPUs these days typically support physical address sizes of something
like 44 or 46 bits, even if they are running in 64 bit mode.

Ian.

> 
> 
> 2010/11/17 Ian Campbell <Ian.Campbell@citrix.com>
>         On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>         > 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.
>         
>         
>         Even on x86_32 physical addresses are >32 bit (think PAE). cr3
>         is a
>         physical address, even if the register which exposes it
>         happens to be
>         limited to 32 bits. cr3 has probably already been expanded to
>         a full
>         physical address by the time EPT sees it and I don't think
>         there's any
>         difference between 32 and 64 bit (at least in this aspect) in
>         how EPT
>         handles the translation from physical address to machine
>         address.
>         
>         Ian.
>         
> 

Re: How EPT translates an X86_32 guest physical address?

[Chu Rui]

[-- Attachment #1.1: Type: text/plain, Size: 1913 bytes --]

Sorry, perhaps I am confused. If the VMM works on the tranditional protect
mode with 2-level addressing, what will happen when the guest "thinks" it is
working in the x86-64 mode with 4-level addressing?



2010/11/17 Ian Campbell <Ian.Campbell@eu.citrix.com>

> On Wed, 2010-11-17 at 11:26 +0000, Chu Rui wrote:
> > Okay, in my mind, the hardware has only one work mode, 32bit or 64bit.
> > Thus the 32bit guest address will be extended under the 64bit host.
> > But what will happen for a 64bit guest under a 32bit host :-)
>
> You appear to be confusing virtual address size, which is 32 or 64 bit
> depending on mode, with phsyical address size, which depends on the
> particular CPU model etc and not the mode it is running in.
>
> CPUs these days typically support physical address sizes of something
> like 44 or 46 bits, even if they are running in 64 bit mode.
>
> Ian.
>
> >
> >
> > 2010/11/17 Ian Campbell <Ian.Campbell@citrix.com>
> >         On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
> >         > 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.
> >
> >
> >         Even on x86_32 physical addresses are >32 bit (think PAE). cr3
> >         is a
> >         physical address, even if the register which exposes it
> >         happens to be
> >         limited to 32 bits. cr3 has probably already been expanded to
> >         a full
> >         physical address by the time EPT sees it and I don't think
> >         there's any
> >         difference between 32 and 64 bit (at least in this aspect) in
> >         how EPT
> >         handles the translation from physical address to machine
> >         address.
> >
> >         Ian.
> >
> >
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 2537 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[Keir Fraser]

32-bit hypervisor does not support 64-bit guests.


On 17/11/2010 11:57, "Chu Rui" <ruichu@gmail.com> wrote:

> Sorry, perhaps I am confused. If the VMM works on the tranditional protect
> mode with 2-level addressing, what will happen when the guest "thinks" it is
> working in the x86-64 mode with 4-level addressing?
> 
> 
>  
> 2010/11/17 Ian Campbell <Ian.Campbell@eu.citrix.com>
>> On Wed, 2010-11-17 at 11:26 +0000, Chu Rui wrote:
>>> Okay, in my mind, the hardware has only one work mode, 32bit or 64bit.
>>> Thus the 32bit guest address will be extended under the 64bit host.
>>> But what will happen for a 64bit guest under a 32bit host :-)
>> 
>> You appear to be confusing virtual address size, which is 32 or 64 bit
>> depending on mode, with phsyical address size, which depends on the
>> particular CPU model etc and not the mode it is running in.
>> 
>> CPUs these days typically support physical address sizes of something
>> like 44 or 46 bits, even if they are running in 64 bit mode.
>> 
>> Ian.
>> 
>>> 
>>> 
>>> 2010/11/17 Ian Campbell <Ian.Campbell@citrix.com>
>>>         On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>>>         > 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.
>>> 
>>> 
>>>         Even on x86_32 physical addresses are >32 bit (think PAE). cr3
>>>         is a
>>>         physical address, even if the register which exposes it
>>>         happens to be
>>>         limited to 32 bits. cr3 has probably already been expanded to
>>>         a full
>>>         physical address by the time EPT sees it and I don't think
>>>         there's any
>>>         difference between 32 and 64 bit (at least in this aspect) in
>>>         how EPT
>>>         handles the translation from physical address to machine
>>>         address.
>>> 
>>>         Ian.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[Haitao Shan]

I think you get many processor features/architectures messed. I would
suggest you read SDM (especially 3A and 3B) before you try to
understand how the code utilize that piece of HW.

In this question particular, the paging mode which host (in your case,
VMM) is running on has nothing to do with the one guest is using.

We have seen 32bit hypervisors that supports 64-bit guests. But in
terms of how EPT translation works, there is no difference compared
with a 64bit-on-64bit.

Shan Haitao

2010/11/17 Chu Rui <ruichu@gmail.com>:
> Sorry, perhaps I am confused. If the VMM works on the tranditional protect
> mode with 2-level addressing, what will happen when the guest "thinks" it is
> working in the x86-64 mode with 4-level addressing?
>
>
> 2010/11/17 Ian Campbell <Ian.Campbell@eu.citrix.com>
>>
>> On Wed, 2010-11-17 at 11:26 +0000, Chu Rui wrote:
>> > Okay, in my mind, the hardware has only one work mode, 32bit or 64bit.
>> > Thus the 32bit guest address will be extended under the 64bit host.
>> > But what will happen for a 64bit guest under a 32bit host :-)
>>
>> You appear to be confusing virtual address size, which is 32 or 64 bit
>> depending on mode, with phsyical address size, which depends on the
>> particular CPU model etc and not the mode it is running in.
>>
>> CPUs these days typically support physical address sizes of something
>> like 44 or 46 bits, even if they are running in 64 bit mode.
>>
>> Ian.
>>
>> >
>> >
>> > 2010/11/17 Ian Campbell <Ian.Campbell@citrix.com>
>> >         On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>> >         > 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.
>> >
>> >
>> >         Even on x86_32 physical addresses are >32 bit (think PAE). cr3
>> >         is a
>> >         physical address, even if the register which exposes it
>> >         happens to be
>> >         limited to 32 bits. cr3 has probably already been expanded to
>> >         a full
>> >         physical address by the time EPT sees it and I don't think
>> >         there's any
>> >         difference between 32 and 64 bit (at least in this aspect) in
>> >         how EPT
>> >         handles the translation from physical address to machine
>> >         address.
>> >
>> >         Ian.
>> >
>> >
>>
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

[-- Attachment #1.1: Type: text/plain, Size: 1513 bytes --]

Thanks for Ian's answer. it comes to a more general scenario.

Hi Chu, EPT entry is 64 bit long, regardless the hypervisor is on x86_32 
platform or x86_64 platform. So there is no difference for the 
hypervisor to use EPT on these two platforms.

On 11/17/2010 7:26 PM, Chu Rui wrote:
> Okay, in my mind, the hardware has only one work mode, 32bit or 64bit. 
> Thus the 32bit guest address will be extended under the 64bit host.
> But what will happen for a 64bit guest under a 32bit host :-)
>
> 2010/11/17 Ian Campbell <Ian.Campbell@citrix.com 
> <mailto:Ian.Campbell@citrix.com>>
>
>     On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>     > 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.
>
>     Even on x86_32 physical addresses are >32 bit (think PAE). cr3 is a
>     physical address, even if the register which exposes it happens to be
>     limited to 32 bits. cr3 has probably already been expanded to a full
>     physical address by the time EPT sees it and I don't think there's any
>     difference between 32 and 64 bit (at least in this aspect) in how EPT
>     handles the translation from physical address to machine address.
>
>     Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 2861 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

[-- Attachment #1.1: Type: text/plain, Size: 3179 bytes --]

Hi all,

I just implement the EPT support in my hypervisor (Very similar to 
Newbluepill). My new problem is irrelevant with Xen.
It's just about how to debug VTx implementation in drivers.

Here is the story. First, I implement a driver support partial VTx, and 
it works very well. Then I implement EPT to identically map gfn to mfn 
from 0x0 to 0xfffff. I suppose it should be OK. But the result is the 
Windows OS hangs (No reboot, No BSOD) when executing VMLAUNCH instruction.

And my problem is that, the windbg just shows "debuggee is running" when 
the debuggee Windows OS hangs, even if I insert "ud2" instruction before 
the next statement, #VMEXIT handler and the first instruction in 
non-root mode. VMLAUNCH should not make this happen according to Intel's 
manual 2B. Everything is OK if I set "enable ept" to be 0 or clear the 
"EPT pointer" field in VMCS. Can someone explain why this happens and 
what should I do to continue debugging?

Both the hypervisor and the Windows OS is on x86_32 platform. I use 
windbg to debug the target machine via serial port.

Some debug information: EPT pointer is 0x9ba801e, (pfn:0x9ba8, 
flag:0x1e, I have double checked this) PML4[0] = 0x00000000_09cd8007, 
PDPT[0] = 0x00000000_09cf3007, PD[0] = 0x00000000_09cf2007, PT[0] = 
0x00000000_00000077. Other entries of the same scheme with different values.

The debuggee is Intel i5 650, multi-core disabled.

Thanks,
Miao

On 11/17/2010 7:53 PM, Superymk wrote:
> Thanks for Ian's answer. it comes to a more general scenario.
>
> Hi Chu, EPT entry is 64 bit long, regardless the hypervisor is on 
> x86_32 platform or x86_64 platform. So there is no difference for the 
> hypervisor to use EPT on these two platforms.
>
> On 11/17/2010 7:26 PM, Chu Rui wrote:
>> Okay, in my mind, the hardware has only one work mode, 32bit or 
>> 64bit. Thus the 32bit guest address will be extended under the 64bit 
>> host.
>> But what will happen for a 64bit guest under a 32bit host :-)
>>
>> 2010/11/17 Ian Campbell <Ian.Campbell@citrix.com 
>> <mailto:Ian.Campbell@citrix.com>>
>>
>>     On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>>     > 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.
>>
>>     Even on x86_32 physical addresses are >32 bit (think PAE). cr3 is a
>>     physical address, even if the register which exposes it happens to be
>>     limited to 32 bits. cr3 has probably already been expanded to a full
>>     physical address by the time EPT sees it and I don't think
>>     there's any
>>     difference between 32 and 64 bit (at least in this aspect) in how EPT
>>     handles the translation from physical address to machine address.
>>
>>     Ian.
>>
>>
>>
>> _______________________________________________
>> 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


[-- Attachment #1.2: Type: text/html, Size: 5326 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

[-- Attachment #1.1: Type: text/plain, Size: 3596 bytes --]

By the way, I noticed that Xen has the same flag in "EPT pointer" field, 
but Xen works well with EPT.

On 11/21/2010 6:11 PM, Superymk wrote:
> Hi all,
>
> I just implement the EPT support in my hypervisor (Very similar to 
> Newbluepill). My new problem is irrelevant with Xen.
> It's just about how to debug VTx implementation in drivers.
>
> Here is the story. First, I implement a driver support partial VTx, 
> and it works very well. Then I implement EPT to identically map gfn to 
> mfn from 0x0 to 0xfffff. I suppose it should be OK. But the result is 
> the Windows OS hangs (No reboot, No BSOD) when executing VMLAUNCH 
> instruction.
>
> And my problem is that, the windbg just shows "debuggee is running" 
> when the debuggee Windows OS hangs, even if I insert "ud2" instruction 
> before the next statement, #VMEXIT handler and the first instruction 
> in non-root mode. VMLAUNCH should not make this happen according to 
> Intel's manual 2B. Everything is OK if I set "enable ept" to be 0 or 
> clear the "EPT pointer" field in VMCS. Can someone explain why this 
> happens and what should I do to continue debugging?
>
> Both the hypervisor and the Windows OS is on x86_32 platform. I use 
> windbg to debug the target machine via serial port.
>
> Some debug information: EPT pointer is 0x9ba801e, (pfn:0x9ba8, 
> flag:0x1e, I have double checked this) PML4[0] = 0x00000000_09cd8007, 
> PDPT[0] = 0x00000000_09cf3007, PD[0] = 0x00000000_09cf2007, PT[0] = 
> 0x00000000_00000077. Other entries of the same scheme with different 
> values.
>
> The debuggee is Intel i5 650, multi-core disabled.
>
> Thanks,
> Miao
>
> On 11/17/2010 7:53 PM, Superymk wrote:
>> Thanks for Ian's answer. it comes to a more general scenario.
>>
>> Hi Chu, EPT entry is 64 bit long, regardless the hypervisor is on 
>> x86_32 platform or x86_64 platform. So there is no difference for the 
>> hypervisor to use EPT on these two platforms.
>>
>> On 11/17/2010 7:26 PM, Chu Rui wrote:
>>> Okay, in my mind, the hardware has only one work mode, 32bit or 
>>> 64bit. Thus the 32bit guest address will be extended under the 64bit 
>>> host.
>>> But what will happen for a 64bit guest under a 32bit host :-)
>>>
>>> 2010/11/17 Ian Campbell <Ian.Campbell@citrix.com 
>>> <mailto:Ian.Campbell@citrix.com>>
>>>
>>>     On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>>>     > 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.
>>>
>>>     Even on x86_32 physical addresses are >32 bit (think PAE). cr3 is a
>>>     physical address, even if the register which exposes it happens
>>>     to be
>>>     limited to 32 bits. cr3 has probably already been expanded to a full
>>>     physical address by the time EPT sees it and I don't think
>>>     there's any
>>>     difference between 32 and 64 bit (at least in this aspect) in
>>>     how EPT
>>>     handles the translation from physical address to machine address.
>>>
>>>     Ian.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 6334 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: How EPT translates an X86_32 guest physical address?

[Haitao Shan]

One difference between EPT-backed 1:1 mapping and direct 1:1 mapping
(I suppose that you don't use shadow page table) is that MTRRs are
ignored when EPT is in effect.
Do you set up EPT memory type correctly? Especially Windows is likely
to access MMIO space below 1M.

Shan Haitao

2010/11/21 Superymk <superymkxen@hotmail.com>:
> Hi all,
>
> I just implement the EPT support in my hypervisor (Very similar to
> Newbluepill). My new problem is irrelevant with Xen.
> It's just about how to debug VTx implementation in drivers.
>
> Here is the story. First, I implement a driver support partial VTx, and it
> works very well. Then I implement EPT to identically map gfn to mfn from 0x0
> to 0xfffff. I suppose it should be OK. But the result is the Windows OS
> hangs (No reboot, No BSOD) when executing VMLAUNCH instruction.
>
> And my problem is that, the windbg just shows "debuggee is running" when the
> debuggee Windows OS hangs, even if I insert "ud2" instruction before the
> next statement, #VMEXIT handler and the first instruction in non-root mode.
> VMLAUNCH should not make this happen according to Intel's manual 2B.
> Everything is OK if I set "enable ept" to be 0 or clear the "EPT pointer"
> field in VMCS. Can someone explain why this happens and what should I do to
> continue debugging?
>
> Both the hypervisor and the Windows OS is on x86_32 platform. I use windbg
> to debug the target machine via serial port.
>
> Some debug information: EPT pointer is 0x9ba801e, (pfn:0x9ba8, flag:0x1e, I
> have double checked this) PML4[0] = 0x00000000_09cd8007, PDPT[0] =
> 0x00000000_09cf3007, PD[0] = 0x00000000_09cf2007, PT[0] =
> 0x00000000_00000077. Other entries of the same scheme with different values.
>
> The debuggee is Intel i5 650, multi-core disabled.
>
> Thanks,
> Miao
>
> On 11/17/2010 7:53 PM, Superymk wrote:
>
> Thanks for Ian's answer. it comes to a more general scenario.
>
> Hi Chu, EPT entry is 64 bit long, regardless the hypervisor is on x86_32
> platform or x86_64 platform. So there is no difference for the hypervisor to
> use EPT on these two platforms.
>
> On 11/17/2010 7:26 PM, Chu Rui wrote:
>
> Okay, in my mind, the hardware has only one work mode, 32bit or 64bit. Thus
> the 32bit guest address will be extended under the 64bit host.
> But what will happen for a 64bit guest under a 32bit host :-)
>
> 2010/11/17 Ian Campbell <Ian.Campbell@citrix.com>
>>
>> On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>> > 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.
>>
>> Even on x86_32 physical addresses are >32 bit (think PAE). cr3 is a
>> physical address, even if the register which exposes it happens to be
>> limited to 32 bits. cr3 has probably already been expanded to a full
>> physical address by the time EPT sees it and I don't think there's any
>> difference between 32 and 64 bit (at least in this aspect) in how EPT
>> handles the translation from physical address to machine address.
>>
>> Ian.
>>
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

Thanks for your answer. I don't use SPT at current. In EPT, the memory 
type I use in the last level page table is WB, the same in EPT pointer.

On 11/22/2010 2:49 PM, Haitao Shan wrote:
> One difference between EPT-backed 1:1 mapping and direct 1:1 mapping
> (I suppose that you don't use shadow page table) is that MTRRs are
> ignored when EPT is in effect.
> Do you set up EPT memory type correctly? Especially Windows is likely
> to access MMIO space below 1M.
>
> Shan Haitao
>
> 2010/11/21 Superymk<superymkxen@hotmail.com>:
>> Hi all,
>>
>> I just implement the EPT support in my hypervisor (Very similar to
>> Newbluepill). My new problem is irrelevant with Xen.
>> It's just about how to debug VTx implementation in drivers.
>>
>> Here is the story. First, I implement a driver support partial VTx, and it
>> works very well. Then I implement EPT to identically map gfn to mfn from 0x0
>> to 0xfffff. I suppose it should be OK. But the result is the Windows OS
>> hangs (No reboot, No BSOD) when executing VMLAUNCH instruction.
>>
>> And my problem is that, the windbg just shows "debuggee is running" when the
>> debuggee Windows OS hangs, even if I insert "ud2" instruction before the
>> next statement, #VMEXIT handler and the first instruction in non-root mode.
>> VMLAUNCH should not make this happen according to Intel's manual 2B.
>> Everything is OK if I set "enable ept" to be 0 or clear the "EPT pointer"
>> field in VMCS. Can someone explain why this happens and what should I do to
>> continue debugging?
>>
>> Both the hypervisor and the Windows OS is on x86_32 platform. I use windbg
>> to debug the target machine via serial port.
>>
>> Some debug information: EPT pointer is 0x9ba801e, (pfn:0x9ba8, flag:0x1e, I
>> have double checked this) PML4[0] = 0x00000000_09cd8007, PDPT[0] =
>> 0x00000000_09cf3007, PD[0] = 0x00000000_09cf2007, PT[0] =
>> 0x00000000_00000077. Other entries of the same scheme with different values.
>>
>> The debuggee is Intel i5 650, multi-core disabled.
>>
>> Thanks,
>> Miao
>>
>> On 11/17/2010 7:53 PM, Superymk wrote:
>>
>> Thanks for Ian's answer. it comes to a more general scenario.
>>
>> Hi Chu, EPT entry is 64 bit long, regardless the hypervisor is on x86_32
>> platform or x86_64 platform. So there is no difference for the hypervisor to
>> use EPT on these two platforms.
>>
>> On 11/17/2010 7:26 PM, Chu Rui wrote:
>>
>> Okay, in my mind, the hardware has only one work mode, 32bit or 64bit. Thus
>> the 32bit guest address will be extended under the 64bit host.
>> But what will happen for a 64bit guest under a 32bit host :-)
>>
>> 2010/11/17 Ian Campbell<Ian.Campbell@citrix.com>
>>> On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>>>> 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.
>>> Even on x86_32 physical addresses are>32 bit (think PAE). cr3 is a
>>> physical address, even if the register which exposes it happens to be
>>> limited to 32 bits. cr3 has probably already been expanded to a full
>>> physical address by the time EPT sees it and I don't think there's any
>>> difference between 32 and 64 bit (at least in this aspect) in how EPT
>>> handles the translation from physical address to machine address.
>>>
>>> Ian.
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

Thank you very much. My EPT implementation works well now. Currently I 
am using UC (Uncachable) type for the EPT PT entries.

By the way, How can I find out which mfn should be WB and which mfn 
should be UC? I suppose it incurs some performance overhead if not using 
WB. Is there any manual to look up the desirable mfn type on Windows?

Thanks,
Miao

On 11/22/2010 2:49 PM, Haitao Shan wrote:
> One difference between EPT-backed 1:1 mapping and direct 1:1 mapping
> (I suppose that you don't use shadow page table) is that MTRRs are
> ignored when EPT is in effect.
> Do you set up EPT memory type correctly? Especially Windows is likely
> to access MMIO space below 1M.
>
> Shan Haitao
>
> 2010/11/21 Superymk<superymkxen@hotmail.com>:
>> Hi all,
>>
>> I just implement the EPT support in my hypervisor (Very similar to
>> Newbluepill). My new problem is irrelevant with Xen.
>> It's just about how to debug VTx implementation in drivers.
>>
>> Here is the story. First, I implement a driver support partial VTx, and it
>> works very well. Then I implement EPT to identically map gfn to mfn from 0x0
>> to 0xfffff. I suppose it should be OK. But the result is the Windows OS
>> hangs (No reboot, No BSOD) when executing VMLAUNCH instruction.
>>
>> And my problem is that, the windbg just shows "debuggee is running" when the
>> debuggee Windows OS hangs, even if I insert "ud2" instruction before the
>> next statement, #VMEXIT handler and the first instruction in non-root mode.
>> VMLAUNCH should not make this happen according to Intel's manual 2B.
>> Everything is OK if I set "enable ept" to be 0 or clear the "EPT pointer"
>> field in VMCS. Can someone explain why this happens and what should I do to
>> continue debugging?
>>
>> Both the hypervisor and the Windows OS is on x86_32 platform. I use windbg
>> to debug the target machine via serial port.
>>
>> Some debug information: EPT pointer is 0x9ba801e, (pfn:0x9ba8, flag:0x1e, I
>> have double checked this) PML4[0] = 0x00000000_09cd8007, PDPT[0] =
>> 0x00000000_09cf3007, PD[0] = 0x00000000_09cf2007, PT[0] =
>> 0x00000000_00000077. Other entries of the same scheme with different values.
>>
>> The debuggee is Intel i5 650, multi-core disabled.
>>
>> Thanks,
>> Miao
>>
>> On 11/17/2010 7:53 PM, Superymk wrote:
>>
>> Thanks for Ian's answer. it comes to a more general scenario.
>>
>> Hi Chu, EPT entry is 64 bit long, regardless the hypervisor is on x86_32
>> platform or x86_64 platform. So there is no difference for the hypervisor to
>> use EPT on these two platforms.
>>
>> On 11/17/2010 7:26 PM, Chu Rui wrote:
>>
>> Okay, in my mind, the hardware has only one work mode, 32bit or 64bit. Thus
>> the 32bit guest address will be extended under the 64bit host.
>> But what will happen for a 64bit guest under a 32bit host :-)
>>
>> 2010/11/17 Ian Campbell<Ian.Campbell@citrix.com>
>>> On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>>>> 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.
>>> Even on x86_32 physical addresses are>32 bit (think PAE). cr3 is a
>>> physical address, even if the register which exposes it happens to be
>>> limited to 32 bits. cr3 has probably already been expanded to a full
>>> physical address by the time EPT sees it and I don't think there's any
>>> difference between 32 and 64 bit (at least in this aspect) in how EPT
>>> handles the translation from physical address to machine address.
>>>
>>> Ian.
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>

Re: How EPT translates an X86_32 guest physical address?

[Haitao Shan]

You can get those memory type information from parsing current MTRR
settings. And then reflecting those via EPT entries.

EPT memory type has two different kinds of settings basically. One is
using EPT memory type directly (ignoring guest PAT settings). The
other one is combined effective memory type derived from EPT memory
type and guest PAT settings, which means EPT memory type is served as
a replacement of MTRRs. I suggest that you use the latter one.

Shan Haitao

2010/11/22 Superymk <superymkxen@hotmail.com>:
> Thank you very much. My EPT implementation works well now. Currently I am
> using UC (Uncachable) type for the EPT PT entries.
>
> By the way, How can I find out which mfn should be WB and which mfn should
> be UC? I suppose it incurs some performance overhead if not using WB. Is
> there any manual to look up the desirable mfn type on Windows?
>
> Thanks,
> Miao
>
> On 11/22/2010 2:49 PM, Haitao Shan wrote:
>>
>> One difference between EPT-backed 1:1 mapping and direct 1:1 mapping
>> (I suppose that you don't use shadow page table) is that MTRRs are
>> ignored when EPT is in effect.
>> Do you set up EPT memory type correctly? Especially Windows is likely
>> to access MMIO space below 1M.
>>
>> Shan Haitao
>>
>> 2010/11/21 Superymk<superymkxen@hotmail.com>:
>>>
>>> Hi all,
>>>
>>> I just implement the EPT support in my hypervisor (Very similar to
>>> Newbluepill). My new problem is irrelevant with Xen.
>>> It's just about how to debug VTx implementation in drivers.
>>>
>>> Here is the story. First, I implement a driver support partial VTx, and
>>> it
>>> works very well. Then I implement EPT to identically map gfn to mfn from
>>> 0x0
>>> to 0xfffff. I suppose it should be OK. But the result is the Windows OS
>>> hangs (No reboot, No BSOD) when executing VMLAUNCH instruction.
>>>
>>> And my problem is that, the windbg just shows "debuggee is running" when
>>> the
>>> debuggee Windows OS hangs, even if I insert "ud2" instruction before the
>>> next statement, #VMEXIT handler and the first instruction in non-root
>>> mode.
>>> VMLAUNCH should not make this happen according to Intel's manual 2B.
>>> Everything is OK if I set "enable ept" to be 0 or clear the "EPT pointer"
>>> field in VMCS. Can someone explain why this happens and what should I do
>>> to
>>> continue debugging?
>>>
>>> Both the hypervisor and the Windows OS is on x86_32 platform. I use
>>> windbg
>>> to debug the target machine via serial port.
>>>
>>> Some debug information: EPT pointer is 0x9ba801e, (pfn:0x9ba8, flag:0x1e,
>>> I
>>> have double checked this) PML4[0] = 0x00000000_09cd8007, PDPT[0] =
>>> 0x00000000_09cf3007, PD[0] = 0x00000000_09cf2007, PT[0] =
>>> 0x00000000_00000077. Other entries of the same scheme with different
>>> values.
>>>
>>> The debuggee is Intel i5 650, multi-core disabled.
>>>
>>> Thanks,
>>> Miao
>>>
>>> On 11/17/2010 7:53 PM, Superymk wrote:
>>>
>>> Thanks for Ian's answer. it comes to a more general scenario.
>>>
>>> Hi Chu, EPT entry is 64 bit long, regardless the hypervisor is on x86_32
>>> platform or x86_64 platform. So there is no difference for the hypervisor
>>> to
>>> use EPT on these two platforms.
>>>
>>> On 11/17/2010 7:26 PM, Chu Rui wrote:
>>>
>>> Okay, in my mind, the hardware has only one work mode, 32bit or 64bit.
>>> Thus
>>> the 32bit guest address will be extended under the 64bit host.
>>> But what will happen for a 64bit guest under a 32bit host :-)
>>>
>>> 2010/11/17 Ian Campbell<Ian.Campbell@citrix.com>
>>>>
>>>> On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>>>>>
>>>>> 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.
>>>>
>>>> Even on x86_32 physical addresses are>32 bit (think PAE). cr3 is a
>>>> physical address, even if the register which exposes it happens to be
>>>> limited to 32 bits. cr3 has probably already been expanded to a full
>>>> physical address by the time EPT sees it and I don't think there's any
>>>> difference between 32 and 64 bit (at least in this aspect) in how EPT
>>>> handles the translation from physical address to machine address.
>>>>
>>>> Ian.
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>
>

Re: How EPT translates an X86_32 guest physical address?

[Superymk]

Thanks a lot. I'll have a try on it.

Miao

On 11/23/2010 9:05 AM, Haitao Shan wrote:
> You can get those memory type information from parsing current MTRR
> settings. And then reflecting those via EPT entries.
>
> EPT memory type has two different kinds of settings basically. One is
> using EPT memory type directly (ignoring guest PAT settings). The
> other one is combined effective memory type derived from EPT memory
> type and guest PAT settings, which means EPT memory type is served as
> a replacement of MTRRs. I suggest that you use the latter one.
>
> Shan Haitao
>
> 2010/11/22 Superymk<superymkxen@hotmail.com>:
>> Thank you very much. My EPT implementation works well now. Currently I am
>> using UC (Uncachable) type for the EPT PT entries.
>>
>> By the way, How can I find out which mfn should be WB and which mfn should
>> be UC? I suppose it incurs some performance overhead if not using WB. Is
>> there any manual to look up the desirable mfn type on Windows?
>>
>> Thanks,
>> Miao
>>
>> On 11/22/2010 2:49 PM, Haitao Shan wrote:
>>> One difference between EPT-backed 1:1 mapping and direct 1:1 mapping
>>> (I suppose that you don't use shadow page table) is that MTRRs are
>>> ignored when EPT is in effect.
>>> Do you set up EPT memory type correctly? Especially Windows is likely
>>> to access MMIO space below 1M.
>>>
>>> Shan Haitao
>>>
>>> 2010/11/21 Superymk<superymkxen@hotmail.com>:
>>>> Hi all,
>>>>
>>>> I just implement the EPT support in my hypervisor (Very similar to
>>>> Newbluepill). My new problem is irrelevant with Xen.
>>>> It's just about how to debug VTx implementation in drivers.
>>>>
>>>> Here is the story. First, I implement a driver support partial VTx, and
>>>> it
>>>> works very well. Then I implement EPT to identically map gfn to mfn from
>>>> 0x0
>>>> to 0xfffff. I suppose it should be OK. But the result is the Windows OS
>>>> hangs (No reboot, No BSOD) when executing VMLAUNCH instruction.
>>>>
>>>> And my problem is that, the windbg just shows "debuggee is running" when
>>>> the
>>>> debuggee Windows OS hangs, even if I insert "ud2" instruction before the
>>>> next statement, #VMEXIT handler and the first instruction in non-root
>>>> mode.
>>>> VMLAUNCH should not make this happen according to Intel's manual 2B.
>>>> Everything is OK if I set "enable ept" to be 0 or clear the "EPT pointer"
>>>> field in VMCS. Can someone explain why this happens and what should I do
>>>> to
>>>> continue debugging?
>>>>
>>>> Both the hypervisor and the Windows OS is on x86_32 platform. I use
>>>> windbg
>>>> to debug the target machine via serial port.
>>>>
>>>> Some debug information: EPT pointer is 0x9ba801e, (pfn:0x9ba8, flag:0x1e,
>>>> I
>>>> have double checked this) PML4[0] = 0x00000000_09cd8007, PDPT[0] =
>>>> 0x00000000_09cf3007, PD[0] = 0x00000000_09cf2007, PT[0] =
>>>> 0x00000000_00000077. Other entries of the same scheme with different
>>>> values.
>>>>
>>>> The debuggee is Intel i5 650, multi-core disabled.
>>>>
>>>> Thanks,
>>>> Miao
>>>>
>>>> On 11/17/2010 7:53 PM, Superymk wrote:
>>>>
>>>> Thanks for Ian's answer. it comes to a more general scenario.
>>>>
>>>> Hi Chu, EPT entry is 64 bit long, regardless the hypervisor is on x86_32
>>>> platform or x86_64 platform. So there is no difference for the hypervisor
>>>> to
>>>> use EPT on these two platforms.
>>>>
>>>> On 11/17/2010 7:26 PM, Chu Rui wrote:
>>>>
>>>> Okay, in my mind, the hardware has only one work mode, 32bit or 64bit.
>>>> Thus
>>>> the 32bit guest address will be extended under the 64bit host.
>>>> But what will happen for a 64bit guest under a 32bit host :-)
>>>>
>>>> 2010/11/17 Ian Campbell<Ian.Campbell@citrix.com>
>>>>> On Wed, 2010-11-17 at 10:32 +0000, George Dunlap wrote:
>>>>>> 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.
>>>>> Even on x86_32 physical addresses are>32 bit (think PAE). cr3 is a
>>>>> physical address, even if the register which exposes it happens to be
>>>>> limited to 32 bits. cr3 has probably already been expanded to a full
>>>>> physical address by the time EPT sees it and I don't think there's any
>>>>> difference between 32 and 64 bit (at least in this aspect) in how EPT
>>>>> handles the translation from physical address to machine address.
>>>>>
>>>>> Ian.
>>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>