On 12/29/2013 04:04 PM, Rafael J. Wysocki wrote: > On Sunday, December 29, 2013 01:12:18 PM Kashyap Chamarthy wrote: >> [. . .] >> >>>> Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751 >>>> >>>>>> Can you ftrace the failure? >>>> >>>> Can try, need some time (rest of the day I'll be away travelling, >>>> will try to do it over the weekend, and update the Kernel >>>> bugzilla with observations). >>>> >>>>>> >>>>> Ugh, it looks like guest dmesg but there are KVM messages there too ("[ >>>>> 281.443662] kvm [2452]: vcpu0 unhandled rdmsr: 0xe8" is unhandled access >>>>> to MSR_IA32_APERF I was talking about above), so I guess this is nested >>>>> guest invocation? >>>> >>>> Yeah -- sorry, I forgot to note it's in a nested environment :( >>>> >>>>> Does it happen in non nested guest? >>>> >>>> I need to that. >>>> >>>> Note to self: Also try with a newer Kernel on the host. >>> >>> Please try the patch I posted earlier today when you're at it: >>> >>> https://patchwork.kernel.org/patch/3411991/ >> >> I applied the patch & tried to build the Kernel, it failed with: >> >> ======= >> . >> . >> . >> Generating a 4096 bit RSA private key >> ............................................................................................................drivers/cpufreq/intel_pstate.c: >> In function 'intel_pstate_init_cpu': >> drivers/cpufreq/intel_pstate.c:617:18: error: 'struct pstate_data' has no member named >> 'current_state' >> if (!cpu->pstate.current_state) { > > My bad, that should have been current_pstate. Updated patch is appended. > > Thanks, > Rafael > > > --- > drivers/cpufreq/intel_pstate.c | 5 +++++ > 1 file changed, 5 insertions(+) > > Index: linux-pm/drivers/cpufreq/intel_pstate.c > =================================================================== > --- linux-pm.orig/drivers/cpufreq/intel_pstate.c > +++ linux-pm/drivers/cpufreq/intel_pstate.c > @@ -614,6 +614,11 @@ static int intel_pstate_init_cpu(unsigne > cpu = all_cpu_data[cpunum]; > > intel_pstate_get_cpu_pstates(cpu); > + if (!cpu->pstate.current_pstate) { > + all_cpu_data[cpunum] = NULL; > + kfree(cpu); > + return -ENODATA; > + } > > cpu->cpu = cpunum; > > Thanks Rafel, I can confirm this patch helps. I re-built the Kernel on L0 (physical host) and L1 (guest hypervisor) with the above patch, and re-ran the libguestfs test (which invokes an L2 appliance), it now successfully completes: http://kashyapc.fedorapeople.org/temp/libguestfs-test-tool-stdout.txt Here's a Fedora Kernel scratch build (not retained for more than 2 weeks) with the above patch I used -- http://koji.fedoraproject.org/koji/taskinfo?taskID=6342414 -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
