WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] How EPT translates an X86_32 guest physical address?

To: Superymk <superymkxen@xxxxxxxxxxx>
Subject: Re: [Xen-devel] How EPT translates an X86_32 guest physical address?
From: Haitao Shan <maillists.shan@xxxxxxxxx>
Date: Mon, 22 Nov 2010 14:49:06 +0800
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Chu Rui <ruichu@xxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Sun, 21 Nov 2010 22:50:00 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LJ5GTYRHoNYvAI52enqJBFnppN/CJn9LToG87fIZj9I=; b=iLy0+1BFEKSVBF7FcZmxmiTPpNoKN1xyg7aCV6uzM0EwrN3qQCRr7qzRRLj0Fws6k8 WSNSx9rVgsIpdBVPGfHseK8CslyK4AhJ2DbQJd3M2VPQPSFcMOgJq2fm5UQLuZQovsMp WG8vF4d6UKyN1qDm05tCxaXnPtG2i8N5uDKqI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pvr9mbitnASY3teuFoG568JK8IGnu8edRwLOtigmI/6+Et3ZZfykQvTZ6WmYRJEcEF uDAJXmtIHF8G+MQ7pmu2+IULsqezZKOxpUbl8w1aXzFom3fazCTVQJgJG3cBxp6gnqkJ XefPktQSZ1wPZ3yBTOaxpbSv9va2Z2ukiY8zc=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BLU0-SMTP149921D35AE97931DE151B6A23C0@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BLU0-SMTP80A291F0F92750E38F3084A2380@xxxxxxx> <AANLkTimG4DCtXSJO0xFoSGgJ_8v46j6W4RU=gUwP+i2L@xxxxxxxxxxxxxx> <BLU0-SMTP170F62EE03BF27EE5AC75FCA2380@xxxxxxx> <AANLkTi=Mu0rom3KCDOQV7tsVnr_sq_npEWEW7FxaFp4T@xxxxxxxxxxxxxx> <BLU0-SMTP204EE298B6F47B9A3CB2B67A2380@xxxxxxx> <4CE3AF56.9030503@xxxxxxxxxxxxx> <1289990998.31507.3506.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTimjjcBS3GujX7XzN1L3bG6YCnxyRt_fn+H0eM2F@xxxxxxxxxxxxxx> <BLU0-SMTP16481E4B6A29A5FDD7236BBA2380@xxxxxxx> <BLU0-SMTP149921D35AE97931DE151B6A23C0@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxx>:
> 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@xxxxxxxxxx>
>>
>> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>

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