----- bp@xxxxxxx wrote: > On Wed, Nov 26, 2014 at 07:39:26AM -0500, boris ostrovsky wrote: > > https://lkml.org/lkml/2014/11/25/973 is all I have right now. > > Ok, so the Code: section from this splat says: > > 25: 55 push %ebp > 26: 89 e5 mov %esp,%ebp > 28: 83 ec 08 sub $0x8,%esp > 2b:* 80 3d c0 ee 97 01 00 cmpb $0x0,0x197eec0 <-- > trapping instruction > 32: 89 1c 24 mov %ebx,(%esp) > 35: 89 74 24 04 mov %esi,0x4(%esp) > 39: 74 12 je 0x4d > 3b: 8b 1c 24 mov (%esp),%ebx > 3e: 8b .byte 0x8b > 3f: 74 .byte 0x74 > > which I can correlate to the dis_ucode_ldr test here: > > .loc 1 134 0 > .loc 1 137 0 > cmpb $0, dis_ucode_ldr+1073741824 #, *_11 > je .L46 #, > > > so we must be faulting when accessing that dis_ucode_ldr thing. But > you > said that accessing it through its virtual address doesn't fix the > issue > either. Which is very very strange... I was confusing you: accessing dis_ucode_ldr by virtual address does work on PV. But we then fail later, in load_ucode_intel_ap(), because it also tries to use __pa_nodebug() which can't be used by PV. So if accessing dis_ucode_ldr by virtual address is acceptable (although I don't think it is?) then we can stick dis_ucode_ldr=1 into xen_start_kernel() and then things look OK. A better solution may be to replace cpuid in x86_guest() with 'return pv_info.paravirt_enabled' (or paravirt_enabled(), I guess). I gave it a quick spin (32-bit only) and it seems to work. I'll see how my overnight tests behave. -boris -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html