GPF while testing fwts msr

Mon Jan 30 15:17:03 UTC 2012

On 01/30/2012 10:03 AM, Chris Van Hoof wrote:
> On 01/30/2012 05:47 AM, Colin Ian King wrote:
>>
>> I believe the GPF is expected if we try and access a MSR that doesn't
>> exist, so this is normal behaviour here, especially inside kvm where we
>> don't have support for this MSR.
>>
>> I suspect this is returning something like -EINVAL to the pread() being
>> used on the MSR, and this ripples back up as a FWTS_ERROR and the test
>> failing to run.  It doesn't break/abort fwts does it?
>>
>> Colin
> 
> No breakage, but I never saw this GPF on kernels < 3.2.0-10, so just
> something new I'm seeing when testing new fwts-live images as I update
> to use the latest Precise kernels.
> 
> ... the dialog screen quickly breaks to the GPF and continues running.
> 
> --chris

Alternatively if this is expected behaviour, is it possible to detect if
running in a virtual instance and not have the msr test used as one of
the batch tests?

>>
>> On 30/01/12 06:41, Alex Hung wrote:
>>> On 01/29/2012 05:59 AM, Chris Van Hoof wrote:
>>>> Hey guys,
>>>> While testing the latest fwts-live image[0] (3.2.0-11.19) in a kvm
>>>> instance I noticed that when the msr test is executed I'm seeing a GPF:
>>>>
>>>> [ 19.495910] general protection fault: 0000 [#1] SMP
>>>> [ 19.496033] CPU 0
>>>> [ 19.496068] Modules linked in: msr ppdev parport_pc parport mac_hid
>>>> psmouse serio_raw i2c_piix4 squashfs overlayfs nls_iso8859_1 nls_cp437
>>>> vfat fat floppy 8139too 8139cp zram(C)
>>>> [ 19.496461]
>>>> [ 19.496490] Pid: 2052, comm: fwts Tainted: G C
>>>> 3.2.0-11-generic #19-Ubuntu Bochs Bochs
>>>> [ 19.496640] RIP: 0010:[<ffffffff8103bf5d>] [<ffffffff8103bf5d>]
>>>> native_read_msr_safe+0xd/0x30
>>>> [ 19.496990] RSP: 0018:ffff88001ba73db0 EFLAGS: 00000086
>>>> [ 19.497170] RAX: 0000000012a40000 RBX: ffff88001ba73e58 RCX:
>>>> 0000000000000480
>>>> [ 19.497376] RDX: 00000000ffff8800 RSI: ffff88001ba73dcc RDI:
>>>> 0000000000000480
>>>> [ 19.497576] RBP: ffff88001ba73db0 R08: 0000000000000000 R09:
>>>> 0000000000000000
>>>> [ 19.497576] R10: 0000000000000480 R11: 0000000000000246 R12:
>>>> ffffffff81326400
>>>> [ 19.497576] R13: 0000000000000000 R14: ffffffff81cdc000 R15:
>>>> 0000000000000008
>>>> [ 19.497576] FS: 00007f43dabb6720(0000) GS:ffff88001f400000(0000)
>>>> knlGS:0000000000000000
>>>> [ 19.497576] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> [ 19.497576] CR2: 00007f43dabbc000 CR3: 000000001bc9a000 CR4:
>>>> 00000000000006f0
>>>> [ 19.497576] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>>>> 0000000000000000
>>>> [ 19.497576] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>>>> 0000000000000400
>>>> [ 19.497576] Process fwts (pid: 2052, threadinfo ffff88001ba72000,
>>>> task ffff88001da00000)
>>>> [ 19.497576] Stack:
>>>> [ 19.497576] ffff88001ba73dd8 ffffffff8132641c ffffffff81187063
>>>> ffff88001b9da600
>>>> [ 19.497576] 0000000000000246 ffff88001ba73e48 ffffffff810a0ec7
>>>> 0000000000000000
>>>> [ 19.497576] 0000000000000000 ffff88001d87d950 0000000000000000
>>>> 0000000000000000
>>>> [ 19.497576] Call Trace:
>>>> [ 19.497576] [<ffffffff8132641c>] __rdmsr_safe_on_cpu+0x1c/0x40
>>>> [ 19.497576] [<ffffffff81187063>] ? user_path_at_empty+0x63/0xa0
>>>> [ 19.497576] [<ffffffff810a0ec7>] smp_call_function_single+0x147/0x160
>>>> [ 19.497576] [<ffffffff813265ce>] rdmsr_safe_on_cpu+0x4e/0x70
>>>> [ 19.497576] [<ffffffffa00900d8>] msr_read+0x98/0xd0 [msr]
>>>> [ 19.497576] [<ffffffff8129b723>] ? security_file_permission+0x93/0xb0
>>>> [ 19.497576] [<ffffffff81177650>] vfs_read+0xb0/0x180
>>>> [ 19.497576] [<ffffffff811778e2>] sys_pread64+0xa2/0xb0
>>>> [ 19.497576] [<ffffffff8165e2c2>] system_call_fastpath+0x16/0x1b
>>>> [ 19.497576] Code: 89 e5 66 66 66 66 90 0f 01 f9 48 89 c6 48 89 d0 89
>>>> 0f 48 c1 e0 20 48 09 f0 5d c3 0f 1f 00 55 48 89 e5 66 66 66 66 90 89 f9
>>>> 0f 32<45> 31 c0 89 c7 48 89 d0 44 89 06 48 c1 e0 20 89 f9 48 09 c8 5d
>>>> [ 19.497576] RIP [<ffffffff8103bf5d>] native_read_msr_safe+0xd/0x30
>>>> [ 19.497576] RSP<ffff88001ba73db0>
>>>> [ 19.497576] ---[ end trace abd45dfe942fc0ed ]---
>>>>
>>>> ... this was of course while running with the fwts-live frontend, but
>>>> can also be easily reproduced with `sudo fwts msr`.
>>>>
>>>> On the host machine (Precise based) I noticed this is generated when I
>>>> hit the GPF:
>>>>
>>>> [592075.713605] kvm: 25101: cpu0 unhandled rdmsr: 0x1fa
>>>> [592075.714107] kvm: 25101: cpu0 unhandled rdmsr: 0x3f1
>>>> [592080.880260] kvm_get_msr_common: 10 callbacks suppressed
>>>>
>>>> I then tried to reproduce this on real hardware and cannot reproduce the
>>>> failure which got me looking at:
>>>>
>>>> https://lkml.org/lkml/2012/1/6/173
>>>>
>>>> ... although I'm not sure if it's relevant here.
>>>>
>>>> Also to note, I'm running fwts version 0.24.16.
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> [0] --
>>>> http://hwe.ubuntu.com/fwts-live/images/fwts-live-oneiric-amd64-usb-hdd-20120127-0.img.bz2
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Not all MSR registers are supported in all CPUs and some read/write of
>>> MSR may depend on others. Read/Write to unsupported MSR will generate
>>> GPF.
>>>
>>> 1FAH (IA32_DCA_0_CAP) DCA type 0 Status and Control register
>>> 3F1H (MSR_PEBS_ENABLE PEBS) Control (R/W)
>>>
>>> It could be KVM does not support the MSR registers. Many CPUs support
>>> these MSR and the error will not be duplicated with real hardware.
>>>
>>> Cheers,
>>> Alex Hung
>>>
>>
>>
> 
> 