Xen devel - Jan 2008 - Early test for 32- vs 64-bit hvm domain?

What is the proper way to test to see if an hvm domain is destined
to be x86 vs x86_64 whilst still early in its initialization in the
hypervisor, e.g. in hvm_vcpu_initialise(v) or hvm_domain_initialise(d)?
Is this information pased down from hvmloader or does it get
discovered somehow?  Or maybe it is not possible to determine
until a vcpu actually starts executing?

I see vmx_guest_x86_mode(v) ASSERTs if v!=current so hvm_guest_x86_mode(v)
can't be used. And hvm_long_mode_enabled(v) doesn't seem to work that
early.  Also, the arch_domain struct has a "is_32bit_pv" field but I
can't
find any equivalent for hvm.

Thanks for any suggestions!
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dan Magenheimer, le Tue 29 Jan 2008 17:01:22 -0700, a écrit
:
> What is the proper way to test to see if an hvm domain is destined
> to be x86 vs x86_64 whilst still early in its initialization in the
> hypervisor, e.g. in hvm_vcpu_initialise(v) or hvm_domain_initialise(d)?
> Is this information pased down from hvmloader or does it get
> discovered somehow?  Or maybe it is not possible to determine
> until a vcpu actually starts executing?
As long as e.g. Linux has not started (i.e. during bios and grub for
instance), you can''t know whether that will be a 64bit Linux or a 32bit
Linux.

Samuel

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

> Dan Magenheimer, le Tue 29 Jan 2008 17:01:22 -0700, a écrit :
> > What is the proper way to test to see if an hvm domain is destined
> > to be x86 vs x86_64 whilst still early in its initialization in the
> > hypervisor, e.g. in hvm_vcpu_initialise(v) or 
> hvm_domain_initialise(d)?
> > Is this information pased down from hvmloader or does it get
> > discovered somehow?  Or maybe it is not possible to determine
> > until a vcpu actually starts executing?
> 
> As long as e.g. Linux has not started (i.e. during bios and grub for
> instance), you can''t know whether that will be a 64bit Linux 
> or a 32bit
> Linux.
That''s what I was afraid of...

Then what is the earliest point in the execution of an x86_64
domain/vcpu in *xen* where hvm_long_mode_enabled(v) will work
properly? E.g. in Linux/x86_64 is long mode set early in __start?
And is this done via a hypercall or an emulated instruction?

Thanks,
Dan


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

On 30/1/08 00:34, "Dan Magenheimer" <dan.magenheimer@oracle.com>
wrote:
>> As long as e.g. Linux has not started (i.e. during bios and grub for
>> instance), you can''t know whether that will be a 64bit Linux
>> or a 32bit
>> Linux.
> 
> That''s what I was afraid of...
> 
> Then what is the earliest point in the execution of an x86_64
> domain/vcpu in *xen* where hvm_long_mode_enabled(v) will work
> properly? E.g. in Linux/x86_64 is long mode set early in __start?
> And is this done via a hypercall or an emulated instruction?
As sson as you see LME bit get set in the EFER MSR then you know you have a
64-bit guest. Writes to EFER are emulated in long_mode_do_msr_write() in
vmx.c and svm.c. Those are the places to patch in Xen 3.1 branch.

 -- Keir



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

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 30/1/08 00:34, "Dan Magenheimer"
<dan.magenheimer@oracle.com> wrote:
>
>>> As long as e.g. Linux has not started (i.e. during bios and grub
for
>>> instance), you can''t know whether that will be a 64bit
Linux
>>> or a 32bit
>>> Linux.
>> 
>> That''s what I was afraid of...
>> 
>> Then what is the earliest point in the execution of an x86_64
>> domain/vcpu in *xen* where hvm_long_mode_enabled(v) will work
>> properly? E.g. in Linux/x86_64 is long mode set early in __start?
>> And is this done via a hypercall or an emulated instruction?
>
> As sson as you see LME bit get set in the EFER MSR then you know you have a
> 64-bit guest. Writes to EFER are emulated in long_mode_do_msr_write() in
> vmx.c and svm.c. Those are the places to patch in Xen 3.1 branch.
You could do it slightly earlier by intercepting bios int 0x15 eax=0xec00 ebx=2 
The kernel issues that to tell the BIOS it is 64bit.

That will only work if the boot loader does not skip the real mode code
(a few do) 

-Andi

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

On 30/1/08 18:44, "Andi Kleen" <andi@firstfloor.org> wrote:
>> As sson as you see LME bit get set in the EFER MSR then you know you
have a
>> 64-bit guest. Writes to EFER are emulated in long_mode_do_msr_write()
in
>> vmx.c and svm.c. Those are the places to patch in Xen 3.1 branch.
> 
> You could do it slightly earlier by intercepting bios int 0x15 eax=0xec00
> ebx=2 The kernel issues that to tell the BIOS it is 64bit.
> 
> That will only work if the boot loader does not skip the real mode code
> (a few do) 
Oh, I hadn''t read about that. We should probably make that call during
Xen
boot then. For this particular issue I expect that trapping EFER.LME is
equally good, and it depends on whether the trap is more conveniently
triggered in the hypervisor itself or in the virtual bios.

 -- Keir



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