Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain

[Mats Petersson <mats@xxxxxxxxxxxxxxxxx>]

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