Hide Forgot
Description of problem: I was experimenting with data_breakpoint.ko in the kernel samples/hw_breakpoint directory. The example works on the raw hardware, but does not appear to work on the guest vm. The hardware breakpoint on guest vm registers without an error, but there are never any breakpoints encountered on the guest vm. Hardware is a Quad-Core AMD Opteron(tm) Processor 2350 running an updated version of Fedora 15 x86-64 and linux-3.0.0-rc7+ kernel, and qemu-0.14.0-7.1.fc15.x86_64. The guest vm on the machine is also Fedora 15 x86-64 and linux-3.0.0-rc7+ kernel. Version-Release number of selected component (if applicable): linux-3.0.0-rc7+ How reproducible: every time Steps to Reproduce: Set up a guest vm and as root run the following command on the guest vm perf stat -a --event=mem:0x`grep pid_max$ /proc/kallsyms | awk '{print $1}'` sleep 10 Actual results: Performance counter stats for 'sleep 10': 0 unknown 10.008019621 seconds time elapsed Expected results: On raw machine get some breakpoints hits: # perf stat -a --event=mem:0x`grep pid_max$ /proc/kallsyms | awk '{print $1}'` sleep 10 Performance counter stats for 'sleep 10': 11 unknown 10.037146596 seconds time elapsed Additional info:
On a Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz running an updated fedora 17 (3.5.4-1.fc17.x86_64) on host and guest vm things seemed to work on the guest vm: # perf stat -a --event=mem:0x`grep pid_max$ /proc/kallsyms | awk '{print $1}'` sleep 10 Performance counter stats for 'sleep 10': 1 mem:0xffffffff81c2c738:rw 10.000670697 seconds time elapsed However, on AMD family 10h machine with same kernel never seem to get any counts of the event for the guest vm. Always see: # perf stat -a --event=mem:0x`grep pid_max$ /proc/kallsyms | awk '{print $1}'` sleep 10 Performance counter stats for 'sleep 10': 0 mem:0xffffffff81c2c738:rw 10.001438287 seconds time elapsed Looks it might be specific to AMD or family 10h machines.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19