>>> On 10/20/2008 at 6:08 AM, in message <20081020100844.GA2955@xxxxxxxxxxx>,
Karel Zak <kzak@xxxxxxxxxx> wrote:
> On Thu, Oct 02, 2008 at 06:31:36PM +0800, CAI Qian wrote:
>> > +static void
>> > +read_hypervisor_cpuid(struct cpu_desc *cpu)
>> > +{
>> > + unsigned int eax, ebx, ecx, edx;
>> > + char hyper_vendor_id[13];
>> > +
>> > + memset(hyper_vendor_id, 0, sizeof(hyper_vendor_id));
>> > +
>> > + cpuid(HYPERVISOR_INFO_LEAF, &eax, &ebx, &ecx, &edx);
>> > + memcpy(hyper_vendor_id + 0, &ebx, 4);
>> > + memcpy(hyper_vendor_id + 4, &ecx, 4);
>> > + memcpy(hyper_vendor_id + 8, &edx, 4);
>> > + hyper_vendor_id[12] = '\0';
>> > +
>>
>> I have tested it in Xen Domain 0 Kernel (2.6.18-117.el5xen.x86_64), it
>> gave me an empty vendor ID. Even with the original version, it showed,
>
> hmm... dom0:
>
> # ./lscpu
> Architecture: x86_64
> CPU(s): 2
> Thread(s) per core: 1
> Core(s) per socket: 1
> CPU socket(s): 2
> Vendor ID: GenuineIntel
> CPU family: 6
> Model: 15
> Stepping: 5
> CPU MHz: 1596.000
> Virtualization: VT-x
> Hypervisor vendor ID: Xen
> Paravirtualization: No
> L1d cache: 32K
> L1i cache: 32K
> L2 cache: 4096K
>
> # uname -a
> Linux rasputin.englab.brq.redhat.com 2.6.18-92.1.1.el5xen #1 SMP Thu
> May 22 09:17:24 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
>
>> No Hypervisor found .
>
> BTW, dom0 is controlled by Xen hypervisor and Xen hypervisor is
> always active, it means
>
> Hypervisor vendor ID: Xen
>
> always for all Xen machines. The problem is that we don't have a way
> how differ between dom0 and full-virt domU. Solution could be:
>
> 1/ don't show "Hypervisor vendor ID: Xen" for dom0. I think it was
> the original Ky's idea.
Since this tool is to be run in the environment where detection is needed, we only need to identify the hypervisor. Furthermore, it will be useful to detect the form of virtualization - para/full. Indeed, for para-virtualized guests, the CPUID test may or may not work (if we don't trap CPUID instruction the hypervisor detection leaf is invalid). Since this tool needs to work across boxes that may or may not support cpuid based detection, I suggest we include other checks such as detecting special files in the case of para-virtualized guests. My initial code had these checks. So, Dom0 which will always be a para-virtualized guest in Xen can be detected correctly. While we are doing this, we may want to add checks for detecting VmWare hypervisors. Today VmWare does not support cpuid based detection (they will do it soon but there is a lot of installations out there that need to be supported). We could look at the output of lspci to detect VmWare devices for this detection.
>
> 2/ show "Hypervisor vendor ID: Xen" (because in pedantic point of
> view Xen is controlling the machine (including dom0)). And add a
> new field:
>
> Virtualization type: para|full|none
>
> for exmaple (dom0):
>
> Hypervisor vendor ID: Xen
> Virtualization type: none
This was my original idea. Dom0 is always para-virtualized on Xen.
>
> domU:
>
> Hypervisor vendor ID: Xen
> Virtualization type: para
>
> Comments? (I vote for 2/, but I don't have a strong opinion about it.)
>
> I think "Virtualization type: para|full|none" is better than
> "Paravirtualization: Yes|No".
Agreed.
>
>> > + if (!access(_PATH_PROC_XEN, F_OK))
>> > + /* XEN dom0 or domU */
>> > + cpu->hvid = strdup("Xen");
>> > + }
>>
>> In RHLE 5 Kernel (2.6.18-92.el5xen), /proc/xen is a directory, so the
>> above check does not work correctly. Is it a file in other Kernels?
>
> It's a directory everywhere. The access(F_OK) works for directories
> as well as for files.
>
> Karel
K. Y
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
