Message-ID: <959b6484-c683-65b2-a1e5-3e3784865682@arm.com>
Date:   Fri, 9 Mar 2018 09:40:01 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     "Yang, Shunyong" <shunyong.yang@...-semitech.com>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "cdall@...nel.org" <cdall@...nel.org>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "david.daney@...ium.com" <david.daney@...ium.com>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
        "will.deacon@....com" <will.deacon@....com>,
        "Zheng, Joey" <yu.zheng@...-semitech.com>
Subject: Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level
 interrupt resampling

On 09/03/18 03:14, Yang, Shunyong wrote:

[trimming things a bit]

>>>>>>>  static bool lr_signals_eoi_mi(u32 lr_val)
>>>>>>>  {
>>>>>>> -	return !(lr_val & GICH_LR_STATE) && (lr_val &
>>>>>>> GICH_LR_EOI) &&
>>>>>>> -	       !(lr_val & GICH_LR_HW);
>>>>>>> +	return !((lr_val & GICH_LR_STATE) ^ GICH_LR_STATE)
>>>>>>> &&
>>>>>> That feels very wrong. You're now signalling the resampling
>>>>>> in both
>>>>>> invalid and pending+active, and the latter state doesn't mean
>>>>>> you've
>>>>>> EOIed anything. You're now over-signalling, and signalling
>>>>>> the
>>>>>> wrong event.
> 
> I am using XOR GICH_LR_STATE(0b'11), so only 0b'11(P&A) will be
> signaled. Other state will be false.

And that's really wrong. P+A is a state where the interrupt is still
being processed. The only case where we can reliably detect that an
interrupt has been EOId is when state==0.

> And I am curious why the EOI bit in LR indicate the end of interrupt
> regardless of the state? Please bear with me as I am a newbie in this
> part.

The EOI bit indicates that we've requested a maintenance interrupt from
the HW. It only triggers when state==0. If you have (like you describe
further down) a sequence of

P -> A -> (exit) -> P+A -> P -> A -> (exit) P+A ...

we can never reliably detect that an interrupt has been EOId (because
the HW never delivers a maintenance interrupt), other than by tracking
the states before and after exit, and hoping that you've done an exit
because you're touching the source of the interrupt.

>>>>> Also, any guideline on how to reproduce this would be much
>>>>> appreciated.
>>>>> I never used this mdev/mtty thing, so please bear with me.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> 	M.
> 
> The mdev/mtty documentation is at Documentation/vfio-mediated-
> device.txt. It docmented how to enable mtty device.
> And support for "vfio-pci,sysfsdev" should be availabe in your qemu
> version (I compiled the latest version).
> Following is my commond to run qemu with mdev support,
> "qemu-system-aarch64 -m 1024 -cpu host -M virt,gic_version=3 -nographic
> \
> -kernel /home/yangsy/up-kvm/arch/arm64/boot/Image.gz \
> -initrd /home/yangsy/kvm/ramdisk/initrd.img \
> -netdev user,id=eth0 -device virtio-net-device,netdev=eth0 -enable-kvm
> \
> -append "root=/dev/ram rdinit=/sbin/init" \
> -device vfio-pci,sysfsdev=/sys/bus/mdev/devices/83b8f4f2-509f-382f-
> 3c1e-e6bfe0fa1001
> "
> For just test this vgic case, type "cat /dev/ttyS0" in guest. But if
> test read/write multiple bytes, please apply following patch also
> https://patchwork.kernel.org/patch/10267039/

Thanks. I'll have a look.

> 
>>>>>
>>>>> From 66a7c4cfc1029b0169dd771e196e2876ba3f17b1 Mon Sep 17
>>>>> 00:00:00 2001
>>>>> From: Marc Zyngier <marc.zyngier@....com>
>>>>> Date: Thu, 8 Mar 2018 11:14:06 +0000
>>>>> Subject: [PATCH] KVM: arm/arm64: Do not rely on LR state to
>>>>> guess EOI MI
>>>>>  status
>>>>>
>>>>> We so far rely on the LR state to decide whether the guest has
>>>>> EOI'd a level interrupt or not. While this looks like a good
>>>>> idea on the surface, it leads to a couple of annoying corner
>>>>> cases:
>>>>>
>>>>> Example 1: (P = Pending, A = Active, MI = Maintenance
>>>>> Interrupt)
>>>>> P -> guest IAR -> A -> exit/entry -> P+A -> guest EOI -> P ->
>>>>> MI
>>>> Do we really get an EOI maintenance interrupt here?  Reading the
>>>> MISR
>>>> and EISR descriptions make me thing this is not the case...
>> Hum yes in EISR it is said that ICH_LR.State = 0b00!
>>>
>>>
>>> Yeah, it looks like I always want EISR to do what I want, and not
>>> to
>>> do what it does. Man, this thing is such a piece of crap.
>>>
>>> OK, scratch that. We need to do it without the help of the HW.
> 
> If convenient, maybe we can get something from HW gus. :-)
> 
> Hi, Marc,
> 
> Do you need me to test the patch you posted for EISR? As it seems there
> are some things need more discussion.

Yeah, that approach doesn't work. I'll try and come up with another
approach (basically banning P+A for interrupts that require a back
notification).

[...]

> I have added some logs to compare level interrupt between pl011(hwirq =
> 33) and mtty (hwirq = 36). In mtty case, vgic_queue_irq_unlock() is
> called twice. But only called once in pl011.
> 
> following is the log,
> ===Without my patch===
> ###PL011###
> 
> <4>[  180.598266] kvm_vgic_inject_irq 453 irq:33 enabled:1 config:1
> latch:0 level:1
> <4>[  180.604460] ##vgic_queue_irq_unlock 388 irq->intid:33 enable:1
> level:1
> <4>[  180.604540] ==>90a0020000000021(active)
> <4>[  180.614878] ==>d0a0020000000021(P&A)
> <4>[  180.618415] kvm_vgic_inject_irq 453 irq:33 enabled:1 config:1
> latch:0 level:0
> <4>[  180.625508] ==>90a0020000000021(active)
> <4>[  180.629343] ==>10a0020000000021(inactive)
> 
> ###mtty-vfio###
> <4>[  223.123329] kvm_vgic_inject_irq 453 irq:36 enabled:0 config:1
> latch:0 level:1
> <4>[  223.129736] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1
> level:1
> <4>[  223.136027] ==>50a0020000000024(pending)
> <4>[  223.139954] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1
> level:1
> <4>[  223.146460] ==>90a0020000000024(active)
> <4>[  223.150273] ==>d0a0020000000024(P&A)
> <4>[  223.153827] ==>90a0020000000024(active)
> <4>[  223.157668] ==>d0a0020000000024(P&A)

So the line is never lowered. That's very odd.

> ...........cyclic...
> 
> I rembered in some tests the state change is cyclic P->A->P&A. But it
> seems I cannot reproduce it. Is output LR state
> in kvm_vgic_inject_irq() reliable?
> 
> ===With my patch===
> ###PL011###
> <4>[  114.798528] kvm_vgic_inject_irq 453 irq:33 enabled:1 config:1
> latch:0 level:1
> <4>[  114.804743] ##vgic_queue_irq_unlock 388 irq->intid:33 enable:1
> level:1
> <4>[  114.804796] ==>90a0020000000021(active)
> <4>[  114.815077] ==>d0a0020000000021(P&A)
> <4>[  114.818628] kvm_vgic_inject_irq 453 irq:33 enabled:1 config:1
> latch:0 level:0
> <4>[  114.825726] ==>90a0020000000021(active)
> <4>[  114.829560] ==>10a0020000000021(inactive)
> 
> ###mtty-vfio###
> 
> <4>[  161.579083] kvm_vgic_inject_irq 453 irq:36 enabled:0 config:1
> latch:0 level:1
> <4>[  161.585419] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1
> level:1
> <4>[  161.591780] ==>50a0020000000024(pending)
> <4>[  161.595708] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1
> level:1
> <4>[  161.602204] ==>90a0020000000024(active)
> <4>[  161.606023] ==>d0a0020000000024(P&A)
> <4>[  161.609561] kvm_vgic_inject_irq 453 irq:36 enabled:1 config:1
> latch:0 level:0
> <4>[  161.616693] ==>10a0020000000024(inactive)
> <4>[  161.620745] kvm_vgic_inject_irq 453 irq:36 enabled:1 config:1
> latch:0 level:1
> <4>[  161.627800] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1
> level:1
> <4>[  161.627849] ==>90a0020000000024(active)
> <4>[  161.640076] ==>d0a0020000000024(P&A)
> <4>[  161.642689] kvm_vgic_inject_irq 453 irq:36 enabled:1 config:1
> latch:0 level:0
> <4>[  161.649822] ==>10a0020000000024(inactive)

Which is really bizarre. The device only lowers the line when it is
being told that the interrupt has been processed. That really smells of
a bug in the device emulation. It should be lowered when the guest
clears the interrupt status at the device level, and not when notified
that the interrupt has been completed at the interrupt controller level.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists