On Sun, Feb 15 2015 at 8:53:30 am GMT, Jan Kiszka <jan.kiszka@xxxxxx> wrote:
> On 2015-02-13 07:53, Alex Bennée wrote:
>>
>> Alex Bennée <alex.bennee@xxxxxxxxxx> writes:
>>
>>> Christoffer Dall <christoffer.dall@xxxxxxxxxx> writes:
>> <snip>
>>>> On Sun, Feb 08, 2015 at 08:48:09AM +0100, Jan Kiszka wrote:
>> <snip>
>>>>> BTW, KVM tracing support on ARM seems like it requires some care. E.g.:
>>>>> kvm_exit does not report an exit reason. The in-kernel vgic also seems
>>>>> to lack instrumentation. Unfortunate. Tracing is usually the first stop
>>>>> when KVM is stuck on a guest.
>>>>
>>>> I know, the exit reason is on my todo list, and Alex B is sitting on
>>>> trace patches for the gic. Coming soon to a git repo near your.
>>>
>>> For the impatient the raw patches are in:
>>>
>>> git.linaro.org/people/alex.bennee/linux.git
>>> migration/v3.19-rc7-improve-tracing
>>
>> OK try tracing/kvm-exit-entry for something cleaner.
>
> Doesn't build for ARM (vcpu_sys_reg is ARM64-only so far).
>
> But the values traced seem useful. Wei Huang's patch in kvm.git queue
> traces the exception class, but unfortunately nothing else. When would
> we need that class? Do we need it at all?
>
> In any case, please add symbolic printing of the magic values whenever
> possible, just like on x86.
>
> I'm now throwing trace_printk at my broken KVM. Already found out that I
> get ARM_EXCEPTION_IRQ every few 10 µs. Not seeing any irq_* traces,
> though. Weird.
This very much looks like a screaming interrupt. At such a rate, no
wonder your VM make much progress. Can you find out which interrupt is
screaming like this? Looking at GICC_HPPIR should help, but you'll have
to map the CPU interface in HYP before being able to access it there.
Do you have an form of power-management on this system?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
