Proposal for better support of hypervisors and their synthetic drivers at boot-time

[Larry Melia]

John,

Sorry for not responding earlier to your comments, but we’re at a point
where we’re trying to get our VM drivers included with the current build.
Your solution for dynamic loading sounds wonderful! Is this a simple
change? And how can we help?

Here’s an example of the modern, preferred way (Linux has been doing this
for 5+ years) to detect the presence of a hypervisor on x86/AMD chips, both
32/64 bit modes (this is pulled from our FreeBSD driver, but the formatting
is off because Google's Gmail really wants to make it look "pretty"):

*#define HV_X64_MSR_GUEST_OS_ID     0x40000000*

*#define HV_X64_CPUID_MIN  0x40000005*

*#define HV_X64_CPUID_MAX  0x4000ffff*

*static* *int*

*hv_check_for_hyper_v*(*void*)

{

         u_int regs[4];

         *int* hyper_v_detected *=* 0;

         do_cpuid(1, regs);

         *if* (regs[2] *&* 0x80000000) {

                 */* if(a hypervisor is detected) */*

                 */* make sure this really is Hyper-V */*

                 */* we look at the CPUID info */*

                 do_cpuid(HV_X64_MSR_GUEST_OS_ID, regs);

                 hyper_v_detected *=*

                          regs[0] *>=* HV_X64_CPUID_MIN *&&*

                          regs[0] *<=* HV_X64_CPUID_MAX *&&*

                          *!*memcmp("Microsoft Hv", *&*regs[1], 12);

         }

         *return* (hyper_v_detected);

}



Of course, a general purpose routine will simply copy the name-tag
somewhere and make it available.
We are also having some issues with some of the disk utilities. They need
to behave differently when operating under a hypervisor. I’ll try to
provide a list of all the things that should be upgraded or enhanced, then
we can figure out the best way to get them done.


On Mon, Apr 29, 2013 at 10:45 AM, John Baldwin <jhb at freebsd.org> wrote:

> I know Alexander replied about the ATA bits already, but I wanted to reply
> to
> two of your other points below:
>
> On Tuesday, April 23, 2013 10:07:03 am Larry Melia wrote:
> > (1) Move the call to init_param1() (in sys/kern/subr_parm.c), which is
> used
> > for hypervisor detection, to an earlier point in the boot process.
> > Presently, it appears to be called after the ATA driver is selected,
> which
> > is too late in the boot process. (This was discovered after some testing
> > with the ATA driver.) Therefore, before the bus drivers and native
> > controllers are detected and selected, discovery of a host hypervisor
> > should be done first.
> >
> > (3) Upgrade the init_param1() function (in sys/kern/subr_parm.c) to use
> the
> > more recent approach to hypervisor detection. This approach uses the
> > CPU-identify functions to retrieve a unique signature consisting of a
> fixed
> > string of ASCII characters. This was done on Linux about five years. For
> > backward compatibility, however, the existing logic would be retained,
> but
> > augmented with this new approach. It would also be conditionally added
> only
> > for x86/AMD64 builds.
>
> I definitely agree with these proposals.  In addition, our current
> hypervisor
> detection code is completely x86-specific and does not belong in MI code.
>  The
> only bits that should be MI are the vm_guest variable and the VM_GUEST
> constants.  I would argue that most of the VM_GUEST constants (for specific
> VMs which we do not have currently) should be MD as well.
>
> Each platform that supports hypervisors would install its own SYSINIT to
> set
> vm_guest instead of doing it directly from init_param1().
>
> Making the VM_GUEST_FOO constants be MD macros means you can use #ifdef to
> test for them.  Thus:
>
> #ifdef VM_GUEST_HYPERV
> /* Include a hyper-V specific driver. */
> #endif
>
> The current enum approach doesn't allow for that.
>
> --
> John Baldwin
>