Re: arm: warning at virt/kvm/arm/vgic.c:1468

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

On 2015-02-15 15:59, Marc Zyngier wrote:
> On Sun, Feb 15 2015 at  2:40:40 pm GMT, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2015-02-15 14:37, Marc Zyngier wrote:
>>> On Sun, Feb 15 2015 at  8:53:30 am GMT, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>> 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.
>>
>> OK... let me figure this out. I had this suspect as well - the host gets
>> a VM exit for each injected guest IRQ?
> 
> Not exactly. There is a VM exit for each physical interrupt that fires
> while the guest is running. Injecting an interrupt also causes a VM
> exit, as we force the vcpu to reload its context.

Ah, GICC != GICV - you are referring to host-side pending IRQs. Any
hints on how to get access to that register would accelerate the
analysis (ARM KVM code is still new to me).

> 
>> BTW, I also tried with in-kernel GIC disabled (in the kernel config),
>> but I guess that's pointless. Linux seems to be stuck on a
>> non-functional architectural timer then, right?
> 
> Yes. Useful for bringup, but nothing more.

Maybe we should perform a feature check and issue a warning from QEMU?

> 
>>>
>>> Do you have an form of power-management on this system?
>>
>> Just killed every config that has PM for FREQ in its name, but that
>> makes no difference.
> 
> I still wonder if the 4+1 design on the K1 is not playing tricks behind
> our back. Having talked to Ian Campbell earlier this week, he also can't
> manage to run guests in Xen on this platform, so there's something
> rather fishy here.

Interesting. The announcements of his PSCI patches [1] sounded more
promising. Maybe it was only referring to getting the hypervisor itself
running...

To my current (still limited understanding) of that platform would say
that this little core is parked after power-up of the main APs. And as
we do not power them down, there is no reason to perform a cluster
switch or anything similarly nasty, no?

Jan

PS: For those with such a board in reach, newer U-Boot patches are
available at [2] now.

[1] http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/208034
[2] https://github.com/siemens/u-boot/commits/jetson-tk1-v2


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]