similar to: [RFC] CPUID usage for interaction between Hypervisors and Linux.

The following makes 'x86info -r' dump hypervisor leaf cpu ids (for kvm this is signature+features) when running in a vm. On the guest we see the signature and the features: eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 Hypervisor flag is checked to avoid output changes when

The following makes 'x86info -r' dump hypervisor leaf cpu ids (for kvm this is signature+features) when running in a vm. On the guest we see the signature and the features: eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 Hypervisor flag is checked to avoid output changes when

On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov <gleb at kernel.org> wrote: > > On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote: > >> On 09/19/2014 10:15 AM, Gleb Natapov wrote: > >> > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: > >> >> On

On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov <gleb at kernel.org> wrote: > > On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote: > >> On 09/19/2014 10:15 AM, Gleb Natapov wrote: > >> > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: > >> >> On

I'm not sure what you mean by "this mechanism?" Are you suggesting that each hypervisor put "CrossHVPara\0" somewhere in the 0x40000000 - 0x400fffff CPUID range, and an OS has to do a full scan of this CPUID range on boot to find it? That seems pretty inefficient. An OS will take 1000's of hypervisor intercepts on every boot just to search this CPUID range. I

I'm not sure what you mean by "this mechanism?" Are you suggesting that each hypervisor put "CrossHVPara\0" somewhere in the 0x40000000 - 0x400fffff CPUID range, and an OS has to do a full scan of this CPUID range on boot to find it? That seems pretty inefficient. An OS will take 1000's of hypervisor intercepts on every boot just to search this CPUID range. I

On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote: > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote: > > The following makes 'x86info -r' dump kvm cpu ids > > (signature+features) when running in a vm. > > > > On the guest we see the signature and the features: > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx =

On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote: > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote: > > The following makes 'x86info -r' dump kvm cpu ids > > (signature+features) when running in a vm. > > > > On the guest we see the signature and the features: > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx =

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

Hi Jan, I was wondering if we should not let the code fall through and clear all registers to zero but rather clear just the one bit we care about? My concern is that a future Intel revision may expand this function and return other information besides that XSAVEOPT, which would then be wiped out by the fall-through code. I''m thinking something like this. Let me know if I have

On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin <hpa at zytor.com> wrote: > On 09/18/2014 02:46 PM, David Hepkin wrote: >> I'm not sure what you mean by "this mechanism?" Are you suggesting that each hypervisor put "CrossHVPara\0" somewhere in the 0x40000000 - 0x400fffff CPUID range, and an OS has to do a full scan of this CPUID range on boot to find it?

On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin <hpa at zytor.com> wrote: > On 09/18/2014 02:46 PM, David Hepkin wrote: >> I'm not sure what you mean by "this mechanism?" Are you suggesting that each hypervisor put "CrossHVPara\0" somewhere in the 0x40000000 - 0x400fffff CPUID range, and an OS has to do a full scan of this CPUID range on boot to find it?

On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini <pbonzini at redhat.com> wrote: > >> > Actually, that MSR address range has been reserved for that purpose, along >> > with: >> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal) >> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID) >> >> I don't know whether this is

On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini <pbonzini at redhat.com> wrote: > >> > Actually, that MSR address range has been reserved for that purpose, along >> > with: >> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal) >> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID) >> >> I don't know whether this is

After aa297292d708, there are separate native calibrations for cpu_khz and tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu() which looks in cpuid leaf 0x16 or msrs for the cpu frequency. Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and tsc_khz may start diverging. tsc_init() now does cpu_khz = x86_platform.calibrate_cpu(); tsc_khz =

After aa297292d708, there are separate native calibrations for cpu_khz and tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu() which looks in cpuid leaf 0x16 or msrs for the cpu frequency. Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and tsc_khz may start diverging. tsc_init() now does cpu_khz = x86_platform.calibrate_cpu(); tsc_khz =

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin <hpa at zytor.com> wrote: > On 09/18/2014 07:40 AM, KY Srinivasan wrote: >>> >>> The main questions are what MSR index to use and how to detect the >>> presence of the MSR. I've played with two approaches: >>> >>> 1. Use CPUID to detect the presence of this feature. This is very easy for