Received: by 10.223.185.111 with SMTP id b44csp98545wrg; Fri, 9 Mar 2018 01:41:24 -0800 (PST) X-Google-Smtp-Source: AG47ELvdiTWkIw7t/QOSycbH1+nguZPd5/GIv8JsvTViRqGf0pyc9elWV+BnQYLNacBIAl//2IfO X-Received: by 2002:a17:902:8c97:: with SMTP id t23-v6mr27096447plo.372.1520588484047; Fri, 09 Mar 2018 01:41:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520588484; cv=none; d=google.com; s=arc-20160816; b=lxHi78GxgBdClftosaLr1dVAT61Ad7NEXbL3qos6xpyPg08pQGDsI1sY9xBKCiQpp1 Fy/tcLT+d1/V6RlBlKX/51TVWqoTJ7uHv8kUbBV8cqynS2u4DDlN67F3+nbn40Y1Oudd fmCCXhMzKGAesO8QQZa9JX58wURAUDOGeepeiRgSpIuSAT9nqQOUArKZd3QXZQap1iHc 8y8KmQYFRz3mCNp/z5Vg/PFLeZM05Z7Dm8Hfgf5KFDrIdwaLj5E0RkZMipWFV8xBbogY Gsrb4AiJE5xnSYNveH6NSJEuD2wggy3ItOmNrJ3jNG0fXF7AtHUpDx2jiKo9AoS5VbMc GnaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=VAyCjiMqCqpcZVC7r+38bO8tmetgsHAcckaKxtmKc6g=; b=mFD/r3U5AdlqaOZaUEYE7KvvojVK6jL/9JNFwfCH0coF+Jul3fL8jWzyAbiZc8VHWx iUSgnzO+S7vAvoMru/ff8NC+eGyb5izrliX3sCzehXBaYEyqBQt3MUIPE8+nl28C+/OO aJqJHwgy44Da7yJglKFtAtlXQrgLTzX5pVPoZJGuhfZj7neA1PMgDWJbiCvSEfhpBHZv PVxHqzbNWZD/1f654jI6peZfTw1oJTw5pl9Cq2Ua8zhEEVf3Kys84hfLfDUAvNzDl9Ko zPYXOQfLA0Cp/IxLDbZ1bu+fdDPsbThqTkZ51JYA2zgUbcL9a04FZIgqRTpAjhljE5Ln Uuaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m4si565449pfh.229.2018.03.09.01.41.08; Fri, 09 Mar 2018 01:41:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751033AbeCIJkH (ORCPT + 99 others); Fri, 9 Mar 2018 04:40:07 -0500 Received: from foss.arm.com ([217.140.101.70]:49124 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800AbeCIJkG (ORCPT ); Fri, 9 Mar 2018 04:40:06 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0EB6580D; Fri, 9 Mar 2018 01:40:06 -0800 (PST) Received: from [10.1.207.62] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3EF063F25C; Fri, 9 Mar 2018 01:40:04 -0800 (PST) Subject: Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling To: "Yang, Shunyong" , "eric.auger@redhat.com" , "cdall@kernel.org" Cc: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "david.daney@cavium.com" , "ard.biesheuvel@linaro.org" , "kvmarm@lists.cs.columbia.edu" , "will.deacon@arm.com" , "Zheng, Joey" References: <1520492490-7943-1-git-send-email-shunyong.yang@hxt-semitech.com> <9ad47673-068e-f732-d2ca-9c76a8fbdfbc@arm.com> <0a15633d-8944-cb9b-3e6b-b08ee5ec42b9@arm.com> <20180308161900.GC1917@lvm> <86r2oubho3.wl-marc.zyngier@arm.com> <1520565257.2583.57.camel@hxt-semitech.com> From: Marc Zyngier Organization: ARM Ltd Message-ID: <959b6484-c683-65b2-a1e5-3e3784865682@arm.com> Date: Fri, 9 Mar 2018 09:40:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1520565257.2583.57.camel@hxt-semitech.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>>> 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...