paravirt: Add simple hypervisor registration and detection interface
AbandonedPublic
Actions

Authored by bryanv on Jan 4 2015, 5:54 AM.

Details

Reviewers

Summary

The hypervisor guest support can register itself to be called during the SI_SUB_HYPERVISOR SYSINIT level early in the boot to determine if we are a guest of that hypervisor. If detected, the vendor name and guest type can be set.

While here, remove the out of place VMware detection done during identify_cpu(). This will be restored in a subsequent commit that adds VMware guest support using this interface.

While not done in this patch, the existing Xen and Hyper-V code should eventually be converted.

Diff Detail

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

bryanv updated this revision to Diff 2984.Jan 4 2015, 5:54 AM

bryanv retitled this revision from to paravirt: Add simple hypervisor registration and detection interface .

bryanv updated this object.

bryanv edited the test plan for this revision. (Show Details)

bryanv set the repository for this revision to rS FreeBSD src repository - subversion.

emaste added a subscriber: emaste.Jan 5 2015, 7:47 PM

bryanv added a reviewer: jhb.Jan 6 2015, 6:31 PM

One thing I'm worried about is that it looks like you only set the vendor name if a hypervisor "driver" calls hypervisor_register(), so that means we won't announce any "unknown" hypervisor vendor? Right now we will always pull hv_vendor out of cpuid if the cpuid leaf is valid, even if it is a hypervisor that we don't currently have a driver for. I think we don't want to lose this feature.

sys/x86/x86/hypervisor.c
53	Maybe drop one of "already"or "yet" as I think having both is redundant? Also, "hypervisors" and "its" are a number mismatch, maybe "We assume a detectable hypervisor..."?

In D1431#5, @jhb wrote:

One thing I'm worried about is that it looks like you only set the vendor name if a hypervisor "driver" calls hypervisor_register(), so that means we won't announce any "unknown" hypervisor vendor? Right now we will always pull hv_vendor out of cpuid if the cpuid leaf is valid, even if it is a hypervisor that we don't currently have a driver for. I think we don't want to lose this feature.

I'll restore that functionality (and probably bring back hv_high that got lost along the way).