Xen users - Mar 2008 - xen guest detection.

Hey All,

I''m working on robust way for a process to be able to detect that it is
running in xen guest, and distinguish between a para-vitualized and
fully-virtualized environment.

Here are the clues I can use:

#1) If I pin a process to a specific virtual cpu with sched_setaffinity()
and then fetch the proccesors local apic id with the cpuid instruction,
multiple calls will/may give me different ids since the xen hypervisor
doesn''t always map the same virtual cpu to the same physical cpu.

This method isn''t very robust.  Say a in-guest process runs cpuid
multiple
times and always gets the same apic id.  Maybe there is only one processor
on the host and maybe the hypervisor just keeps mapping the virtual cpu to
the same physical cpu for each call.

#2) I noticed that in a para-virt environment, the motherboard BIOS area in
physical ram (64k starting at 0xf0000) is all zeros.  But can I count on
this to be the same for future versions of xen?

#3) Check the existence of /proc/xen and the absence of xend/the xend xmlrpc
socket.  This method is a little bit error prone because paths may change
(Xen installation may be redhat or xen enterprise).  Other proccesses may
match "xend".  How can I distinguish the two cases: 1) baremetal + xen
enabled kernel but xend is not installed  2) a real xen guest environment.

#4) Check if the virtual ethernet hw address is a xen address.  But I think
users can just specify there own ethernet hw address.


Thoughts?

I''m leaning toward #2 or #3.

Thanks Ahead!
Mike Closson


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

On Tue, Mar 18, 2008 at 10:46 AM, Michael Closson <closms@gmail.com>
wrote:
> Hey All,
>
> I''m working on robust way for a process to be able to detect that
it is
> running in xen guest, and distinguish between a para-vitualized and
> fully-virtualized environment.
>
> Here are the clues I can use:
>
> #1) If I pin a process to a specific virtual cpu with sched_setaffinity()
> and then fetch the proccesors local apic id with the cpuid instruction,
> multiple calls will/may give me different ids since the xen hypervisor
> doesn''t always map the same virtual cpu to the same physical cpu.
>
> This method isn''t very robust.  Say a in-guest process runs cpuid
multiple
> times and always gets the same apic id.  Maybe there is only one processor
> on the host and maybe the hypervisor just keeps mapping the virtual cpu to
> the same physical cpu for each call.
>
> #2) I noticed that in a para-virt environment, the motherboard BIOS area
> in physical ram (64k starting at 0xf0000) is all zeros.  But can I count on
> this to be the same for future versions of xen?
>
> #3) Check the existence of /proc/xen and the absence of xend/the xend
> xmlrpc socket.  This method is a little bit error prone because paths may
> change (Xen installation may be redhat or xen enterprise).  Other
proccesses
> may match "xend".  How can I distinguish the two cases: 1)
baremetal + xen
> enabled kernel but xend is not installed  2) a real xen guest environment.
>
> #4) Check if the virtual ethernet hw address is a xen address.  But I
> think users can just specify there own ethernet hw address.
>
>
> Thoughts?
>
>
This thread might give some ideas too:
http://xen.markmail.org/search/?q=hvm%20detect%20shell%20script#query:hvm%20detect%20shell%20script+page:1+mid:xurts65ly6b3xlch+state:results

> I''m leaning toward #2 or #3.
>
> Thanks Ahead!
> Mike Closson
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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