Hide Forgot
Created attachment 530479 [details] program to check bits of IVB new features Description of problem: SMEP feature is not exposed to guest in rhel6.2 snapshot 3. But in host, SMEP bit is enabled. This should be a kernel bug. Using linux kernel 3.1 with the same qemu-kvm, SMEP feature works fine in guest. Version-Release number of selected component (if applicable): related rpm packages rhel6.2 snapshot3: kernel-2.6.32-211.el6.x86_64.rpm qemu-kvm-0.12.1.2-2.199.el6.x86_64.rpm qemu-kvm-tools-0.12.1.2-2.199.el6.x86_64.rpm libvirt-0.9.4-19.el6.x86_64.rpm How reproducible: 100% Steps to Reproduce: 1.start rhel6.2 host with intel_iommu=on in kernel boot option on Ivy Bridge platform 2./usr/libexec/qemu-kvm -smp 2 -m 1024 -had /root/rhel6u2.img -cpu host 3.check SMEP bit in guest. (You may use my attached program to have a check.) 4.check if SMEP feature works well.(Our Intel QA will do this step.) Actual results: SMEP bit is not enabled. Expected results: SMEP feature works well in guest. Additional info:
This looks like a feature request. Also, what does booting with intel_iommu=on have to do with the SMEP processor feature?
*** This bug has been marked as a duplicate of bug 703053 ***
(In reply to comment #2) > This looks like a feature request. Also, what does booting with intel_iommu=on > have to do with the SMEP processor feature? SMEP has nothing to do with the 'intel_iommu' boot option. Oh, I just listed my runtime boot option at that time when I filed the bug.
I'm reopening this bug because the SMEP feature request bug 703053 is already ON_QA. Here's what happened on bug 703053 while this one was temporarily closed: Don Dugger 2011-10-27 15:13:02 EDT Yongjie- you indicated that SMEP was not exposed when `iommu=on' was specified on the kernel command line, does this mean it is exposed when you don't include that flag? Comment 15 Chris Wright 2011-10-27 21:11:11 EDT The test program is looking for more than SMEP. Can you clarify that you are seeing the message "SMEP feature is not enabled" rather than looking at the return code from the test program when running it in the guest? And it seems like you get "SMEP feature is enabled" when running in the host (both 3.1 and RHEL 6.2 snapshot3 kernel). Also, can you debuginfo-install qemu-kvm and then break on cpu_x86_cpuid and step through until you hit "case 7:" and verify what gets loaded for each of eax, ebx, ecx and edx? Comment 16 Yongjie Ren 2011-10-27 21:35:15 EDT (In reply to comment #14) > Yongjie- you indicated that SMEP was not exposed when `iommu=on' was specified > on the kernel command line, does this mean it is exposed when you don't include > that flag? SMEP should have nothing to do with the 'intel_iommu' boot option. Oh, I just listed my runtime boot option at that time when I filed that bug. SMEP isn't exposed to guest either, when it doesn't include 'intel_iommu' boot option. Comment 17 Yongjie Ren 2011-10-28 06:16:26 EDT (In reply to comment #15) > The test program is looking for more than SMEP. It also print some info about other Ivy Bridge features because I also test them. You may focus on SMEP issue. > Can you clarify that you are > seeing the message "SMEP feature is not enabled" rather than looking at the > return code from the test program when running it in the guest? I also checked the ebx[7] which stands for SMEP bit. SMEP is enumerated via CPUID.7.0.EBX[7]. > And it seems > like you get "SMEP feature is enabled" when running in the host (both 3.1 and > RHEL 6.2 snapshot3 kernel). Yes, right. CPUID.7.0.EBX in host is 0x281. So, SMEP bit is enabled in host. > > Also, can you debuginfo-install qemu-kvm and then break on cpu_x86_cpuid and > step through until you hit "case 7:" and verify what gets loaded for each of > eax, ebx, ecx and edx? CPUID info in guest when Leaf 7 subleaf 0: eax 0, ebx 1, ecx 0, edx 0, edx 0 So, SMEP bit is not enabled in guest. Comment 18 Chris Wright 2011-10-28 12:08:13 EDT (In reply to comment #17) > (In reply to comment #15) > > Also, can you debuginfo-install qemu-kvm and then break on cpu_x86_cpuid and > > step through until you hit "case 7:" and verify what gets loaded for each of > > eax, ebx, ecx and edx? > CPUID info in guest when Leaf 7 subleaf 0: > eax 0, ebx 1, ecx 0, edx 0, edx 0 > So, SMEP bit is not enabled in guest. Thanks for the additional details. Is the above from using gdb on the host? I know the test program will show the bits as the guest sees them (with bit 7 in leaf 7 subleaf 0 clear). I just wanted to see what the host is returning from KVM hypervisor to qemu-kvm as part of the guest setup (including the cpuid that the guest will later see). The process includes: 1) inform qemu-kvm which cpuid bits to set (-cpu host) 2) qemu-kvm queries the kernel to verify which bits are supported 3) qemu-kvm sets the cpuid bits 4) vm is launched and a cpuid insn will see only the bits set in step 3 I suspect that step 2) is where things are breaking down. Comment 19 Chris Wright 2011-10-28 13:31:47 EDT I think I see the issue. If I can find a test box, I'll verify. Otherwise I'll build a test kernel for someone else to test.
Sorry for the noise, I'm closing this as duplicate as ddugger had orginially done. Will post patch against bug 703053. My mistake, got the process wrong here. *** This bug has been marked as a duplicate of bug 703053 ***