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] Re: [Xen-users] boot a existing windows in hvm domain

To: Keir Fraser <keir@xxxxxxxxxxxxx>,Brady Chen <chenchp@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
From: Mats Petersson <mats@xxxxxxxxxxxxxxxxx>
Date: Wed, 08 Aug 2007 18:45:12 +0100
Cc: Keir Fraser <keir@xxxxxxxxxxxxx>, tygrawy@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Z24 <z24@xxxxxxx>, AL.LINUX@xxxxxxxxxxx
Delivery-date: Wed, 08 Aug 2007 10:43:01 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:cc:in-reply-to:references:mime-version:content-type:sender:message-id; b=ZMfIptQSRRJrXpMWZ9O9yPUgckCetH0wC8zccUGxQ19QdLawfLDB7ZI9NQiXhLrGkgZi7l0e1a/ZvhZjvbK1gaWYttppy+IHjKEy6HQdi61uGp++kDHPnfA8S2UBbScPvN+h74TvLSZlb4GtTFTpk7nvYFNuaXhVwMFBbjJ8X0Q=
Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:x-mailer:date:to:from:subject:cc:in-reply-to:references:mime-version:content-type:sender:message-id; b=VR1ehhv/QE5h5Se6EEr3iG+G2VdFLObJ6wlvzExj3LJXt9HekqotUBR8bHJ6F4cX8c9pNl7jS5Gat62Z7e9KNbuPXXb7Dlfwqa5i0lyMvCvCIZx+ozmeKjxF2dTZi4Z9CQiw5mNJwuEMv5HvxS/Ds+k17oYbh8zSYIb2xWUaV18=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2DFAB87.13D04%keir@xxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8fec1fce0708080850o33f141ta280cb1cf192b12c@xxxxxxxxxxxxxx> <C2DFAB87.13D04%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
At 17:19 08/08/2007, Keir Fraser wrote:
No, it's a processor mode halfway between real mode and protected mode which
all x86 processors support, but which vmxassist is really rather bad at
handling. If this is a big-real-mode copy loop then that might explain why
the loop is executing so bizarrely, and may mean you are out of luck until
we retire vmxassist.


And the fact that EDI is 0xC33FE when it tries to write to the memory at address of EDI indicates that it's Big-Real-Mode.

In real-mode, any register access beyond segment+0xFFFF is a GP-fault on 386 and later processors. To get around this and simplify the process of for example loading large chunks of data into memory, someone figured out that segment register limits (and base-address) is not being RESET by the processor when resetting the protected-mode bit in CR0, so one can go into protected mode, load a segment register with a bigger limit (e.g. a "no limit" of 4GB), and a base-addres of (say) zero.

Unfortunately, since VMXassist uses the VM806 mode of the processor, it doesn't support transitions back and forth between protected mode with segment registers preserved (you can't run in Real Mode with VMX enabled).

The other option for possibly getting this working (plug for my former employer) is to use an AMD processor, as that supports "real-mode virtualization", so you can run real-mode with "SVM" enabled, and in this case, the segment registers can be manipulated in protected mode, and then go back to real-mode, without any loss of segment data.

As Keir hints, there is work to "remove" the VMXassist mode (which by all accounts, and I don't think I'm offending anyone by saying this, is a quick hack to get around the fact that real-mode code is needed to boot the OS).

--
Mats


 -- Keir

On 8/8/07 16:50, "Brady Chen" <chenchp@xxxxxxxxx> wrote:

> "big-real-mode"? is it something related to PAE? my CPU is Intel
> T2400, Centrino Duo
> thanks
>
> [root@localhost firmware]# cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 14
> model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
> stepping        : 8
> cpu MHz         : 1828.831
> cache size      : 2048 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni
> monitor vmx est tm2 xtpr
> bogomips        : 3660.35
>
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 14
> model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
> stepping        : 8
> cpu MHz         : 1828.831
> cache size      : 2048 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up pni
> monitor vmx est tm2 xtprbogomips        : 3660.35
>
>
> On 8/8/07, Mats Petersson <mats@xxxxxxxxxxxxxxxxx> wrote:
>> At 14:32 08/08/2007, Keir Fraser wrote:
>>> Disassembled the interesting bit by hand:
>>>
>>> D700: 66 03 DF               add %edi,%ebx
>>> D703: 66 83 C3 02            add $2,%ebx
>>> D707: 66 81 C7 FE 01 00 00   add $0x1fe,%edi
>>> D70E: 66 49                  dec %ecx
>>> D710: 66 0B C9               or  %ecx,%ecx
>>> D713: 0F 84 17 00            jz  0xd72e
>>> D717: 26 67 8B 03            mov %es:(%ebx),%ax
>>> D71B: 26 67 89 07            mov %ax,%es:(%edi)
>>> D71F: 66 83 C3 02            add $2,%ebx
>>> D723: 66 81 C7 00 02 00 00   add $0x200,%edi
>>> D72A: 66 49                  dec %ecx
>>> D72C: EB E2                  jmp 0xd710
>>> D72E: 66 61                  popal
>>> D730: 90                     nop
>>> D731: 1F                     pop %ds
>>> D732: 07                     pop %es
>>> D733: C3                     ret
>>
>>
>> Any chance that the segment(s) involved are "big-real-mode"?
>>
>> --
>> Mats
>
> _______________________________________________
> 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

<Prev in Thread] Current Thread [Next in Thread>