Bug 749544

Summary: SMEP feature is not exposed to guest
Product: Red Hat Enterprise Linux 6 Reporter: Yongjie Ren <yongjie.ren>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED DUPLICATE QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2CC: alex.williamson, chao.zhou, chrisw, ddugger, ddutile, haitao.shan, rpacheco, tburke, xudong.hao
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-28 19:35:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
program to check bits of IVB new features none

Description Yongjie Ren 2011-10-27 12:54:49 UTC
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:

Comment 2 Alex Williamson 2011-10-27 15:21:34 UTC
This looks like a feature request.  Also, what does booting with intel_iommu=on have to do with the SMEP processor feature?

Comment 3 Don Dugger 2011-10-27 19:08:33 UTC

*** This bug has been marked as a duplicate of bug 703053 ***

Comment 4 Yongjie Ren 2011-10-28 01:27:19 UTC
(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.

Comment 5 Chris Wright 2011-10-28 19:00:38 UTC
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.

Comment 7 Chris Wright 2011-10-28 19:35:52 UTC
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 ***